唐霜的博客

“前端数据治理“这个知乎栏目，我打算从另一个纬度去讨论前端应用开发。这个栏目的核心话题都是围绕“业务”这个词。之所以要再强调，是因为有少数朋友在阅读时，思路会跑偏，用非本栏目讨论范围内的内容进行无意义的互怼，我觉得没有必要。任何阅读和讨论，一定需要一个前置条件，本栏目的前置条件就是“业务型应用开发“。在这类场景中，由于业务本身的流转逻辑复杂，流转过程中不同的对象状态变化相互之间还存在关联性，所以开发过程中往往比较痛苦，这也是我开这个栏目，梳理这些开发问题，以帮助需要相关思路的开发者获得参考的初衷。

本文主要讨论“元数据”这个话题。“元数据”的简单定义就是“关于数据的数据”，直白的说，就是关于值本身的描述的集合。对应到开发中，就是表结构，我们在设计数据库表时，需要对每个字段的类型、长度、默认值等进行规定，这些内容，就是关于这个字段的值的元数据。

和后端开发不同，前端是面向交互编程，因此，和后端相比，前端建模更多是为了给视图交互服务。

现在，我们进入到具体的场景进行“元数据”的讨论。我们现在有一个简单的商城系统，商城系统的核心对象有三个：消费者（用户）、商品、订单。围绕这三个核心对象，商城的整套业务流转在运行。现在，我们要为商品建模了，我们来想一想，在那些业务环节（交互过程中）会需要商品？

• 商品的上架（一个提交表单）
• 商品信息的修改（一个修改表单）
• 商品的展示（商品详情页）
• 商品的引用（下单过程中，订单拉取商品部分信息进行展示或计算）

有人会说，用户已购买的商品也是，但我想说，用户已购买的商品和我们这里的核心对象商品是不同的，用户已购买的商品属于订单的子对象，用户下单买完之后，订单当时商品的信息是固定到订单信息中，相当于对商品对象进行了主要信息的克隆，和这里的核心对象商品已经脱钩了。

综合上面的这些情况，实际上，我们面临的交互主要有两个：1）表单 2）展示。

在考虑设计“商品”这个对象的元数据时，我们要分开上面两种场景进行设计。当然，对于我而言，我虽然是从两种场景去设计，但是我在模型中将所有的元数据集中在一起，在两种场景下都可以使用该模型。

接下来，我们来看商品价格这个字段。

我们先考虑展示的时候这个字段要准备哪些可能需要的东西：

• 样式类：字体大小、颜色等
• 值类：保留多少位小数，前面是否加¥等货币符号
• 名类：“价格”这个词，是否需要区分当前系统是中文和英文
• 格式类：是否需要千分位分隔符，或者根据用户所在国家进行数字格式化

你看，我们一下子就让价格这个字段丰富起来了。上面这些都是我能想到的，但不一定全。不同的电商系统中，这些东西估计都是需要的，所以，实际上，我们已经总结出“价格”这个字段的通用“元数据”了。

那么，具体在编程上怎么去实现呢？我在 tyshemo 中定义了 Meta 类，该类其实是一个抽象类，用于定义元数据。现在，我们尝试定义一下价格这个字段：

import { Meta } from 'tyshemo'

class Price extends Meta {
  static name_zh = '价格'
  static name_en = 'Price'
  static font_size = 18
  static font_color = '#660000'
  static formatter = pipe(
     thousands, // 千分位分隔符
     fixed(2), // 保留两位小数
     currency, // 我自己写了一个currency函数来自动添加货币符号
  )
}

你看，我们已经定义了 Price 的不少元数据了。

接下来，我们来看看表单中的情况。表单，我一直一来都认为是前端开发中，最复杂的场景之一，因为它要处理的东西实在有点多。不过对于价格这个字段，我们感知上应该还好，不会有特别复杂的逻辑。

• 是否必填？
• 是否只读？（某些情况下，一经发布，不允许修改商品价格）
• 是否隐藏？
• 是否禁用？
• 提交到后端时是 price 字段，还是 good_price 字段？
• 最大值/最小值？
• 用户填写的时候是否需要千分位格式化？（这个就有点难度了）
• 真实值和用户看到的值是否一致（是否需要省略小数部分）？
• 校验逻辑？（这个应该是表单标配）

你看，Price 瞬间就又复杂了很多不是吗？这些都不是全部的，我只把自己所能想到的都列了出来。现在看看代码实现：

import { Meta, Validator } from 'tyshemo'

