前言

前端代码中与后台API进行数据交换是一个复杂的开发点，几乎在所有的项目中都会遇到。怎么从后台API获取数据，怎么提交数据，怎么保证获取数据的快捷性、唯一性、不重复请求等问题，是这个点中的主要挑战。在《Databaxe：基于observer思想的数据（源）管理器》一文中我详细阐述了开发DataBaxe的出发点和开发思路。但是在如何使用，以及它的具体细节上，还没有详细介绍。本手册的主要目标是，帮助开发者快速上手和快速查看使用方法，同时提供一些场景的解决方案。

快速上手

这一节帮助开发者快速上手如何使用DataBaxe实现优雅的前端数据请求。

安装

DataBaxe通过npm包的形式对外发布，你可以通过下面命令安装

npm i -S databaxe

安装到项目之后，你可以如下引入

// ES6引入方式
import DataBaxe from 'databaxe'

// CommonJS引入方式
const { DataBaxe } = require('databaxe')

另外，在浏览器中，为了可以单独运行DataBaxe，你可以如下引入：

<script src="node_modules/databaxe/dist/databaxe.bundle.js"></script>
<script>
const { DataBaxe } = window.databaxe
</script>

DataBaxe是一个数据请求管理的工具，不基于浏览器环境，因此，它可以在NodeJS中运行。

创建实例

DataBaxe这个对象是一个类，你可以通过new关键字实例化一个对象，这个对象就是一个数据管理器，用它来管理数据来源（api接口）、请求方式（请求组件axios的参数）、输出方式（返回数据如何处理）。

const dbx = new DataBaxe()

// 第一步：注册数据来源
dbx.register({
  id: 'users',
  url: '/api/v2/users',
})

export default dbx

---------------------------------

// 第二步：使用数据
;(async function() {
  let users = await dbx.get('users')
  // ...
})

dbx的所有方法都是async函数，调用的时候，你既可以像promise那样使用then/catch，也可以在async函数中使用await关键字直接得到结果。

上面这段代码中我们将dbx导出，在项目的其他地方使用dbx。而dbx其实是一个容器，它包含了所有你注册好的数据源（含请求方式）。基于这样的设计，你可以将数据源集中起来管理，将项目中所有需要用到的接口统一封装为一个dbx（数据仓库），当你需要某个数据的时候，只需要通过get去其中获取即可。这使得数据源的管理和数据的使用完全分离，对于使用者来说，可以做到完全无感的从仓库中获取数据，他完全不需要知道这个数据是从哪个api来的，也不需要知道内部是怎么请求数据的，他完全就是调用一个get方法，并且知道每一个id代表的是什么数据即可。

这对于开发来说，其实是非常完美的一件事。开发者仅仅需要记住一个id值，而不需要传参数，也不需要写特殊的ajax逻辑。看上去，这就像一个仓库，你不知道仓库里面怎么运作的，但是你知道，凭借id就可以取数据。

这样的取数据方式简直不要太舒服。相当于仓库的提供者和代码的撰写者完全分开，业务代码的撰写者完全不关心后台的api接口，只关心仓库有没有提供一个id，可以获得我需要的数据。

概念

在使用DataBaxe进行深度开发的时候，我们还需要除了获取数据本身之外的功能所需要的其他功能，我们还需要更深入的了解DataBaxe的设计逻辑。

数据源

不可否认，本质上，我们还是要从后台的API获取数据。而规定一个数据如何从API获得的配置信息，就是“源”。同时，我们给这个源配置一个id号，这样，我们可以在获取对应的源的数据时，可以用这个id作为获取的凭证。

而且，基于restful风格的api设计，使得源的设计也非常有意思，你可以为每一个请求类型设计一个独立的源，也可以设计一个共用的源并通过获取数据时传参数来决定进行什么请求类型。这个技巧，我会在下文详细解释。

数据仓库

对于开发者而言，要取数据就从数据仓库取，要更新数据，就往数据仓库塞。数据仓库里面保存着所有从api请求过来的数据，但是，对于所有从数据仓库中获取数据的调用者，如果每一次都要从api去请求数据，不仅速度慢，而且短时间内所请求的数据是一样的，没有必要再次请求。

缓存

