在我看来，前端数据问题分3个层次，分别是：

• 原始数据请求
• 数据请求抽象
• 数据源管理抽象

我们通过Restful API也好，websocket也好，或者本地缓存也好，都可以获得一些数据。但这些数据的获取和使用，如何在项目中具有更优雅的设计，至今我还没有看到满意的答案。我在《漫谈前端数据层》一文中提出，可以在前端借鉴数据仓库的概念，设计可以从我们常见的react数据请求编码方式中解脱出来的方案。不过在那篇文章中，对获取数据的这个环节的思考并不非常成熟。这篇文章表达我经过思考后，对这一问题的最终解答。

我们常见的做法，有两种，一种比较原始，直接在react组件中使用axios等库发出请求，请求回来后通过setState把数据拿来使用。另一种结合状态管理器，在独立的模块文件中，把相关的接口全部集中起来，形成一堆基于axios的async函数，并在状态管理器中调用这些函数，用到thunk、saga之类的工具来实现状态异步更新。这两种方式在我看来，都是原始方案。

所谓“原始”，就是直接按照ajax请求的思维，把最底层的xhr通过一层封装暴露出来，在使用时，需要遵循axios等库的细节，思维层面仍然是发出xhr之后等待接口返回结果的思维。它的问题在于，它只解决了ajax请求本身的问题，而如果你需要对数据进行处理、检查，或者对数据有什么要求，就需要自己解决。而之所以说“原始”，就是因为解决这些数据问题，都是散落在各个组件内，或者集中在一个文件的async函数内，每个地方都有类似的痕迹。而使用的人在通过浏览器devtool看数据时，并不清楚你真实处理成了什么数据。总而言之，原始数据请求的方式，就是看上去好像有封装，本质上和最早写xhr没有本质区别。

往上一层，我们要屏蔽这种底层的xhr编程方式。也就是我们要抽象数据请求本身。这听起来比较绕，但你一开始可以理解为，我们要做一层封装，把xhr的那种请求方式隐藏起来，让我们像做某种无感知的操作一样。我写了一个库专门做这一层，你可以了解一下我发明的这套ScopedRequestLanguage。它的核心思想是“把请求进行描述”。当你看到“描述”这个词的时候，你往往就会把它和“抽象”联系在一起。描述的内容总是静态的，但是基于这些静态的东西，我们却可以一眼了解关于该请求的细节，甚至在脑海中勾勒出一个场景发生时，具体将会出现什么状况。

我们用一个例子来解释。现在，我有这样一段描述：

GET "/api/xxx" -> {
  name: string;
  price: number;
  total: number;
}

你看，这段描述你是可以读懂的吧，我想但凡做过web开发的前后端程序员都能读懂这段代码。它是讲“你用一个GET请求/api/xxx接口时，将会得到一个含有name, price, total字段的数据对象“。我们基于描述来执行请求，演示代码如下：

const data = await requester.run(`
  // 上面的描述文本
`)

我们通过抽象请求本身，把请求转化为描述文本，进而实现屏蔽底层xhr请求的林林总总。而描述的作用就非常多，除了能够准确的获得需要的数据之外，它还可以被转化为用以检测后端接口是否按照既定规则给数据的检查器，也可以在前后端同学之间共同阅读，从而建立起更好的沟通模式。

虽然通过描述我们屏蔽了底层发出请求的细节，然而，这远远不够，因为它在屏蔽底层细节的时候，并没有屏蔽数据请求这个过程。

再往上一层，我们要屏蔽数据请求过程本身。我们要抽象的，是数据源本身。前端消费数据，虽然大部分来自Restfull API，但时常也需要从localStorage等其他地方拉取数据。单从从API请求数据而言，我们仍然需要谨慎的理解，“数据是不是还在请求？”，“数据回来了吗？”，“后端是不是出问题了？”等等类似的问题。我们要做的，就是屏蔽这些问题。

我们把数据源进行抽象后，对于数据的消费者，也就是业务代码的撰写者，思维上是消费数据，而不是请求数据。两个字的差别，就是一次思维上的飞跃。我们把数据源抽象为一个看不到内部细节的球，现在，我们要消费数据，于是我们向球说“我要你的数据”，于是它就把数据给你了。至于它的数据来自哪里，你并不需要关心，它向你屏蔽了数据请求的细节。

我们还是用代码来举例，假如我们现在有一个数据源叫做ProjectDataSource ，现在我们要消费这个数据源的数据，我们只需要：

const data = dataRepo.get(ProjectDataSource)

此时，你得到的data就是你需要的数据。你可能会想“咦，我没看到你请求数据呀？你这个数据准不准确哦？”。这是你在用上一层的思维思考问题。你现在需要升级你的思维，你不要关心数据源内部的数据是怎么来的，就是是上帝说要有数据然后就凭空出现了数据，你也不要关心。你要关心的是，它给的数据，是否是按照我们的约定来给的，此时，你需要用上typescript。

const data: IProjectData = ...

也就是说，对于你来说，只要它给你的数据符合你对数据类型的要求，那么你管他数据是哪里来的，你就认为这数据是合法的就好了，至于数据的准确性，你需要交给提供数据源的抽象引擎来做。这个抽象引擎解决你所考虑的所有问题。而你只需要消费这个数据即可。

好了，现在，让我们进入到球的内部，看看球里面到底发生着什么。

一个数据源的建立，最底层，还是要走ajax那一套，只是说，我们这些底层的东西，被提前封印在球内了。球内代码大致如下：

const defaultValue: IProjectData = { ... }
const ProjectDataSource = dataRepo.source(async () => {
    const data: IProjectData = await requester.run(`
        // 上面的描述文本
    `)
    return data
}, defaultValue)

我们用上了第二层的抽象。但是它只负责请求的部分，而构成数据源的，除了请求，实际上还可以加入其他很多东西，例如缓存，你可以在第一个函数中加入一些缓存的逻辑，你也可以在这里对数据进行检查和提示。同时，它的第二个参数是默认值，就像 [state, setState] = useState(0) 在默认状态时为0一样，这个默认值保证了数据源在没有发出请求时，也是可用的，不会对界面造成破坏。

我在几年前写了一个叫databaxe的库，专门去做类似的数据源管理，前年在思考了很久之后，写了一个叫algeb的库，借鉴hooks的思维重新整理了这一整套数据源管理的逻辑。你可以通过这个库的思想，去窥探这一层次的内容。数据请求和数据管理是两码事，你一定要把他们分开，在你的项目中，应该更看重数据管理，因为数据管理的方式会通过抽象，屏蔽它底层的请求细节，让你的开发，具有“将不同的对象串联起来“的特征。

这就是我关于前端数据源的一些思考。当然，其实还有一点比较重要，就是你需要把3层的东西，结合到你的项目中去使用，而不是独立于你项目之外运行。我在我们项目中深度实践了这种抽象和整合，你可以关注本专栏，或者我的微信wwwtangshuangnet，通过我后续的文章了解相关的内容。