Robust 第 014 期:三角金字塔 web 表单开发新范式

Web 表单虽然是前端开发中非常常见的开发项目,但是,在具体到一些业务场景中,表单开发缺是非常复杂的过程。其中设计到的点,虽然看上去好像都挺容易,能实现,但是,要将所有这些点组织在一起管理,确是一个复杂的事情。本期 robust 主要来聊一聊 web 表单开发的新范式。

网易云音乐:点击播放

喜马拉雅:点击播放

求打赏🙇如果你觉得 Robust 这样一档技术类的谈话节目还不错,希望我继续做下去,不妨打赏支持。你可以扫描本文下方的二维码打赏,也可以加我微信后红包打赏。

文字稿:

两个难点:
  • 如何让听众能够体会到,一个 web 表单比看上去的,有多复杂,以至于需要用一个体系去阐述它
  • 如何让开发者能接受我所提出来的三角金字塔开发范式,毕竟它的开发方式和传统从 UI 出发的方式不同
1)为什么在我看来 web 表单是前端开发最复杂的问题之一
  • 即使最简单的表单开发,也涉及到非常复杂的问题:状态
  • 因为,html 原生表单组件也好,我们自己手写的 react 受控表单组件也好,表单的编辑时数据,和最终提交的数据完全不同
  • 由于这个编辑态的存在,表单无法像普通组件一样按照静态逻辑开发
  • 几乎所有的表单,都不可能一步开发完,无论如何,你都需要至少两步:1. 数据准备阶段;2. 数据提交阶段。
2)哪些问题会让 web 表单开发很头疼?
  1. 交互形式:除了普通 UI 框架/库提供的表单组件,还有很多复杂的表单交互,例如,点击某个选项之后,需要进入到一个新的页面,在这个页面进行某些操作后,得到一个结果,然后返回表单界面,把这个结果作为当前编辑的选项的结果。也就是说,某些情况下,你看到的界面,它的形式表现的却不是表单,但它的本质就是表单。可以这么说,但凡需要经过 “编辑-提交” 这样的步骤完成的业务逻辑,其本质都是表单。
  2. 复用麻烦:同样是一个点击弹出新界面,选中某个选项后返回,这样的交互形式,却可能存在细节上的不同,导致组件复用麻烦。
  3. 联动:当某个选项值符合某个条件时,另外一些选项才显示出来。这种联动效果,在表单里面经常会出现,看上去很简单,实际上真正处理起来却很复杂,例如,需要处理联动时,动态加载数据问题,需要解决切换联动开关所带来是否重置数据问题等等。
  4. 数据根据条件提交:当某个选项的值符合某个条件时,另外一个选项才把数据提交到后台,如果不符合条件,即使它是展示的可见的,也不提交。
  5. 自动计算:某一个选项是由另外几个选项自动计算得到的结果。
  6. 自动拉取:进入表单,或者某个选项值发生变化时,符合某种条件下,需要根据条件自动拉取数据对其他选项进行填充。
  7. 校验:
    1. 何时进行校验?
    2. 校验如果出错,是直接展示在选项输入下面,还是通过一个提示框进行提示?
    3. 是输入的时候立即校验,还是提交表单的时候才校验?
    4. 校验是要把所有不符合校验逻辑的错误都抛出来,还是只抛出第一个不符合的?
    5. 是否要校验,需根据一定的条件进行判断,符合条件才进行校验,否则不校验
    6. 同一个选项,有多个校验逻辑
  8. 是否显示?
  9. 是否必填?
  10. 是否只读?
  11. 数据提交:
    1. 和展示的数据不一样,例如展示的是“yes”提交的是1,展示的是“no”提交的是0
    2. 提交时,只提交id,不需要提交文本
    3. 提交时,先用部分数据提交到接口,看看这份数据是否符合提交规则,然后才将整个数据提交到另外一个接口
    4. 有些字段不需要提交
    5. 有些值可能并没有展示在界面上,但是需要提交
  12. 数据恢复:从接口拉取数据,生成一个编辑态表单,对数据进行编辑后提交
    1. 接口数据和表单所需要的数据格式不一致
    2. 数据类型不匹配,例如某个选项需要一个数组,但接口返回了一个字符串,或者需要一个数组,返回null
  13. 同一个字段选项,在某种情况下不可编辑,在某种情况下必填,在某种情况下不可见,在某种情况下可见但不提交
  14. 表单分步走
  15. 表单可撤销或可更换整体数据