如何做到短时间内不必重复请求API呢？当然是使用缓存。在一个请求发起之后，数据回来之后，将回来的数据缓存起来，当发现新的请求是请求的相同的数据时，就将缓存作为结果直接返回。问题在于，1.怎么保证请求的唯一性；2.怎么确定缓存的时效性。我们通过ajax请求的method、url和配置信息来确定请求是唯一的。而且，对于一个唯一确认的请求而言，所有使用databaxe的调用方都是一样的，即使创建了多个databaxe实例，它们之间也共享缓存。而缓存的时效性则根据每个实例配置的expire选项来确定。

但需要注意的一点是，expire不会致使缓存销毁。expire仅仅是决定是否要使用缓存。也就是说，一个数据源的缓存，一旦生成之后，只会被新数据替换，而不会被销毁。这样的设计，确保了每一次get都能得到数据。在缓存过期的情况下，新的ajax会发出，但是倘若这个请求失败，那么缓存还是会被使用，也就是说，任何情况下，get都能给你想要的结果。这是一个巧妙的设计，让你的应用可以做到更好的可用性。

由于缓存的存在，使得databaxe的调用方在请求数据时极其的快。同时，开发者可以根据需要，选择缓存的存储介质，可以是临时的内存变量，也可以使用localStorage持久化数据，还可以使用HelloIndexedDB等其他拥有Storage API的存储方式。

响应式设计

只有前面所提到的东西，不足以让databaxe与众不同，真正让databaxe出人意料的，是响应式设计。在databaxe的使用中，你可以通过subscribe方法，对某个id的数据进行观察，当这个数据发生变化（从api拉回新数据之后），传入的回调函数会被执行。这样一来，不同的调用方，在同一个数据发生变化的时候，都可以按照自己的需要进行响应。

更为奇妙的是，基于内部的依赖收集原理，和autorun方法，在某些函数内用get获取了数据，而当对应的数据发生变化时，该函数会被自动重新执行一次，这非常适用于某些界面渲染的场景。这也会在下文详细举例。

数据源

数据源用于决定一个数据从哪个api接口获取数据，或将数据提交到哪个接口。

之所以在实例化配置之前讲数据源，是因为，数据源可以单独于databaxe而存在，它可以是一种协议，可以用于所有支持这种协议的数据管理工具。databaxe只是使用了这些数据源配置，并按照自己的逻辑实现了数据管理。你甚至可以自己发明一套逻辑，来使用这些数据源。

在一个项目中，将数据源抽离出来，有利于统一管理数据源，对于后台api的任何变化，都可以通过数据源的代码了解到。更有意思的是，数据源配置的源代码，即是api接口的文档，一个接口需要什么参数，都可以通过数据源的配置信息了解到。

数据源配置

一个数据源的配置信息如下：

{
  id: 'xxx', // 作为该数据源的身份凭证
  url: 'xxx', // 作为数据源的目标api地址，URL支持插值的方式提供占位符，在真正请求数据时再传入插值替代值，当url以http(s)://开头时，直接作为目标地址，如果不是，则会与配置中的baseURL连接
  options: { // 请求配置信息，databaxe内部使用axios作为ajax请求的库，options将作为请求这个接口时传的请求配置信息的基础信息
    method: 'GET',
  },
  transform: function(data) { // 数据从仓库出来时，数据从store中取出后，通过这个函数进行转化，get的最终结果是transform的结果。需要注意的是，store.stringify为false时，transform不能直接修改data本身，而应该克隆一份后进行修改。
    return Object.assign({}, data, { is: true })
    // 建议，transform是一个纯函数，不产生任何副作用
  },
  take: function(res) { // 数据从api返回时，将通过take函数兜住整个响应数据，让你可以对响应数据进行修改。注意，缓存中将存储take编辑后的结果，因此，要特别小心，因为编辑后的数据会被其他实例使用。
    //建议，take是一个纯函数，主要用于对api返回的数据类型和结构进行检查，你可以搭配hello-type使用
  },
}

之所以将一个数据的请求信息提炼出来，是为了让数据源可管理性更强。你可以单独使用一个模块来存放所有和项目相关的数据源，而当后台的api发生变化时，只需要修改数据源即可，而不需要对业务代码进行任何的修改。

