2.1 组件化开发思想

2.1 组件化开发思想

本节摘要：组件是自包含、接口清晰、可独立复用的 UI 单元，是 React 和 Vue 共同的基本构建块。本节讲"该不该拆组件、拆到多细"的判断标准，并给出一套可操作的评审清单——这正是"比稿现场"里每个方案最先过的那一关。

本节阅读目标
阅读完本节，你应当能够：

1. 说清组件的三个核心属性和为什么它们互为前提。
2. 用"接口、职责、独立"三把尺子评审一次组件拆分的取舍。
3. 辨别过度拆分与欠拆分的典型症状并给出调整方向。

一、为什么组件必须是"基本单元"

看一个只有三五个页面的小应用，组件化的收益几乎看不见；可应用一旦到了几十个页面、十来个开发并行，没有组件化，任何一个改动都会像推倒多米诺骨牌。组件把"改一处影响全局"压制成"只影响它自己"，这是它成为现代前端地基的根本原因。

二、三个核心属性

组件之所以是组件，靠三个属性撑起来，缺一不可：

• 自包含：它管自己的状态与表现，不依赖外部偷偷塞进来的全局变量。
• 接口清晰：靠 props 等明确的入口接收外部数据，靠事件把需要外部处理的信号抛出去，不对外部世界动隐藏的手脚。
• 可复用：同一个组件能出现在不同上下文里而不串味。

一个典型的 React 组件长这样，注意它是如何同时照顾三个属性的：

function Counter({ step = 1, onChange }) {
  const [value, setValue] = useState(0);
  const increment = () => {
    const next = value + step;
    setValue(next);
    onChange?.(next); // 把"变化"通过事件抛给父级，而不是自己越界改父级状态
  };
  return (
    <div>
      当前值：{value}
      <button onClick={increment}>加 {step}</button>
    </div>
  );
}
​

这里 props（step、onChange）是接口，value 是自包含的内部状态，事件回调是它对外的通信出口。三者齐备，组件才"端着清清楚楚的门面"。

三、比稿尺子：三问评审法

给任何"要不要拆成组件"的方案做评审，套三个问题就够：

1. 它重复吗：同一段结构或逻辑在超过两个地方出现，就是复用的强信号。
2. 它独立吗：一个职责可以独立演进而不依赖别的模块，就该自成组件。
3. 接口干净吗：拆完后父组件的 props 是不是仍然一目了然、不用看懂子组件内部。

沿这三问往下推，很容易避开两个极端。

四、过度拆分与欠拆分

比稿最常见的滑铁卢不是能力不足，而是走极端。

欠拆分的症状：一个巨型组件塞了几百行，props 二十多个，注释写着"别动这里我也不确定"。治理方向是顺着职责把大块切开。

过度拆分的症状：连一行文字都要包一层组件，props 层层透传，接口数比内容还多。治理方向是合并那些"永远相伴"的小块，别让接口网络失控。

下面用一个矩阵概括"一口吞 vs 切成末"的取舍，这是比稿评审的核心一张表。

五、知识体系定位

组件化思想是整套教程的起点和归处：第 3、4 章把"怎么写出一个组件"落到 React/Vue 的具体语法；第 5 章把它推进到"多个组件怎么往来、怎么复用"。投资在 2.1 的这一课会反复兑现。

这里再把"组件"与另外两个易混概念划个清楚，常被新手放在一起比较。**组件（Component）**是带界面与行为的可复用单元，是本章的主角；**模块（Module）**通常指按文件边界切分的代码单位，偏工程组织而非界面单元，一个组件内部可以由多个模块拼成；函数是最细的复用原子，组件靠函数来组织行为，但函数本身不承担"自包含 UI 单元"这层职责。三者边界常常互相包含，分清楚它们，才能在评审接口时对"该抽象到哪一层"心里有数。

六、一场具体的比稿：拆还是不分

拿一个互联网常见的例子走一遍评审：一个"用户卡片"，展示头像、名字、最近动态，还有一个"关注/取关"按钮。三种方案摆上桌。

方案甲：一个 UserCard 组件打包全部。写得快，但名字要显示的地方（比如消息列表）没法复用，因为整块内容都耦合在卡片里。评审三问里"独立吗"这一问就卡住了。

方案乙：拆成 UserAvatar、UserName、UserAction（关注按钮）、UserFeed 四个小件，再拼成 UserCard。复用性最好，但刚起步时接口网络有点密，属可接受的代价。

方案丙：全站几十个小组件，连头像都再拆成"图片+占位文案"。过度细，接口数比内容还多，读起来反而费劲。

评审结论通常是乙。它的取舍是：在"可复用"与"接口简洁"之间取一个甜点，而不是贪多。这就是组件化的判断功夫——不是会拆，而是拆得恰到好处。这也正是全集用比稿现场贯穿的原因：多数决策没有标准答案，只有经过三问评审后的相对最优。

七、组件接口设计的基本纪律

给组件的对外接口（props 与事件）定几条底线，能少走很多弯路：

• props 只表达数据意图：名字叫 value、title、items，别让调用方猜单位或含义。
• 别让组件越权改外部状态：改外界的活交给事件回调上报，组件内部只动自己的 state。
• 默认值给出明确兜底：可选的 props 给默认值，调用方能一眼看出省略会怎样。
• 接口数量克制：超过十个 props 的组件往往职责过重，回头重新划分。

这些纪律在比稿现场会反复使用：同一场景不同方案的评审，最后都会落到"接口是否清晰、职责是否单一"这两条上面来。

本节要点回顾

• 三属性：自包含、接口清晰、可复用，三者互相成就。
• 三问评审：重复吗、独立吗、接口干净吗。
• 两个极端：欠拆分靠辩责切开，过度拆分靠合并收敛。
• 统一度量衡：是否复用、是否独立、是否好维护，而不是"能不能跑"。

下一节进入渲染机制的里层——虚拟 DOM。组件是面子，虚拟 DOM 和 diff 才是让"声明式"高效落地的里子。