关于 Formily2.x 全局表单状态持久化方案的最佳实践

[Vizards]

背景

1. 之前使用过 Formily(UForm) 1.x，在前期依赖过一个曾经作为亮点宣传的“时间旅行能力”，即可以通过 FormGraph 全局持久化当前表单的状态，具备随时从 Storage 中恢复 FormGraph 以实现 state 的持久化数据的写入和读取，毫无疑问的是 Formily 2.x 同样拥有这个能力。
2. 讨论的点是在什么时机进行状态持久化、如何对这种状态持久化能力做通用封装

需求

在后续大量使用 Formily 2.x 的实际 React SPA 工程中，会出现不同的页面渲染不同的 Form 的需求，希望为某些文本量较多或字段较复杂的表单项提供恢复现场的能力，具体实现方案大同小异，都是通过向 Storage/IndexedDB/EdgeStorage 写入和读取 FormGraph 实现（对于 FormGraph 的实际大小是否超出 Storage 容量在此不作为重点讨论）

但是当不同的 Form 位于不同的页面上时，开发者希望通过一些上层封装将这种恢复现场的能力赋予 FormProvider，虽然也可以通过 useFormEffects 封装一个 Custom Hook 实现，但仍需要在不同的 FormProvider 内进行手动调用。可能的更具吸引力的设计模式是通过封装将所有的 FormProvider 赋予恢复现场的能力，不需要此能力的组件可以通过配置关闭。

可能方案

1. 按照设计者的想法（#1606-comment-915472)）合理的方案是FormProvider和createForm是在同一个组件内搭配使用，那么 createForm 的单实例还适不适合应用于这种场景？
2. 将 FormProvider 和 createForm 作为一对一搭配，一起封装为单个组件，在内部实现输入状态监听和状态持久化存储和恢复。 但此种模式不符合源码中的一些设计思维，也存在一些问题: 我封装了一层formily,在外层怎么调用formily的生命周期？ #2929
3. 对 FormProvider 做封装，不关心 createForm：源代码中可以看到，如果不在 createForm 中监听某些生命周期事件，在后续挂载 effects 监听可能无效，FormProvider 本身职责比较单纯，对它做封装是否符合最佳实践？

疑问总结

1. 对于需要持久化用户表单状态的这种实际应用情形，在 Formily 的哪个生命周期内调用持久化数据的写入和读取最为合适？
2. 对于多个不同 formInstance 的 SPA 应用，如何为他们注入一些全局统一的生命周期方法，在 Formily 设计者看来的最佳实践是什么？