URL插值

数据源配置的URL中支持插值，这是一个重要的特性，因为几乎大部分数据都需要根据实际的数据信息才能获取到。而在缓存时，这些特征都被收集起来，也就是说，不会出现不同的数据资源混用了缓存的情况。

// url配置为 `/api/v2/users/{userId}`
// 当获取某个用户的详情时，可以

dbx.get('user_by_id', { 
  fields: { userId: '12345566' } 
})
// 在get方法的第二个参数中传入feilds，用来替换掉url中的插值

这样，使得datasource的灵活性大大增强。而一个数据源，在请求的时候，url不同，searchquery不同，postdata不同，都代表着不同的数据结果，在缓存时，databaxe会完全考虑到了这些，因此，当你的get的第二个参数和url一起搭配着决定了缓存的标志。这让缓存不会出现任何错误。

transform

transform函数用于在当你从仓库中取出数据之前，对将要取出的数据进行一次转化。之所以这样设计，是因为，对于后台api返回的结果而言，前端可能需要根据自己的需求而进行调整，不能单纯直接使用后台api返回的结果。这个时候，可以通过transform来对数据进行转换。

使用transform需要注意两点：

1. transform会在每次get的时候生效，transform的结果不会被缓存（今后会考虑采用reselect的方式对transofrm结果进行缓存），这也就是说，transform会在每次取数据时执行，倘若trasnform消耗了太多性能，显然是不明智的，因此，它仅适用于对数据结构之类的简单处理，而不应该将大型的运算加入其中。
2. trasnform不可对传入的原始数据进行修改（除非你使用localStorage/indexedDB等本地存储），否则，它会直接对缓存产生副作用，造成后续数据错误。因此，transform必须是纯函数，和redux的reducer一样，不可以在内部对输入进行修改。

之所以缓存的不是transform的结果，是因为所有数据源在所有实例之间都是共享的，也就是说，后台api返回的数据，不一定仅被当前这个trasnform转换，还可能会被其他实例的transform转换。所以，缓存必须保存api返回的原始结果，这样才能保证每一个transform得到的源数据是一致的。

而transform为纯函数，是将来内置transform结果缓存的基础，也就是说，在以后的版本中，我会直接把transform的结果也缓存起来，这样可以更提高性能。

take

take函数在数据从api返回给databaxe时被调用，它会兜住整个response信息。之所以要在数据返回时提供一个兜住的功能，是为了方便开发者根据返回的response来决定该返回结果是否合法。

可以说，take的唯一功能，就是校验数据是否合法，你不可以在take中修改数据本身，否则会造成严重的数据污染问题，所有实例之间共享了同一个datasource的数据，一旦你在某一个实例的take中修改数据，那么其他实例就会使用错误的数据。

一个校验的技巧是，当你在take中抛出错误时，相当于数据请求就会失败，返回的数据不会写入到缓存中。

{
  take: function(res) {
    if (res.data.error) {
      throw new Error(res.data.error)
    }
  }
}

上面这段代码，在take中使用了throw error，这样可以在后台返回的数据有问题的时候，防止把错误的数据写入到缓存中。而且，在这种情况下，get仍然能正常返回数据，只不过使用的是缓存结果而已。

实例化配置

我们在项目中，创建一个databaxe的实例，需要用到的配置。

配置详解

databaxe的配置看情况，基础用法配置很简单，但是如果想使用更加丰富的功能，可以进行比较复杂的配置。

{
  debug: false, // 是否启用调试工具，启用后当出现一些问题时，可以在控制台看到错误输出
  expire: 0, // 缓存的过期默认时间，0:永不过期，负数:不使用缓存，正数:过期时间。expire会被单个datasource的expire选项覆盖
  debounce: 0, // save方法提交时的延迟时间，当一个save方法被触发时，它不会马上将数据提交到后端，而是等待debounce结束，当在debounce时间内新的save被触发，那么会发生两件事：
    // 1. 新提交的save的数据，会合并到当前的数据中，后面提交的数据字段会覆盖之前的字段值
    // 2. debounce的时间重置，等到结束后才会再次提交
    // 注意：debounce的最小值为10
  store: { // 数据持久化配置信息，databaxe内部使用hello-storage作为缓存的库，store将作为配置信息传入 
    namespace: 'databaxe',
    storage: localStorage, 
    stringify: true, // 默认为false 
  },
  options: { // 数据请求的默认配置，databaxe使用axios作为内置的数据请求工具，options会被作为axios的默认配置，当发起一个get或save时，传入的options会与默认options合并
    baseURL: '',
  },

  onInit: null,
  onRegister: null,
  onUpdate: null,
  onRequest: null,
  onResponse: null,
}

