datamanager.js 基于observer思想的数据管理器

0

原文载于我的博客 http://www.tangshuang.net/381...

这里主要探讨一下怎么把数据请求从业务代码中抽象出来。

传统的数据请求方式是我们在具体的业务代码,或某些特定的逻辑代码(例如redux的action)中手工写一个ajax,无论是使用最新的fetch api,还是使用axios,都是在直接构建一个请求发送器和控制请求过程。当然,这是比较容易理解的,任何人单独看这段代码都能读懂。

但是在很多项目中,请求往往都越来越固定,总的和backend打交道的api估计不超过20个,所以我们尝试把所有的请求封装在一个services文件夹里面,形成一个独立的module,请求某个数据的时候,我们调用这个module的某个api。这种操作比前面的方式显然上升了一个层面。

但是,我们会遇到问题。当应用中的两段代码,同时使用了一个service,如果不加处理,就会导致同一个页面,同一时间,对一个backend api发出两个相同的请求。这种情况在我之前的项目中经常出现:一个页面里面有两个组件的实例。之前想到了使用cache,当一个请求发出的时候,发现参数都没变,那么直接把cache的数据返回好了,这样还可以提高数据请求的性能。然而,这完全没有解决掉问题,因为当第一次数据请求的时候,cache是没有的,两个请求还是会同时发出。后来想到,把这请求的promise缓存起来,当第一个请求发出之后,第二个请求准备发之前,先去检查cache列表中存不存在同请求的promise,如果存在,直接返回这个promise,这样,当这个promise成功的时候,两个地方的then都被触发了。

接下来,我们发现还有另外一种需求,当一个页面里面同一个组件渲染了两个实例的时候,一个实例请求到新数据,我们还希望另一个实例也可以得到这个数据,至于是否刷新界面,可以由程序来决定。这是非常好的准备使用观察者模式的场景。

观察者模式,简单的说,就是“订阅-分发”模式,观察者(订阅者)subscribe一个或多个特定订阅,当被订阅的内容发生变化时,发布者便把这些变化分发给订阅者。之所以叫观察者,是因为当观察者本身并不做任何和订阅内容相关的工作,只处于一个干自己的事,但是时时刻刻盯着自己订阅的内容,一旦收到订阅通知时,马上干对应的事。

上面的场景就是这样一种场景。我们需要独立出一个观察者,这就是datamanager,它接受来自页面内两个实例的订阅,当其中一个订阅者通过datamanager的api触发了数据请求,导致两个实例订阅的相同内容发生改变时,datamanager将新的内容同时分发给这两个实例。

看上去非常简单的逻辑,实现起来却不那么简单。索性你可以通过这里直接阅读源码来了解我是怎么实现的。

使用datamanager也很简单:

npm install --save datamanager.js

然后在你的代码中使用它:

import DataManager from 'datamanager.js'

const datamanager = new DataManager()
datamananger.register([ ...datasources ]) // datasource请阅读文档

datamanager.subscribe('datasourceId', (data) => {
  // 这里可以执行ComponentB的重新渲染动作
})

在另外的代码中可以通过request来获取数据:

// ComponentA里面执行
async () => {
  let data = await datamanager.request('datasourceId') // 当数据回来时,上面的subscribe里的回调函数会被执行
  // 用data做点事
}

datamanager提供来subscribe来进行订阅,只需要在subscribe的第二个参数中告诉datamanager,对应的datasourceId数据回来之后,自己要做什么就可以了。

回头再来看datamanager,你就发现,它不需要你告诉单次请求的url,而是把url通过datasource注册进去,它的本意就是,这个datasource可能会反复使用,因此你只需要记住它的id即可。这和我们传统的request就开始有些不同了。

request方法是完全按照传统请求返回promise的思想设计的,真正的datamanager的思想精髓,是在于它提供的get方法,当你熟悉datamanager的操作之后,开始使用get方法,而完全忘掉request方法的时候,你会发现,datamanager中完全没有数据请求的概念。它提供了一种新的思路:对于一个应用,和backend api打交道的部分被抽象出来,应用只从datamanager获取数据,而不关心它是怎么从backend拿到数据的

对于应用而言,datamanager就在那里,你通过register注册datasource之后,就只管找它要数据就是了,要数据,给数据,要数据,给数据。后端?我不管你怎么从后端拿数据,反正我只知道数据应该在你那里。它就像一个data center,管理着前端数据。但同时,它又是observer,为实现数据在不同实例间的实时共享提供了便利。

这里可以透露一下,datamanager内部是用axios请求数据,但是对于开发者而言,不需要知道(还是需要知道axios的response结构的,如果有需要的话)。当然,这里需要说明的是,backend还是在的,只是你把backend的信息放到了datasource中,一次性注册进了datamanager。

总而言之,datamanager是对前端数据请求的一次提炼,这种提炼把前端负责的分散的数据请求代码规整化,把datasource集中管理,在代码中,不考虑请求这个动作,而是从datamanager中直接拿一个数据,拿到的是什么就是什么,不需要质疑。注意“直接”这个词,“不考虑请求”的意思是说“未来的前端没有代码层面的ajax”,只需要拿数据,只需要拿数据。

你可能感兴趣的

载入中...