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 3529

为价值买单，打赏一杯咖啡

本文价值35.29RMB
已有1条评论
  1. eric 2021-04-28 16:04

    你好，问下这个三角金字塔范式有开源吗？可以参考一下实现吗

    回复