复杂业务组件应该怎样拆
组件拆得太大难以维护,拆得太碎又会让数据流和调试成本失控。真正稳定的边界来自变化原因。
先用白话理解
这篇内容在讲什么?
这篇内容讲的是:复杂页面应该在哪里切开,才不会越拆越乱。
问题
组件越拆越多,数据层层传递,修改反而更麻烦,为什么?
按视觉小块机械拆分,没有根据状态归属和变化原因定义边界。
解决方案
- 画出状态和事件流向
- 业务容器负责数据
- 只抽取稳定重复能力
- 公共组件避免读取页面 Store
先画出状态和事件
在拆文件前先列出页面有哪些状态、谁修改它们、哪些事件会跨区域传播。这一步能快速识别业务容器和纯展示组件。
复用不是唯一目标
一个只使用一次但边界清晰的组件仍然有价值;一个被复用很多次却需要大量条件分支的组件可能已经失去内聚性。
公共能力需要稳定契约
表单、弹窗、分页和上传等公共组件,需要明确受控方式、错误状态、插槽边界和可访问性要求。
- 避免传入整个页面 Store
- 事件名称表达业务结果
- 为异步状态提供统一结构
结语
判断最终要回到真实体验
技术方案没有脱离场景的标准答案。把用户任务、业务边界、开发成本和长期维护放在一起评估,才有可能做出稳定、清晰且经得起变化的页面。
照着做的步骤
- 画出状态和事件流向
- 按变化原因划分区域
- 确定页面与公共组件边界
- 检查复用是否降低成本
容易踩的坑
- 只按视觉方块拆分
- 公共组件包含大量业务判断
- 状态在多层组件间反复传递
术语不用怕
- 内聚:相关逻辑放在一起
- 耦合:模块之间相互依赖
- 状态提升:把共享状态放到共同上层