“前端数据治理“这个知乎栏目，我打算从另一个纬度去讨论前端应用开发。这个栏目的核心话题都是围绕“业务”这个词。之所以要再强调，是因为有少数朋友在阅读时，思路会跑偏，用非本栏目讨论范围内的内容进行无意义的互怼，我觉得没有必要。任何阅读和讨论，一定需要一个前置条件，本栏目的前置条件就是“业务型应用开发“。在这类场景中，由于业务本身的流转逻辑复杂，流转过程中不同的对象状态变化相互之间还存在关联性，所以开发过程中往往比较痛苦，这也是我开这个栏目，梳理这些开发问题，以帮助需要相关思路的开发者获得参考的初衷。
本文主要讨论“元数据”这个话题。“元数据”的简单定义就是“关于数据的数据”，直白的说，就是关于值本身的描述的集合。对应到开发中，就是表结构，我们在设计数据库表时，需要对每个字段的类型、长度、默认值等进行规定，这些内容，就是关于这个字段的值的元数据。
和后端开发不同，前端是面向交互编程，因此，和后端相比，前端建模更多是为了给视图交互服务。
现在，我们进入到具体的场景进行“元数据”的讨论。我们现在有一个简单的商城系统，商城系统的核心对象有三个：消费者（用户）、商品、订单。围绕这三个核心对象，商城的整套业务流转在运行。现在，我们要为商品建模了，我们来想一想，在那些业务环节（交互过程中）会需要商品？
- 商品的上架（一个提交表单）
- 商品信息的修改（一个修改表单）
- 商品的展示（商品详情页）
- 商品的引用（下单过程中，订单拉取商品部分信息进行展示或计算）
有人会说，用户已购买的商品也是，但我想说，用户已购买的商品和我们这里的核心对象商品是不同的，用户已购买的商品属于订单的子对象，用户下单买完之后，订单当时商品的信息是固定到订单信息中，相当于对商品对象进行了主要信息的克隆，和这里的核心对象商品已经脱钩了。
综合上面的这些情况，实际上，我们面临的交互主要有两个：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，可以自己对字段进行自定义。这个需求本身是复杂的，但我们单纯从前端角度来看，这个需求实际上可以为前端提供丰富的元数据，一旦这些规则都是定义好的，我们就可以通过一种协议，从后端拉取有关这个字段的元数据，获得该字段的所有规则，这有助于我们统一化前端字段的展示和编辑逻辑，完成之后，前端不需要自己再手写各种各样的校验逻辑，不需要再用像素眼盯着屏幕检查是否按照设计要求展示字体、颜色，有了这套系统，前端实际上代码量会下降一个量级（当然，实际上，复杂度提升了很多，对于那些反复强调“到时候新人看不懂”的团队，不适合拥有这类系统）。
