共计 1705 个字符，预计需要花费 5 分钟才能阅读完成。
吾辈的博客原文在：https://blog.rxliuli.com/p/12…，欢送来玩！
场景
之前吾辈也在 SF 上询问过 相似的问题。
目前在理论业务中遇到了两种状况
程序的性能在分发给不同组织应用的时候有所差别，即不同的组织都会存在一些定制化的性能。
最常见的差别例如- 表单的字段存在差别
- 列表展现的字段与相干操作有所不同
组件内的代码在某个权限下才会执行，然而又依赖于组件内的一些状态，如何将这些代码宰割到不同的中央（例如不同的文件）便于之后的保护。
- 一些按钮在指定权限下存在
- 一些数据在指定权限下展现
计划
- 应用动静配置渲染不同的页面(可序列化的配置)
- 依据状态匹配不同的动静组件
- 应用 hooks 封装不同的逻辑
- 应用状态图管制状态和逻辑
理论调研后果
应用动静配置渲染不同的页面
实际上，之前有看过吾辈写的 react 通用列表组件封装 就晓得，实际上列表曾经被配置化了，能够应用配置的模式去渲染一个残缺的列表页面，因而能够依据不同的组织应用不同的配置就好了。然而，事实上并没有这么简略，因为就算是简略的列表，也依然蕴含 上下文，而这，正是配置不能拿到的内容。
上下文次要包含
- 须要异步申请的数据，例如下拉框的选择项
- 须要从路由上获取的数据，例如搜寻条件
- 须要对页面内的其它组件进行操作时，例如点击按钮有个新增列表项的弹窗
能够有几种解决方案
- 通过函数，而不是单纯的配置，这样，能够通过参数解决一些上下文的依赖状况
- 通过函数且异步，能够解决 api 申请时，此时的 api 必然是能够用的，然而会依赖于 api。
但这依然会带来问题
- 数据不再纯正，无奈序列化。
- 不同配置依赖的数据可能不同，须要配置本人去解决，那么如果这样想的话，那么配置就须要自行获取数据，而不是内部传递数据了
- 依然无奈应用 状态
- 最重要的是，应用函数之后变得不再像是 配置 了
依据状态匹配不同的动静组件
- 配置更为灵便，可能获取到组件的上下文
- 接口申请也没有问题
- 对不同配置，能够自行对数据进行解决
问题
- 无奈如同纯数据配置那样，复用逻辑这么彻底，然而也能够通过 hooks 解决。
- UI 复用问题
先应用组件的形式编写一下，看具体后果如何 - 无奈序列化也意味着无奈放到后端，甚至意味着很难做动静加载
应用
- 应用一个 wrapper 组件来讲 UI 和通用逻辑给包裹进去
- 应用另外一套组件去辨别不同租户的配置（因为是在组件外部写配置，所以该配置能够灵便的应用任意接口，组件上下文可能还不太行）也就是用多个组件来解决这个问题。
能够再尝试一下有没有解决方案。
应用 hooks 封装不同的代码
- 相比于解决 是哪一个 ，更适宜解决 有或没有 的代码宰割
- 可能应用 react 的状态
问题
- 应用 hooks 必须放在函数组件最顶层，导致实质上无奈
lazy加载。参考：Hook 规定 - 应用 hooks 同样难以序列化存储到后端
应用状态图管制状态和逻辑
应用 hooks 封装代码最适宜解决元素级的权限管制，但在面对须要依据多个维度的状态决定程序的状态或行为时，就有点力不从心了。而这，也是为什么无限状态机为什么有用的起因。
论断
最终，咱们抉择了最灵便的 动静组件 + Hooks 共享逻辑 的模式，尽管应用动静组件会减少一些冗余度，但也能够通过子组件或 hooks 的模式复用逻辑，实际上在工程化减小的复杂度的收益是要高于代码冗余的。
应用示例
注销相干内容曾经应用该形式进行了重构
src/pages/registercommon: 通用的一些组件和逻辑，例如申请后盾接口应该是对立的，但返回的数据类型却应该是独自的form: 表单相干组件，提供给列表 / 详情页面应用detail: 详情页面list: 列表页面
organizations: 不同组织的目录org1: 组织 1org2: 组织 2
吾辈编写了一个简略的示例，代码在 dynamic_state
其余技术问题
[x] 如何在运行时依据组织切换性能
- 能够再包一层组件而非简略的从
lazy component map取出组件
- 能够再包一层组件而非简略的从
[x] 如何在运行时增加新组织的性能
- 可能须要插件的实现形式，反对动静加载进来，例如 vscode 的插件体系。
[x] 如何应用 hooks 更好的复用逻辑
- 应用 hooks 封装逻辑，应用小型组件封装 UI/UX
[x] 如何在打包阶段干掉不相干组织的代码
- 须要批改 webpack 相干的内容，目前不予考虑
