Form表单方案思考

在之前的field-form源码解析和Formik源码解析 表单源码梳理中,在第三弹中原计划梳理下Formily相关实现,原谅我偷个懒(不是),本文先从Formily相关功能说起,最后梳理下自己在表单方案上的一点思考.

Formily功能梳理

Formily是一个能力相对完善的表单方案,它主要有如下的特点:

• 路径系统
• 响应式更新
• 可支持Schema渲染
• 提供生命周期能力

表单方案思考

表单方案的演进

表单方案从满足基本业务要求往能力复杂和使用简化上演进.比如:

• 在表单值更新上,提供依赖值的更新/精确更新/Form Group能力等
• 表单实现上从Pro Code的方式到可配置化表单或者基于业务场景封装的表单渲染方案
• 使用上更贴合实际,比如Formik可以直接hooks方式使用/校验场景非当前表单项值的注入等

业务实现上的一些思考

思考业务实现是想解决在面对业务变化时能更快速稳定的支持业务.在广告创编场景中,通常我们看到的是一个大表单,但是由于场景的叉乘实际上后面会衍生多个表单的渲染逻辑.如何从组件走到 表单这步是需要思考的关键点.

字段功能原子化

• 字段功能原子化 抽离字段的UI/校验达到最大化的复用
• 业务逻辑抽象/隔离 在字段中抽象业务能力,比如通常的白名单显隐能力对应到字段只有visible字段控制,不需要关注白名单解析

生命周期能力

抽象业务生命周期,数据获取/数据转换/插件注入等

结合当前业务结合去选型

Pro Code并不糟,关键在于如何通过原子化/生命周期能力/抽象能力去实现便于理解且成本可控的表单.基于配置方式实现的表单方案在处理较复杂联动能力上和代码维护上都有很大的成本,并不是大杀器. 性能似乎并没有那么重要,在可控的性能下,如何管理更新时产生的副作用是需要考虑的问题.并不能直接一把梭

表单技术方案实现思考

• 基础层 提供底层能力组件库/配置化能力/自动化测试能力/自定义规则校验能力 对于自定义规则校验能力可以理解为对上层实现的一种约束.比如检查组件内白名单字段的使用情况
• 业务物料 基于基础层实现业务物料的封装,在业务物料层可以抽象出通用api或者生命周期.
• 运行时 可以用Pro Code方式的表单/Schema配置方式实现的表单/基于业务实现的表单渲染方式,可以提供插件的注入方式插入插件逻辑 提供运行时主要是将相关实现逻辑去解耦.比如在最开始的表单上实现显隐需要判断白名单权限等.在通过表单原子化抽象,这些能力对应到表单上的表达就是字段模型的一个字段