const { max, min, required } = Validator

class Price extends Meta {
  static required = true
  static readonly = function() {
    return this.is_expired // 模型上的 is_expired 字段为 true 时，价格只读，不能被修改
  }
  static setter = v => v === '' ? 0 : +v
  static getter = v => v === 0 ? '' : v + '' // 当价格为 0 时，输入框为空
  static validators = [
    required('价格必须填写'),
    min(0), // 不能小于 0
    max(9999999),
  ]
  static to = 'good_price' // 传给后端时使用 good_price 字段
  static is_need_thousands = true // 给一个标记，由视图层处理交互逻辑
}

表单中可能还会有其他的一些限制，总之，我们尽可能覆盖到各种场景，并在 Meta 中提前定义好这些元数据。当然，有的时候，在元数据中，有些定义是比较抽象的，比如上面的 is_need_thousands 这个属性，如果单纯看它，从字面意思确实可以理解，意思是需要千分位分隔符，但是问题在于，具体怎么实现呢？所以，这里就比较抽象，它实际上是前端约定好的一套交互协议，如果 meta 中 is_need_thousands 为 true，那么我们在前端视图层实现时，就会采用一个特殊的数字输入框组件，这个组件自带了方便的千分位分隔符能力。但是，对于非前端人员，阅读到这里，就会存在一定的理解障碍。这也是属于前端私有的领地。

另外，我们可能还会在元数据中定义一些其他的属性：

• 数据类型是什么？
• 后台接口中，如何获取 price 字段的值？是直接读 data.price 还是读 data.good_price？
• 在什么情况下不需要上传这个字段？
• 当这个字段的值发生变化时，是否需要执行某个函数？

这些属性的定义，都可以通过 tyshemo 这套系统来实现。

我们回到元数据这个话题。我在读大学的时候，我们管理学领域有一门分支学科，叫“信息资源管理”，里面提到一个论点，“管理要超前到信息产生之前“，也就是说对信息的管理，要在信息产生之前就进行，这叫“超前管理”。怎么做到超前管理呢？就是事先定义好元数据系统。当然，真正的工作并非那么简单，但是，从中可以看到，元数据是保证我们业务逻辑按照我们预先设计的规则进行的。

最近接到一个新的需求，我们要统一规划系统中所有字段的基本逻辑，包括所有字段的中英文、展示格式（一个字段可能多套）、校验规则等。这是一个复杂的需求，最理想的状态是做成一套线上系统，有点像 Headless CMS，可以自己对字段进行自定义。这个需求本身是复杂的，但我们单纯从前端角度来看，这个需求实际上可以为前端提供丰富的元数据，一旦这些规则都是定义好的，我们就可以通过一种协议，从后端拉取有关这个字段的元数据，获得该字段的所有规则，这有助于我们统一化前端字段的展示和编辑逻辑，完成之后，前端不需要自己再手写各种各样的校验逻辑，不需要再用像素眼盯着屏幕检查是否按照设计要求展示字体、颜色，有了这套系统，前端实际上代码量会下降一个量级（当然，实际上，复杂度提升了很多，对于那些反复强调“到时候新人看不懂”的团队，不适合拥有这类系统）。

我写《前端数据治理之道》围绕一个中心词汇：业务。但我在一些文章的评论中收到“业务交给后端去处理，前端做展示就好了”类似如此的思想。这类思想我个人的理解，更多是站在后端开发者的角度看问题，因此，我打算写一篇文章，专门讨论什么是业务逻辑。

很明显，在部分场景下，前端是不可能只做展示的，随着B端、G端产品的强势，这种“前端只做展示”的应用架构已经不符合需求了。我观察到，业务在开发层面有两种存在形式：数据的业务，人机交互的业务。站在后端开发的角度，只看到第一种，但在实际开发中，前端开发需要兼顾两种业务，而且，很大程度上后一种需要以前一种为基础。

数据的业务由持久化数据和逻辑代码构成，基于这两个基础，可能还需要搭配各种系统来实现，例如需要消息通知系统来在每一个业务节点上推送催办消息给特定用户，例如需要利用定时任务系统来拉取第三方数据，例如需要队列服务来解决长串任务堆叠。总之，我们传统的后端系统基本上只关注这一层面的业务。

