这是一个创建于 530 天前的主题，其中的信息可能已经有所发展或是发生改变。
前端新手，最近一直在思考这个问题，可能是个很基本的问题。框架是 React ，代码库整体都是 Typescript 了。
比如我有 6 种不同的组件，正常来说就是依序从上到下排列（可能单个组件多次使用）。但是彼此之间的顺序，每个组件具体渲染方式（几个按钮，颜色，什么文字，是否带额外图标等等），都会因为后端传来的具体数据变化，也就是因为业务逻辑有几十上百种渲染组合。因为渲染完毕之后的交互反而是非常简单明了的，所以用户行为反而不会影响 UI 。
怎么能有效地把这些业务逻辑整理起来便于后续开发的迭代，避免分散的业务逻辑之间互相影响（比如 A 业务说要加粗组件 3 的文字，但是 B 业务说要追加图标给组件 3 ，而 C 业务可能说组件 3 的图标要移动到组件 2 里），以及新的修改可以避免对所有业务排列组合做一遍繁琐检查？
换句话说，你有 100 个 if else ，每一个都输出了代表具体渲染方式的 div ，怎么找到 if else 之间的共同点，以及 div 的子元素之间的共同点，然后有效地重构两者？
顺便附上 GPT 老师的回答，有些过于笼统了：
重构一个相对复杂的基于后端数据的 UI 渲染逻辑可以采取以下步骤：
理解当前代码：首先，仔细研究和理解当前的代码逻辑，包括数据获取、处理和 UI 渲染的流程。确定各个组件之间的依赖关系，以及数据是如何在这些组件之间流动的。
拆分为小组件：将整个逻辑拆分成更小的可复用组件。根据功能和职责将代码分解成独立的模块，这样可以降低代码的复杂度并提高可维护性。
提取公共逻辑：识别并提取出可重复使用的逻辑部分。如果在多个地方有相似的处理逻辑，将其提取成独立的函数或组件，以避免重复代码。
引入状态管理：如果现有的数据流动逻辑过于复杂或混乱，考虑引入状态管理库（如 React 的 Context API 、Redux 等）。通过将状态抽象出来，使数据的流动变得清晰可见，降低组件之间的耦合度。
优化数据获取和处理：审查数据获取和处理的过程，寻找性能瓶颈和不必要的计算。确保只请求和处理必要的数据，并使用合适的数据结构和算法来提高效率。
添加单元测试：为重构后的代码编写单元测试，以验证逻辑是否正确并捕捉潜在的错误。这有助于确保重构过程不会引入新的问题，并提高代码的质量。
逐步重构：根据拆分的模块和提取的公共逻辑，逐步进行重构。在每个阶段完成后，运行测试以确保代码仍然按预期工作。同时，确保重构过程不会对现有功能产生负面影响。
监控和反馈循环：在重构过程中，密切关注应用程序的性能和用户反馈。根据监控结果和用户反馈，进一步优化和调整代码，以确保重构的效果符合预期。
重构复杂的 UI 渲染逻辑需要耐心和谨慎。确保在每个步骤中进行适当的测试和验证，并始终保持代码的可读性和可维护性。
 |
1
saplf 2023-07-14 14:13:38 +08:00
个人看法，列出条件表格之类的，比如：
[ { condition: (data) => bool, component: ComponentA }, { condition: (data) => bool, component: ComponentB }, ... ] 这里根据不同的条件渲染不通的组件。组件内部的细节看具体情况拆分出可传入的 props ，也就是把会变动的元素变成属性传入，至于传入的是组件还是字体样式什么的，看变化程度，具体情况具体分析，在上面的每一项里再加一个 props 属性表格，结构类似 |
 |
2
tool2d 2023-07-14 14:20:52 +08:00
看描述有点类似低代码页面项目，我看别人抽象到 json 页面描述都挺好的。
|
 |
3
Ayanokouji 2023-07-14 14:25:54 +08:00
服务端渲染呀
|
 |
4
rpman 2023-07-14 14:45:46 +08:00
这个问题也很笼统。你直面代码时的想法往往是对的。
单看描述的话我提一个小点，可以把这些 variants 都配置化。 |
 |
5
iosyyy 2023-07-14 15:35:54 +08:00
应该可以考虑 AST 吧..
|
 |
6
janus77 2023-07-14 16:17:17 +08:00
如果你有 100 个 if else 那你要考虑重新设计了，最简单的就是用面向对象的方法把很多东西包含在父类里面，比如父类有 100 个 case ， 然后分成 10 个子类，子类里面再分子类这样。
|
 |
7
sgiyy 2023-07-14 17:11:17 +08:00
需求解释得不清楚，建议你先把目前有的配置先梳理下，看看都有哪些，再去讨论方案
|
 |
8
FallMonkey OP @sgiyy 现有的配置是说具体有多少种 UI 组合或者说对应的业务逻辑吗？
|
|
9
FallMonkey OP @rpman 对，好几个回复也提到了，把这些业务逻辑都配置化，用 JSON 来描述页面。所以是不是可以参考一些低代码页面项目的配置方法寻求类似的思路？
|
|
10
sgiyy 2023-07-17 10:28:37 +08:00
@FallMonkey #8 是的，就是说也可以参考低代码项目的设计；只是如果你的配置项不是那么的多，你参考下低代码项目的思路即可，无需考虑完全照搬，不要把东西搞得太复杂，最后反而增加较多工作量就得不偿失。
|
Select Language