无论你用 React，Vue，还是 Angular，你还是要一遍一遍写相似的 CRUD 页面，一遍一遍，一遍一遍，一遍又一遍……
“天下苦秦久矣”～～
现在的前端开发，我们有了世界一流的 UI 库 React，Vue，Angular，有了样式丰富的 UI 组件库 Tea (腾讯云 UI 组件库，类似 Antd Design)， 有了方便强大的脚手架工具(例如，create react app)。但是我们在真正业务代码之前，通常还免不了写大量的样板代码。
现在的 CRUD 页面代码通常：
太轻的“Model”或着“Service”，大多时候只是一些 API 调用的封装。
胖”View“，View 页面中有展示 UI 逻辑，生命周期逻辑，CRUD 的串联逻辑，然后还要塞满业务逻辑代码。
不同的项目业务逻辑不同，但是列表页，表单，搜索这三板斧的样板代码，却要一遍一遍占据着前端工程师的宝贵时间。
特别是 CRUD 类应用的样板代码受限于团队风格，后端 API 风格，业务形态等，通常内在逻辑相似书写上却略有区别，无法通过一个通用的库或者框架来解决（上图中背景越深，越不容易有一个通用的方案）。
说好的“数据驱动的前端开发”呢？
对于这个“痛点”——怎么尽可能的少写模版代码，就是本文尝试解决的问题。
我们尝试使用 JavaScript 新特性<code>Decorator</code>和<code>Reflect</code>元编程来解决这个问题。
从 ECMAScript 2015 开始，JavaScript 获得了 <code>Proxy</code> 和 <code>Reflect</code> 对象的支持，允许你拦截并定义基本语言操作的自定义行为（例如，属性查找，赋值，枚举，函数调用等）。借助这两个对象，你可以在 JavaScript 元级别进行编程。MDN
在正式开始之前，我们先复习下<code>Decorator</code>和<code>Reflect</code>。
这里我们简单介绍 Typescript 的<code>Decorator</code>，ECMAScript 中<code>Decorator</code>尚未定稿，但是不影响我们日常的业务开发(Angular 同学就在使用 Typescript 的<code>Decorator</code>)。
简单来说，<code>Decorator</code>是可以标注修改类及其成员的新语言特性，使用<code>@expression</code>的形式，可以附加到，类、方法、访问符、属性、参数上。
TypeScript 中需要在<code>tsconfig.json</code>中增加<code>experimentalDecorators</code>来支持：
比如可以使用类修饰器来为类扩展方法。
Reflect 是 ES6 中就有的特性，大家可能对它稍微陌生，Vue3 中依赖 Reflect 和 Proxy 来重写它的响应式逻辑。
简单来说，<code>Reflect</code>是一个人内置的对象，提供了拦截 JavaScript 操作的方法。
Reflect Metadata 是 ES7 的一个提案，Typescript 1.5+就有了支持。要使用需要：
<code>npm i reflect-metadata --save</code>
在 <code>`tsconfig.json`</code> 里配置 <code>`emitDecoratorMetadata`</code> 选项
简单来说，Reflect Metadata 能够为对象添加和读取元数据。
如下可以使用内置的<code>design:key</code>拿到属性类型：
回到正题——使用 Decorator 和 Reflect 来减少 CRUD 应用中的样板代码。
CRUD 页面无需多言，列表页展示，表单页修改 ……包括 API 调用， 都是围绕某个数据结构(图中<code>Person</code>)展开，增、删、改、查。
基本思路很简单，就像上图，Model 是中心，我们就是借助<code>Decorator</code>和<code>Reflect</code>将 CRUD 页面所需的样板类方法属性元编程在 Model 上。进一步延伸数据驱动 UI的思路。
借助 Reflect Matadata 绑定 CRUD 页面信息到 Model 的属性上
借助 Decorator 增强 Model，生成 CRUD 所需的夜班代码
下文，我们用TypeScript和React为例，组件库使用腾讯Tea component 解说这个方案。
首先我们有一个函数来生成不同业务的属性装饰函数。
一个类装饰器，处理通过数据装饰器收集上来的元数据。
TypeScript 项目中第一步自然是将后端数据安全地转换为<code>type</code>，<code>interface</code>或者<code>Class</code>，这里 Class 能在编译后在 JavaScript 存在，我们选用<code>Class</code>。
重点在<code>handle?: string | ServerHandle</code>函数，在这个函数处理 API 数据和前端数据的转换，然后在<code>constructor</code>中集中处理。
列表页中一般使用 Table 组件，无论是 Tea Component 还是 Antd Design Component 中，样板代码自然就是写那一大堆 Colum 配置了，配置哪些 key 要展示，表头是什么，数据转化为显示数据……
首先我们收集 Tea Table 所需的<code>TableColumn</code>类型的 column 元数据。
然后在 EnhancedClass 中收集，生成 column 列表。
自然我们封装一个更简易的 Table 组件。
<code>getConfigMap<T>(F: any, cachekey: symbol,metaKey: symbol): Map<string,T></code> 收集元数据到 Map
<code>static getColumns<T>(): EnhancedTableColumn<T>[]</code> 得到 table 可用 column 信息。
效果很明显，不是吗？ 7 行写一个 table page。
表单，自然就是字段的 name，label，require，validate，以及提交数据的转换。
Form 表单我们使用Formik + Tea Form Component + yup(数据校验)。Formik 使用 React Context 来提供表单控件所需的各种方法数据，然后借助提供的 Field 等组件，你可以很方便的封装你的业务表单组件。
照猫画虎，我们还是先收集 form 所需的元数据
有了元数据，我们可以在 EnhancedClass 中生成 form 所需：
initialValues
数据校验的 validationSchema
各个表单组件所需的，name，label，required 等
提交表单的数据转换 handle 函数
上文包含了不少的代码，但是大部头在如何将元数据转换成为页面组件可用的数据，也就是元编程的部分。
而业务页面，7 行的 Table 页面，40 行的 Form 页面，已经非常精简功能完备了。根据笔者实际项目中估计，可以节省至少 40%的代码量。
写到尾声，你大概会想到某些配置系统，前端 CRUD 这个从古就有的需求，自然早就有方案，用的最多的就是配置系统，在这里不会过多讨论。
简单来说，就是一个单独的系统，配置类似上文的元信息，然后使用固定模版生成代码。
思路实际上和本文的元编程类似，只是元编程成本低，你不需要单独做一个系统，更加轻量灵活，元编程代码在运行时，想象空间更大……
上面只是 table，form 页面的代码展示，由此我们可以引申到很多类似的地方，甚至 API 的调用代码都可以在元编程中处理。
元编程——将元数据转换成为页面组件可用的数据，这部分恰恰可以在团队内非常好共享也需要共同维护的部分，带来的好处也很明显：
最大的好处自然就是生产效率的提高了，而且是低成本的实现效率的提升(相比配置系统)。一些简单单纯的 CURD 页面甚至都不用写代码了。
更易维护的代码:
“瘦 View“，专注业务，
更纯粹的 Model，你可以和 redux，mobx 配合，甚至，你可以从 React，换成 Angular）
最后更重要的是，元编程是一个低成本，灵活，渐进的方案。它是一个运行时的方案，你不需要一步到罗马，徐徐图之 …… - ……
前端元编程，较少你的样板代码，加速前端开发