const configs = {
  expire: 10000, // 10秒缓存
}
const dbx = new DataBaxe(configs)

存储介质

databaxe缓存的存储介质是多选的，通过store这个配置，可以决定databaxe实例的一些行为方式。比如，默认情况下，databaxe不同实例之间，同一个数据是共享的，但是，有的时候，你想某个实例数据独享，怎么办？只需要去修改store.namespace即可，通过开设一个独立的命名空间的存储区域，就可以做到数据独享。（默认所有的databaxe实例的存储空间都是名为databaxe的namespace。）再比如，你想使用localStorage作为存储介质，使数据可以持久化。也通过配置store来实现。现在，就详细对存储介质配置进行解释。

databaxe的存储介质是由用户自己配置的，关键是怎么配置呢？这你就要了解一下hello-storage了。 它是一个非常有用的存储脚手架，它本身也提供Storage API接口，作为临时的共享内存存储介质。共享内存存储，说白了，就是变量存储，一刷新页面，就消失了。它的最主要功能是适配各种存储方式，只要一个存储介质支持Storage API，就可以用hello-storage来管理。所谓的Storage API，是web标准的API，主要支持个体getItem, setItem, removeItem等接口，而且非标准的一些扩展，还支持直接存储object，而不是把对象序列化之后才能存储。我撰写的hello-indexeddb这个工具，还能把indexedDB转化为拥有标准Storage API的对象，也可以作为存储介质传给hello-storage。

hello-storage的使用方法也是根据实际情况而不同，最简洁的时候不需要传入任何参数就可以马上使用。例如：

const store = new HelloStorage()
store.set('key', { a: 1 })
let obj = store.get('key')

就是这么简单。但是，由于HelloStorage的设计是为了接近快速使用Storage API，而前端的Storage都是共享的，例如localStorage，两个应用程序，在一个域名下面，操作相同的key，实际上会操作相同的一个数据。因此，为了避免这种情况，实现独享存储，我给hello-storage增加了namespace选项，通过namespace，你可以使得具有相同namespace的存储介质为独享的。例如：

const store1 = new HelloStorage({ namespace: 'store1' })
const store2 = new HelloStorage({ namespace: 'store2' })

这样，store1, store2则会各自独享存储空间，不会引起set同一个key的时候，相互干扰。

但是需要注意的是，如果两个hello-storage的实例具有相同的namespace，那么它们两个又会共享存储。也就是说，namespace决定了你会使用哪一块存储介质。

回到databaxe中，配置中store选项就是传入HelloStorage构造函数的参数，因此，如果你希望某个databaxe实例独立一个存储空间，可以设置自己的store.namespace。默认情况下，databaxe使用的namespace为'databaxe'。

在HelloStorage中，如果我想使用localStorage或者sessionStorage，只需要在参数选项中配置storage这个选项：

const store = new HelloStorage({ 
  storage: localStorage, 
  stringify: true, // localStorage要求对象序列化为字符串后存储，这个选项的默认值是true，所以可以不传
  async: false, // async为true时，整个实例切换为异步模式，在storage本身是异步的情况下，async必须设置为true，否则会导致错误
})
store.set('key', { key: value })

非常简单吧。配置中，storage, stringify, async这三个选项需要搭配，因为不同的存储介质这三个选项都不一样。例如，react native的AsyncStorage，就要求async这个选项必须是true，因为它是异步的。一旦启用async之后，整个HelloStorage都会切换为异步模式。如果你使用HelloIndexedDB，async必须为true，stringify可以为false，因为indexedDB可以存储js对象。

回到databaxe，如果我想使用indexedDB作为存储介质，应该怎么办么？只需要修改store这个配置项即可。

import HelloIndexedDB from 'hello-indexeddb'

