基于 React 的多端动态表单渲染器设计与实践
一、背景与动机
随着公司门店数量的不断增加，、、、逐渐成为企业运营的核心环节。为了支撑这一目标，公司建设了门店生命周期中台，对门店从筹建到开业再到营运进行全流程管理。
在这一过程中，涉及了 的建设，包括 H5 端、Web 端以及 App 端。其中，主要面向 两端，虽然两端在交互与体验上存在差异，但在 上却高度一致。
如果为每个端单独维护表单页面，不仅开发成本高，而且在业务规则频繁调整的情况下，更新迭代效率会受到极大影响。基于此，我们希望能够实现：
-
：通过统一的 Schema 配置，支持表单在不同端的动态渲染。
-
：当业务流程调整时，仅需修改配置而非重写代码。
-
：减少重复开发，统一表单逻辑与组件管理。
因此，设计并实现了一套 在 架构 下，渲染器作为独立子包进行维护，业务项目则划分为 Web 与 H5 两个子包，通过共享同一渲染器实现多端表单渲染，从而支撑门店业务的快速迭代与规模化扩张。
二、项目架构设计
设计思路
在项目架构上，采用 的方式，将项目拆分为三个子包：
-
H5 端业务项目：面向移动端，基于 实现交互。
-
Web 端业务项目：面向桌面端，基于 实现交互。
-
渲染器包 ：核心渲染器，负责解析 并动态渲染表单。
表单渲染流程
Schema 获取
-
表单 在 上进行配置与生成。
-
在业务项目中，根据不同的任务 请求对应的表单 。
Schema 格式化与处理
渲染器包 提供了 hooks 方法。
调用该方法时传入任务 ，即可获取到格式化后的 数据。
表单渲染
将 传入 渲染器组件。
会根据 配置动态生成表单。
多端组件适配问题
由于 H5 端基于，Web 端基于 ，二者的组件体系不同，为了解决多端渲染适配问题，设计了 ：
在业务项目中 ，并映射到渲染器中使用。
渲染器只关心抽象的组件类型，不依赖具体实现。
不同端可以通过注册方式接入各自适配的组件，从而实现 。
同时支持自定义组件
三、技术细节与重难点突破
1. 表单字段的复杂处理
在实际业务中，表单往往不只是简单的输入输出，还涉及到复杂的 字段联动、动态校验与布局控制。
-
：例如 A 字段选择后，B 字段是否展示或值范围随之改变。通过 Schema 中配置联动规则，在渲染器层统一解析，避免散落在各业务代码中。
-
：某些字段的校验规则并非固定，而是依赖于其他字段的值变化。
实现思路图
整体流程
-
业务端拿到自定义 schemas 配置（来自宜搭平台）
-
格式化/合成 schema（把业务 schema + 自定义schema 组合成完整的 ）
-
初始化渲染器状态：调用 )，内部通过 把组件树展平成 字典
-
渲染 ：组件读取 的 （如 components、form），根据组件状态渲染 UI
-
用户交互 → 触发事件 → triggerEvent 执行 中匹配的事件 → 更新组件属性/值 从而完成联动或动态校验规则修改
2. 数据源优化与请求控制
下拉框、级联选择等控件通常需要远程接口获取数据。渲染器设计时支持异步数据源配置
在多端表单渲染过程中，如果不加控制，极易出现 或 的问题：
-
：同一个接口返回的数据如果已获取过，则直接复用，避免重复请求。
-
：对于多个 Select 控件同时请求同一接口的情况，渲染器内部做合并处理，仅发起一次请求，其余控件共享结果。
-
：通过请求队列与并发数限制，避免瞬时发起过多接口调用导致的网络阻塞。
实现思路图
数据源管理器核心功能
- 数据源缓存
当一个接口请求过一次数据后，将结果缓存
下一次请求同一接口时，直接返回缓存结果
- 请求去重
当多个控件同时请求同一个接口时，只发起一次请求
后续控件直接复用首次请求的 Promise 结果
关键点是用 一个 Map 存储进行中的 Promise
- 并发控制
设置最大并发数（例如 5）
如果请求超过并发限制，先放入队列排队
请求完成后，自动触发队列中的下一个请求