在前端，基于数据的业务也同样存在，举个例子，我们做了一套数据视图系统，对于用户而言，他们可以通过挑选几个字段的所有数据进行统计，并为了研究不同因子变化带来的结果变化，直接修改某些值来进行计算结果。很显然，这里用户进行的这些操作不会对线上数据库产生任何影响，因此也就不需要向后端提交数据。这些数据被存在客户端内存中，一旦用户离开这个界面，这些临时数据就可以销毁。如果按传统做法，前端必须将一大堆数据post到后端接口，由接口返回计算结果，然后再由前端来渲染。但是很明显，相同的计算在前后端执行得到的结果是一样的，而传统方式还要付出网络交互和前后端耦合的代价，而这类计算仅仅当前这个用户用到一次，不需要持久化，交给后端处理，还要让后端考虑性能、并发等风险。可见，这一业务虽然是数据业务，却可以在前端完成。

交互的业务是本专栏要关注的重点。人机交互大发展是当代计算机系统发展的重要一面，如果只重视数据业务而不关注人机交互，那么丑陋的命令行模式就可以完成大部分计算任务。但是如所有人所见，如今的业务系统需要用户在一个界面，结合界面上呈现的多维信息，完成不止一个操作。而且为了提升用户体验，产品设计人员想尽一切办法，让用户明晰每一个操作的作用，避免做了错误操作。现代应用的交互复杂度，以及交互后面所蕴含的业务逻辑，有时，让人望而生畏。

业务的逻辑，表面上可以用一大堆if…else来概括，但实际上除了判断之外，它还可能涉及形式。

很多人对“形式”这个词不敏感，但如果你研究过形而上学或符号学，就会不再那么轻松。形式在交互中极为重要，我们用一个具体的场景来解释。

现在有一个表单，里面有一个输入框，该输入框对应的字段，需要关联到系统中已有的某个对象，但也有可能用户不选择关联，使用输入的值作为结果。而如何用户选择使用输入的值作为结果，那么就有可能输入一个系统中已经存在的对象，而该字段的规则是不允许系统中有重复值。在这个场景中，是暂时没有数据参与的，也就是说，它的整个业务必须依靠前端来实现。

除了单点的复杂交互业务之外，还有连续的流程交互业务。以一个审批流为例，一个审批单发起、审批A、审批B、结项，这个流程环节必须走。暂不考虑流程分支流问题，后端自有后端的方式交互这一审批流管理起来，现在我要问的是，前端做了什么来合理管理流程业务？是只展示后端输出的内容，还是自己构建了一套流程模型？

现在我们再来看看什么是业务逻辑。

实际上，我们口口声声的业务逻辑，是只用代码实现的真实业务的规则映射。注意“规则”这个词，简单说，一个业务中，存在什么逻辑，可以通过在纸上画出不同业务对象之间的联系和约束，并将这些联系和约束一条条列出来，形成一个列表，而这列表中的每一条，就是一条规则，这些规则的总和，就是这个业务的业务逻辑，而且是全部业务逻辑，你不能再多列出一条了。

既然是一条条的规则，那么我们就可以在代码层面对规则进行管理。对于前端开发者来说，最熟悉的规则管理，莫过于路由管理。现在，我们做一个思想实验，将每一个route对应一条业务规则，每一个url对应某一时刻后端接口输出的业务数据，随着后端接口业务数据的变化，不同的业务规则会被使用，而没有匹配到的规则会被屏蔽，从而，在界面上呈现出根据业务逻辑而提供对应的人机交互的效果。

由于规则是有限的，我们可以借鉴有限状态机的开发范式来实现对业务逻辑的开发。有限状态机，很好的为我们提供了在不同规则之间转换的一种思路。当业务从一个状态切换到另一个状态时，可以很清晰的获取当前状态，以及下一步我可以做什么。业务切换也是这样，我们明确当前可以做什么，也知道下一步可以做什么，到具体要做什么，要看用户做了什么操作。

但和有限状态机不同，业务流转并不是状态切换，每一次流转，都可能牵涉一堆东西，例如从一个阶段进入下一个阶段，参与业务的业务对象变了，我讲过，业务流程是实体的进出和状态变化的总和，所以单纯靠有限状态机是解决不了的，但我们可以借鉴状态机切换状态的这个切换编程模式。

由于我并没有将所描述的这套东西实现成框架或库，所以无法再具体到细节处。

最后，前端处理业务逻辑不仅不是多余，而是当下复杂应用的趋势和要求。目前而言，前端领域还没有强大的针对这个领域的库或框架，因此，需要我们积极探索，重拾软件设计的技术体系，寻找更多可能性。

在我看来，前端数据问题分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，通过我后续的文章了解相关的内容。