const storage = new HelloIndexedDB()
const dbx = new DataBaxe({
  store: {
    storage,
    stringify: false,
  }
})

这样就可以使用indexedDB作为databaxe的存储介质了。

由于DataBaxe内所有的操作都是异步的，因此，store的async参数被强制设置为true，你自己传入的async配置失效。

同样的道理，一旦你掌握了hello-storage，那你可以很轻松的选择不同的存储介质来存储databaxe的缓存，甚至你可以自己构造存储介质，只要该介质拥有标准的Storage API即可。

默认情况下，使用的是HelloStorage提供的内存存储，它是运行时的，因此一刷新页面，数据就没有了，而且，它和当前js线程是共享的，所以对缓存数据直接修改会导致问题，因此，千万不要在默认情况下，直接修改缓存数据，以及直接从缓存中取出来的数据，这也是为什么要求transform是纯函数的原因。

在一个应用中，可以实例化多个databaxe实例，而这些实例可以使用相同的datasource，但也可以使用不同的datasource，还可以一部分共享，一部分自己创建。databaxe实例可以共享一个storage，也可以使用不同的，比如，其中一个使用localSotrage，另外一个使用indexedDB。假如两个databaxe实例共享了一个storage，那么他们会共享同一个请求的数据。所谓的同一个请求，是通过请求的url，再加上options信息，得到的一个对象得到的指纹相同的请求。

API

对于DataBaxe的使用，如果不需要特殊功能，其实非常简单，例如，仅仅把它当作一个待缓存的数据请求工具，只需要一个注册，和一个获取即可。而如果需要更丰富的功能，则需要详细的阅读下面的api。

register

注册数据源。它是一个async函数，可以使用await处理。

• datasources 数据源对象列表，可以是一个数组，当只传入一个数据源的时候，可以直接传，不必放在数组中

dbx.register({
  id: 'user_by_id',
  url: '/api/users/{uid}',
})

get

从databaxe获取数据。它是一个async函数。

• id 某个数据源注册的时候传入的id
• options 请求时所需要的options，作为axios的第二个参数
  • fields options.fields将作为替换url中的差值的参数，在作为axios参数时，会从options中删除
• force 是否强制跳过缓存，从服务器获取最新的数据，默认为false，强制获取后，本地的缓存会被更新

const user = await dbx.get('user_by_id', {
  fields: {
    uid: 123922,
  },
})

subscribe

对某个数据源获取到新数据的事件订阅。callback会在get发起新请求，更新本地的缓存之后被触发。

• id 某个数据源的id
• callback(data, options) 当对应的本地缓存被更新后触发的函数
  • data 更新后的数据
  • options get的时候传入的options，全等
• priority 一个id可以被subscribe多个callback，通过priority规定这些callbacks的执行顺序，默认priority是10

async function render() {
  const users = await dbx.get('users')
  // 利用users渲染界面
}

dbx.subscribe('users', render)

render()

上面这段代码，当'users'这个id的数据源对应的缓存发生变化之后，render函数会被再次执行，这样可以起到重新渲染界面的效果。

需要注意的是，由于databaxe的缓存在一定条件下是共享的，因此，即使另外一个databaxe的实例也使用了和'users'这个数据源一模一样的请求时，当那个实例请求数据更新了这个相同请求的缓存时，render函数也会被触发。这种设计让开发者少写很多代码，例如在两个组件中，使用了各自不同的数据源，然而，这两个数据源发出了相同的请求（指纹相同），那么它们的数据是共享的，subscribe也会跨组件被触发。

因此，在开发的时候，一定要注意，这一点，因为相同的请求URL+参数可能会触发缓存更新，进而触发subscribe的回调函数。而由于不同的实例里，配置的expire的值不同，会导致缓存的更新频率不同。比如，组件A的expire是10，而组件B的expire是20，如果组件B通过subscribe订阅了，那么在同一个缓存被组件A的过期触发时，也会同时触发组件B的观察者，所以两个组件对应的观察者函数会被一起执行。在使用的时候，要特别注意这一点。

unsubscribe

subscribe的反函数，取消对数据源数据变化的订阅。

• id 数据源id
• callback 要取消的callback，当不穿时，表示取消所有id对应的callbacks

