“前端数据治理“这个知乎栏目,我打算从另一个纬度去讨论前端应用开发。这个栏目的核心话题都是围绕“业务”这个词。之所以要再强调,是因为有少数朋友在阅读时,思路会跑偏,用非本栏目讨论范围内的内容进行无意义的互怼,我觉得没有必要。任何阅读和讨论,一定需要一个前置条件,本栏目的前置条件就是“业务型应用开发“。在这类场景中,由于业务本身的流转逻辑复杂,流转过程中不同的对象状态变化相互之间还存在关联性,所以开发过程中往往比较痛苦,这也是我开这个栏目,梳理这些开发问题,以帮助需要相关思路的开发者获得参考的初衷。
本文主要讨论“元数据”这个话题。“元数据”的简单定义就是“关于数据的数据”,直白的说,就是关于值本身的描述的集合。对应到开发中,就是表结构,我们在设计数据库表时,需要对每个字段的类型、长度、默认值等进行规定,这些内容,就是关于这个字段的值的元数据。
和后端开发不同,前端是面向交互编程,因此,和后端相比,前端建模更多是为了给视图交互服务。
现在,我们进入到具体的场景进行“元数据”的讨论。我们现在有一个简单的商城系统,商城系统的核心对象有三个:消费者(用户)、商品、订单。围绕这三个核心对象,商城的整套业务流转在运行。现在,我们要为商品建模了,我们来想一想,在那些业务环节(交互过程中)会需要商品?
- 商品的上架(一个提交表单)
- 商品信息的修改(一个修改表单)
- 商品的展示(商品详情页)
- 商品的引用(下单过程中,订单拉取商品部分信息进行展示或计算)
有人会说,用户已购买的商品也是,但我想说,用户已购买的商品和我们这里的核心对象商品是不同的,用户已购买的商品属于订单的子对象,用户下单买完之后,订单当时商品的信息是固定到订单信息中,相当于对商品对象进行了主要信息的克隆,和这里的核心对象商品已经脱钩了。
综合上面的这些情况,实际上,我们面临的交互主要有两个: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 这套系统来实现。
TySheMotyshemo.js.org我们回到元数据这个话题。我在读大学的时候,我们管理学领域有一门分支学科,叫“信息资源管理”,里面提到一个论点,“管理要超前到信息产生之前“,也就是说对信息的管理,要在信息产生之前就进行,这叫“超前管理”。怎么做到超前管理呢?就是事先定义好元数据系统。当然,真正的工作并非那么简单,但是,从中可以看到,元数据是保证我们业务逻辑按照我们预先设计的规则进行的。
最近接到一个新的需求,我们要统一规划系统中所有字段的基本逻辑,包括所有字段的中英文、展示格式(一个字段可能多套)、校验规则等。这是一个复杂的需求,最理想的状态是做成一套线上系统,有点像 Headless CMS,可以自己对字段进行自定义。这个需求本身是复杂的,但我们单纯从前端角度来看,这个需求实际上可以为前端提供丰富的元数据,一旦这些规则都是定义好的,我们就可以通过一种协议,从后端拉取有关这个字段的元数据,获得该字段的所有规则,这有助于我们统一化前端字段的展示和编辑逻辑,完成之后,前端不需要自己再手写各种各样的校验逻辑,不需要再用像素眼盯着屏幕检查是否按照设计要求展示字体、颜色,有了这套系统,前端实际上代码量会下降一个量级(当然,实际上,复杂度提升了很多,对于那些反复强调“到时候新人看不懂”的团队,不适合拥有这类系统)。
有关元数据的讨论暂且就到这里,相信你读完本文都有一些想法,不妨在本文下发和我一起讨论。欢迎关注知乎专栏“前端数据治理之道”,我们一起思考和讨论前端数据处理、管理和治理的各种办法。
![e033af08b085b20e732941e7e4700b2e.png](https://i-blog.csdnimg.cn/blog_migrate/799629f72f76c29d2ce8866c3c555fbe.png)
作者:否子戈
公众号:wwwtangshuangnet
版权所有,禁止转载