datamanager.js是我自己认为最近两年写出的最出色的库，虽然源码本身有些乱，而且写在一个文件里面，行数也不多，很多传参也没有类型验证，但是，它的思想，以及我能完整的把这套思想用代码表达出来，都是非常让我兴奋的事。我甚至认为，它是最新范式的数据管理方式。（这里说的数据，是指从服务器请求获取的数据。）为什么这么说，我下面会慢慢解释。不管怎样，你可以提前阅读我在写完代码前写的这篇文章《设计一个基于observer思想的数据管理器》。而且建议你在它的git仓库克隆它下来，跑一下它的例子。如果你以前在工作中遇到过某些情况，你会惊讶于它的解决方式。
数据源
我们传统的数据请求也分了几种层次，最低的莫过于在业务代码流中，想要用数据的地方，就用一个xhr请求去请求数据，包括用jquery的$.ajax去请求。稍微高级一点的，会把所有的数据请求封装在一个目录下，在业务代码中只是调用某个非常简单的函数，就可以完成请求。而flux思想下，把数据和状态（state）混在一起，因为界面是通过state的变化而变化的，因此，要使得界面展示请求回来的数据，就必须通过把数据赋值给state，使得state发生变化，从而使得界面跟着变化。这一过程使得在flux框架下的应用写数据请求到业务逻辑之间的跨度非常大，代码结构非常不好理解，如果是新手，只能望而生畏。
有没有一种可能，我们完全忽略“请求”这个动作，而是定义一大堆数据源，这个源里面提供数据的api接口，要传的参数，请求的方式，至于请求的过程，交给一个黑盒子完成，这样，我就不用在关心我到底要在自己的项目里面，怎么写请求，怎么在不同代码之间实现桥梁，实现数据到界面的转换。
基于上面这个想法，我试着写了一些自己工作中可能出现的数据源形式：
// 从api得到一个数据
{
url: 'http://api.xxx.com/source',
}
// 某些情况下，要拿到一组数据，必须通过post方法
{
url: 'http://api.xxx.com/source2',
method: 'post',
postData: {
yearRange: '2010-2017',
queryIds: [ ... ],
},
}
// 某些情况下，拿到一组数据之后，我希望在得到这组数据之前，对原始数据进行一些结构处理
{
url: '...',
transform(data) {
return data.map(item => item.log_text = item.name + item.share)
},
}
总之，我希望我不需要去写具体怎么请求，而是定义了一大堆data source，每一个source里面包含了拿到这组数据的必要信息，然后，我把这个source传给某个容器，这个容器自己去处理数据请求。而我从这个容器得到的数据，就是我最终想要的数据，我根本不在乎这些数据是怎么得到的，我只在乎我最后拿到的数据是不是我想要的。
数据仓库
上面说的容器，我更愿意用“仓库”来形容。之所以选择“仓库”这个词，是因为它有存储能力，它不是一个蓄水池，水只是从它过一下就走了，它具有存储物品超过一个月甚至一年的能力，你需要的时候你就找它要，它就像哆啦A梦的口袋一样，你问它要数据的时候，数据就在那里。
“仓库”还有一个特点，就是它里面的物品经过详细的类目整理，使得物品的存储和空间利用非常高效，你不用担心同一份数据在它里面产生多个拷贝，从而消耗空间，你也不用担心当你需要一个数据，而它实际上已经有了这个数据的情况下，它还会花更多时间去服务端取，它会智能的分析你向它发出的数据需求，并快速找到已经有的数据，直接返回给你。这事情看上去好像挺奇怪的，这种事好像发生的概率特别低。但是，你想一下这样的情况，teamA和teamB开发了两个不同的组件，它们各自在组件A和组件B里面实现了自己的数据管理，但不巧的是，它们都对同一组数据有依赖，比如地区列表那种，它们虽然不自己发请求，但是每次它们被加载的时候，它们都会通知application层面的框架，让框架的数据管理去请求一下，于是同一个数据源，被毫无必要的访问了两次。
乍一看，这种问题，用缓存不就好了么？然而，它们的思维逻辑完全不同。缓存是在请求过程中的逻辑，而仓库是没有这个逻辑。仓库在面对开发者这一端，你感觉不出它干了任何事情，你随心所欲的向它要数据，而它每次都一五一十的把数据给你，你都不知道它的数据是从哪里来的，你只记得你把数据源告诉了它，你心想，它大概在内部自己按照数据源里面提供的信息已经早就把数据请求回来存起来了。没错，你看出了关键，你从仓库里面去数据是同步的，而传统的请求，是异步的。
我当时就是这样想的：
var a = datamanager.get('a') // 得到一个数据
// 过了很久
var a = datamanager.get('a') // 得到一个新数据，可能是老数据过期了，所以datamanager跑去拿了新数据回来
但是，对于我而言，我只管用get这个方法，我虽然不知道最后得到的是不是一个和前一次相同的数据，但是，我可以保证我每次都得到了一个合法的数据，我不在乎浏览器端的数据是否和服务器端的数据在同一时刻是一致的，但我在乎用户每一次打开页面的时候，都可能极快的得到想要的结果。
当获取数据变成一种直接操作时，无论在执行效率上，还是使用灵巧性上，都和现在所有的前端数据请求、管理方式不同，它是一种激进的前卫的数据管理方式。因此，在某些细节上，甚至结果上，它都可能被人不理解，甚至遭受诟病，但无论如何，一旦你开始接受这种方式，并且将它用到多团队分离式开发中，特别是我以前公司那种，组件团队之间，将会是一种新体验。
防呆
上面给出了一个例子，可以看出得到数据a是多么的方便。然而，有一种情况不可避免，就是当a这个数据还没有被从服务器下载下来存储在仓库中时，你就开始去使用它。这种情况，在vue、react开发种随处可见。当一个组件实例化的时候，由于没有数据，所以界面上不会渲染出任何东西，为了不让用户感到困惑，往往我们会用一个条件分支，将没有数据时候的状况，展示为一个loading效果的界面。同样的道理，在datamanager思想下去思考，如果数据还没有被下载到datamanager里面，那不是要面临同样的效果吗？是的。而且就目前的情况而言，这也是无法办到的。
但是有另外一件事我们可以做，就是我们可以防止页面上同时对同一个数据源发起两次请求。这看上去是一个小问题，但是当你在两个不同的team开发，而你们开发出来的东西被用到一个application里面的时候，这个时候情况就不同了。对于一个team开发的产品，必然要求自己产品功能的完整性和可复用性，因此，当两个team开发的产品同时请求了一个源时，无论你是哪一方，都不得不在自己的产品体系内发送一个请求，这就导致了重复的请求发生。
我们回到前面所讲的，在datamanager的思想里，开发者不需要考虑“请求”这个问题，他们都是get, get, get，而不需要做任何请求相关的事情，因此，上述的问题在这种情况下根本不存在，只要保证两个team都使用了datamanager的数据管理模式，那么他们只需要get, get, get。
响应式设计
响应式设计是现代web应用的基础模式，一个web应用，不能做到在数据或状态变化的情况下自动更新界面，那么它就算不上现代。我们继续回到上面两个team在完全不知道对方的情况下进行开发的情况。假如，这两个team开发的产品，需要同一个数据源，那么，当这个数据源给出的数据发生更新时，这两个产品的界面都应该同时更新（除非处于编辑状态）。但是作为两个独立的产品，怎么可能会预测到这一点呢？只要有datamanager作为桥梁即可。那你可能会觉得，这岂不是是的独立产品耦合度很高。恰恰相反，datamanager就是为了解耦。就像你在不同的项目里面使用lodash一样，使用datamanager也是只把它当作一个依赖库，然后使用它的api，你完全不用去想还有另外一个team存在这件事。
另外一种响应可能更细节一些。当一个量依赖于另外一个量，比如 a = b + 1，有什么办法可以在b发生变化时，a也自动发生变化：
a = b + 1 b = 1 a // 2 b = 2 // b发生变化 a // 3 自动变化
这个技术叫依赖注入，其实质是在b发生变化时，b内部隐藏了一种方法，可以去修改a。那它有什么用？vue就是在用它。当一个变量依赖于另外一个变量时，它的值会随着被依赖的变量值的变化而变化，根本不需要自己再去运行一遍求值过程。这在视觉上给人非常牛逼的感觉。不过它也不是什么神秘技术，很容易分解。
这在datamanager里面也可以很好使用起来，当a = dm.get('b')时，一旦b发生变化，a也自动改变，而如果界面依赖于a，那么就可以触发某种机制去更新界面。
安装和使用
非常简单，就像一个普通的npm包一样，你只需要一条命令就可以安装datamanager了：
npm install --save datamanager.js
安装好之后，你就可以使用它。datamanager是一个类，使用时，实例化，得到一个实例，这个实例会附赠很多接口方法，这些方法可以操作（主要是获取）数据。
import DataManager from 'datamanager.js'
let dm = new DataManager(options)
function render() {
let data = dm.get(dataSourceId)
if (data === undefined) {
return
}
// 用data干点什么
}
dm.autorun(render)
这些在github上都有非常详细的介绍，这里就不再赘述，本文主要是对一些概念做介绍，防止开发者不理解而乱用。
再强调一下
datamanager里面也没有什么新概念，只不过有些点如果不加以解释，会导致使用者理解错误而带来bug。
没有请求数据的概念
虽然datamanager提供了request方法，但是不推荐使用，这个方法是为了方便初学者过渡而提供了。正确的姿势是使用get方法。把datamanager当做一个数据管理仓库，每一格存放着一个数据源的所有信息，当然也包括了最终需要的数据。注册一个数据源(datasource)就是开辟一格，这一格里面有后端服务器的url信息、一些初始化信息。当你调用get方法时，datamanager会根据你传入的id确定从哪一个拿数据给你。你可以想象在get这个过程里面，datamanager从仓库中找到一格，取出数据直接返回给你，当数据不存在时，会返回undefined。
至于datamanager如何从后端api接口去拿数据的，这对于开发者而已，可以不用了解，除非你对原理比较感兴趣，想自己研究。
没有订阅的概念
这个非常重要，订阅是开发者自己写的代码里面，通过subscribe方法，传入一个回调函数。这个回调函数，会在对应的dataSourceId的数据发生变化时执行。什么时候数据会发生变化呢？当然是datamanager通过内部机制，去后端api取新数据，把仓库里面的老数据（或没有数据）替换掉之后。一般而言，你需要在回调函数中通过get方法再去获取新数据。不过为了兼容过渡思想，回调函数的第一个参数我还是传出了新的data。但是这个data不允许被修改，绝对不允许，它仅仅用来做一些判断，而不应该作为数据使用（除非你自己深拷贝一份）。
但是！subscribe方法都不提倡使用。更推荐的方法是直接使用autorun方法。就像上文的示例代码一样，你没有看到subscribe方法，程序照样能够在数据被更新时重新执行一遍render函数。因此，要从“订阅-发布”的思维中跳出来。新的思维叫“依赖收集”。
它分为两个部分：
- autorun函数：立即运行传入的函数A
- 在函数A中使用get方法
get方法会收集所有需要的dataSource，建立一个内部机制，当这些被依赖的dataSource的数据发生变动时，就会重新执行函数A。这听上去很神奇，你没有自己创建subscribe，它是怎么做到知道哪些dataSource是函数A依赖的呢？这是一个比较大的问题，有兴趣可以去了解vue的计算属性，相信你对vue还是比较感兴趣的。
此时此刻，你应该建立新的数据使用的思维：从datamanager里面直接获取数据，通过一个函数来渲染界面，当数据源发生变化时，函数会自动重新执行，从而界面也会发生变化。你不再需要设计一整套根据条件而改变界面的逻辑了，代码会变的少不止一倍以上。在这里，你不考虑两个点：1.数据如何通过ajax请求回来，2.数据请求回来之后如何触发界面更新。
你要考虑的是，如何正确合理的编写render函数，因为autorun只需要它作为参数，非常简单，所有的难度就落在render函数的编写上了。
逻辑
前文我提到过，如果你第一次打开某个界面，而此时datamanager里面的某个datasource还没有数据，那么get方法会返回undefined。这是一种特殊的状态，面对这种状态你不能简单跳过，而需要特殊逻辑进行处理，特殊逻辑就是，在render函数中经过判断，直接return打断程序：
let somedata = dm.get(someid)
if (somedata === undefined) {
return
}
可以说，在每一个，或每一组连续的get操作之后，你都要做这样的一个逻辑，虽然有点烦人。所谓“每一组”，是说你可以这样：
let data1 = dm.get(id1)
let data2 = dm.get(id2)
if (data1 === undefined || data2 === undefined) {
return
}
但是，在没有经过判断之前，绝对不要尝试使用该数据进行某些操作，下面是错误代码示范：
// 错误代码示范
function getName() {
return dm.get('name')
}
function getAge() {
return dm.get('age')
}
function render() {
let name = getName()
let age = getAge()
document.querySelector('#text').innerHTML = name + ':' + age
}
dm.autorun(render)
看上去没什么毛病，但是你会发现，第一次页面打开的时候，name和age都是undefined，会引起一些错误。你有两种选择，一种是在getName和getAge这两个函数里面直接写上面的if逻辑，另一种是在render函数中写if逻辑，第一种是推荐的方法，因为某些情况下，getName不会像这里这样简单，可能在get操作之后还有后续动作。所以，在每一次执行dm.get()之后做逻辑判定是最合理的。
总结
datamanager给了前端一种新的写作思路，就是把数据请求完全抽离开开发，假定数据已经存在直接写作。从某种角度讲，这种思路是一种将异步操作改为同步操作的方法。
2018-01-07 4082