3)目前市面上有哪些表单开发解决方案
4)如何去分解表单,才能让表单开发显得杂乱无章?
  • 表单开发的本质是什么?
  • 界面+数据+业务逻辑
  • 界面就是交互效果,只要是世界上见到过的交互效果,我们都可以开发,所以,在不考虑上述所有情况下,界面上的单个选项的交互效果是很容易开发的。但是,难就难在你需要去适应上面这么多的复杂情况。所以,怎么办?
  • 将入口和交互效果分离。所有的交互效果,就按照我们写交互组件的方式去写。唯独不同的地方,在于交互结束之后那一下,要把数据放回到表单数据中,并且把要显示的结果放到表单界面上。
  • 表单数据怎么管理?
  • 表单数据其实有三个状态:编辑态、准备态、提交态。
  • 编辑态包含了编辑时需要的所有信息,无论是界面上展示需要的数据信息、逻辑信息,但编辑态以编辑时需要的数据格式保存数据。例如附件上传。
  • 准备态是从接口拉取的数据,以及用于创建编辑态数据所需要的数据。
  • 提交态则是从编辑态数据经过提取和整理、转化之后得到的数据。
  • 我们只要在我们的开发中存在这三种状态,并且分开管理,就能很清晰的管理表单数据了。至于在三态之间进行转化,其实是非常简单的数据处理逻辑而已。
  • 编辑态数据管理是核心逻辑,编辑态数据不仅有取出后用于界面展示的功能,而且,一定要有响应界面输入的功能,因为只有自动响应界面输入,才能在这个管理器内部去做一些运算,比如某些字段是基于另外的字段自动计算得到结果的。
  • 最后,就是要处理表单的业务逻辑。表单业务逻辑,我个人理解,就是用于在界面和数据之间进行调度,根据业务逻辑进行判断,选择展示哪些字段UI,根据条件处理数据变化。
  • 推荐数据表的逻辑判断方法。
  • 所谓数据表,就是节点值为boolean 的对象。
  • 可包含:阶段表,权限表,必填表。根据因素主要是:类型、当前状态。
5)“三角金字塔”表单开发方法论
  • 本质是在表单开发中使用 MVC 范式
  • 界面+数据+业务逻辑=视图+模型+控制器
1 表单视图开发
  • 我们要先构建一套框架组件,用以实现表单的布局、样式。
  • form-group-item 三级结构
  • 组件是布局框架,要实现交互,我推荐一种“slot”方案。当一个选项需要使用某个交互的时候,它去调用原有的交互组件,这些交互组件,可以是 web 原生的,也可以是借助第三方,比如 antd。总之,在已经布局好的框架中,在每一个需要使用某种交互的地方,有一种统一的方式调用交互组件。
  • slot 需要:label, value, required, disabled, readonly, hidden, errors
  • 以 react 为例,创建一个 FormItem 框架组件,这个组件需要接收一个 render 属性,是一个函数,这个函数的参数就是 slot 的信息,而函数的返回值,就是交互组件根据接收的参数返回的 jsx。这种操作逻辑应该在其他很多地方都见过。
  • 通过 slot 来渲染,则可以将多个字段选项合并到一个组件中,实现块级复用
  • 基于这种模式的表单视图开发,有三种实现:标签式(angularjs、vue)、jsx式(react)、配置式(jquery)。虽然要使用的开发方式不同,但是在思想上得到统一。
  • 在任何表单开发情景下,按照上述思路进行开发,会让表单视图开发变得更统一化,有规律可循。