save

往服务端发送数据。

在databaxe里面，数据源的配置很有意思，你可以在数据源的options配置中，直接规定这个数据源的请求方式。get主要是从服务端拉取数据，save则是反向往服务端发送数据。因此，get仅支撑GET, POST, HEADERS, OPTIONS这几种请求方式，save则仅支撑POST, PUT, PATCH, DELETE这几种。

get中支持POST也是根据实际情况而支持的，因为在一些特殊的场景下，某些系统会使用POST发送一大堆参数去查询数据，因此，需要在数据源配置和get的options中搭配好使用。

• id 数据源id
• data 要发送的数据，options.method为DELETE时无效
• options 请求时做为axios参数，options.data无效，options.fields不会被axios使用

await dbx.save('users', { uid: 1342455, user_name: 'xiaoming' })

save方法需要搭配settings.debounce使用，当save被触发之后，不会立即发送数据，而是等待debounce时间过去。而在这期间，假如save又被触发，而且是同一个id，那么debounce会被重置，重新开始。而data会被合并，后面的字段会覆盖前一个对象的同名字段。

await dbx.save('users', { uid: 1342455, user_name: 'xiaoming' })
await dbx.save('users', { uid: 1342455, sex: 'F' })
// 发送的数据是 { uid, user_name, sex }

settings.debounce的最小值为10，即10毫秒。

alias

创建一个别名数据源。所谓别名数据源，是指和上文所指的真正数据源有区别的替代性融合数据源。别名数据源可以包含一系列操作，然后当作一个数据源一样，使用databaxe的get/save进行操作。

• id 数据源的id
• fn 调用时执行的函数
• type 要用什么方法调用get/save，默认为get

dbx.alias('user_book', function(options) {
  return Promise.all([
    this.get('user', { fields: { uid: options.fields.uid } }), // 可以使用this
    this.get('book', { fields: { book_id: options.fields.book_id } }),
  ]).then(([user, book]) => {
    return { user, book }
  })
})

// 使用
let userBook = await dbx.get('user_book', { fields: { uid: 124422, book_id: 'xxx-xxx' } })

通过alias，你就可以把多个get/save操作合并为一个。

alias所创建的别名数据源不支持subscribe，但是我们可以通过subscribe原始数据源来达到同样的效果，获取别名数据源时所触发的订阅仍然是有效的。因此，实际上仍然是响应式的。

destory

销毁实例，释放内存。

autorun

这是一个神奇的方法，它可以自动收集一个函数内是否使用了某个数据源，倘若使用了，那么当这个数据源发生变化时，自动重新执行这个函数。

• fns 数组，要自动收集响应的函数列表

async functionn renderA() {
  let data = await dbx.get('a')
  // ...
}
async function renderB() {
  let data = awiat dbx.get('b')
}

dbx.autorun([renderA, renderB]) // renderA和renderB都会被执行一次

autorun会执行一次被传入的函数，在这一次执行过程中，收集到所有依赖，进而可以在这些依赖发生变化时重新触发执行函数。

autofree

autorun的反函数，是否autorun中传入的函数的监听。由于限制，autorun绑定的函数，必须通过autofree进行释放，否则会引起内存问题。

• fns 数组，要解除的函数列表

结语

DataBaxe是这两年来，我经历的多次迭代最终打磨出来的库。它的主要不同之处，是把数据封装起来，像一个仓库一样，抹平了不同组件、不同界面、不同程式之间的同源数据问题，是数据请求上的一种创新。另外，它的响应式设计非常值得玩味，你可以通过我github上的演示代码，看具体的效果。通过响应式编程，你可以做到，在一个团队开发的组件中使用了databaxe，另外一个团队开发的另外一个组件中请求了数据，而更新前面一个组件的界面，但在代码上，两者完全是隔绝的，甚至在开发的时候，两个团队完全不知道对方的存在。

一个库的好坏，要到实践中才能得以检验。DataBaxe和HelloType被我内置到几个自己写作的项目中，结合deferer-queue，可以让项目中的数据请求，更具有健壮性。

如果你觉得本书对你有帮助，通过下方的二维码向我打赏吧，帮助我写出更多有用的内容。

2019-01-26