← 返回内容列表
工程实践

复杂业务组件应该怎样拆

组件拆得太大难以维护,拆得太碎又会让数据流和调试成本失控。真正稳定的边界来自变化原因。

先用白话理解

这篇内容在讲什么?

这篇内容讲的是:复杂页面应该在哪里切开,才不会越拆越乱。

问题

组件越拆越多,数据层层传递,修改反而更麻烦,为什么?

按视觉小块机械拆分,没有根据状态归属和变化原因定义边界。

解决方案
  1. 画出状态和事件流向
  2. 业务容器负责数据
  3. 只抽取稳定重复能力
  4. 公共组件避免读取页面 Store
01

先画出状态和事件

在拆文件前先列出页面有哪些状态、谁修改它们、哪些事件会跨区域传播。这一步能快速识别业务容器和纯展示组件。

02

复用不是唯一目标

一个只使用一次但边界清晰的组件仍然有价值;一个被复用很多次却需要大量条件分支的组件可能已经失去内聚性。

03

公共能力需要稳定契约

表单、弹窗、分页和上传等公共组件,需要明确受控方式、错误状态、插槽边界和可访问性要求。

  • 避免传入整个页面 Store
  • 事件名称表达业务结果
  • 为异步状态提供统一结构

结语

判断最终要回到真实体验

技术方案没有脱离场景的标准答案。把用户任务、业务边界、开发成本和长期维护放在一起评估,才有可能做出稳定、清晰且经得起变化的页面。

照着做的步骤

  1. 画出状态和事件流向
  2. 按变化原因划分区域
  3. 确定页面与公共组件边界
  4. 检查复用是否降低成本

容易踩的坑

  • 只按视觉方块拆分
  • 公共组件包含大量业务判断
  • 状态在多层组件间反复传递

术语不用怕

  • 内聚:相关逻辑放在一起
  • 耦合:模块之间相互依赖
  • 状态提升:把共享状态放到共同上层