2 表单模型开发
  • 不卖关子,你需要用到我写的 tyshemo 这个库,它提供了一个 Model 类,这个类是一个表单数据模型的基类,你需要使用 extends 关键字对它进行扩展,扩展出来的,就是一个表单模型。
  • 在表单模型上,你需要声明,这个表单需要用到哪些字段。
  • 在声明每一个字段时,你需要声明:
    • 默认值/计算属性函数
    • 字段类型+类型错误提示语
    • 校验器数组:determine 是否要执行该校验器,validate 校验器函数,返回 true|false|Error|[],message 校验失败时的文本
    • 从接口拉取数据后从准备态数据转化到编辑态数据的函数
    • 从编辑态转化到提交态时的转化函数
    • 从模型读取数据用于展示时的格式化函数,以及从用户输入保存到模型的格式化函数
    • required, readonly, disabeld, hidden 函数
    • 错误抓取函数
    • 扩展字段
  • 上述这些东西的定义,我用模型的 schema 这个概念来囊括它
  • 模型本身是一个定义,而模型的实例则是一个容器,容器中存放着编辑时的数据
  • 模型实例具有响应式能力,能够在状态数据发生变化时通知外部,从而可以让 UI 框架可以刷新界面
  • 另外,模型开发还可以自己加入其他方法,这样可以把有关数据的操作,全部收拢到模型中,这样方便数据代码管理,在将来某些地方出现问题时,都可以直接通过模型的对应方法来进行调试和修复。
  • 一个表单模型,不一定只用于一个表单业务,可能相同的表单模型,可以被复用,只需要足够的条件
3 表单控制器开发
  • 表单控制器主要是结合业务逻辑,也就是前面提到的业务数据关系表,对模型进行初始化、方法调用、UI 支配
  • 实际上,我们现在前端开发,都会借助 react 或 jquery 等 UI 驱动框架
  • 所以,我们的表单控制器开发,不可避免,实际上,就是要连接表单数据模型、表单视图、表单业务,通过模型数据变化来驱动界面变化,并且将用户输入反馈到模型数据上去,并且万无一失的将业务逻辑粘合到表单模型上,并且完成最终表单数据提交
  • 阶段表
  • 权限表
  • 必填表
  • 可见表
  • 可写表
6)表单自定义
  • 基于服务端返回的json实现表单自定义。
  • 核心场景:问卷
  • 在系统的后台管理页面,提供一个表单自定义的界面,让管理员可以根据自己的业务需要进行自定义配置,将配置信息保存为json,返回给前端,前端拿到这个配置之后,按照配置好的逻辑进行表单渲染。而且,还可以自己拟定一套规则,用于配置一些动态逻辑,比如字段的展示和隐藏逻辑,比如字段联动等。但是,需要明白的一点是,这个配置单纯只是 UI 层面的话,其实不能符合我们最终的要求,还要配合数据模型才可以。
  • 由于 schema 也是可以配置化的,因此,视图、模型的配置,都可以通过后台自定义配置,只是我们需要有一个协议层的东西,对服务端输出的配置进行解析
  • 后台仅仅保存了配置信息,虽然这些配置信息考虑到了所有情况,有很多条件分支,但是它毕竟是无状态的,真正要实现自定义,必然会前后端耦合,需要有较强的协议进行约束,通过协议进行解析,在前端去生成运行时的有状态的东西,而且有些东西,无法通过 http 进行传输,例如类的实例,这些都需要协议来完成
  • 但是,总之,基于三角金字塔模型的表单开发范式,实现表单自定义的思路是非常清晰的
7)小结
  • MVC 思想
  • 响应式编程
  • 协议

2020-05-04 141

为价值买单

本文价值1.41RMB