[!info] related notes

• 所属 MOC: react-moc
• 相关概念: react-use-effect、react-custom-hooks
• 易混淆概念:
• 相关资源:

React Class Component vs Function Component

核心差异

两者都能表达 React UI，但组织组件逻辑的模型不同。

Class Component

典型模型：

React.Component
→ this.props / this.state
→ setState
→ lifecycle methods

同一个业务关注点可能分散到：

• componentDidMount；
• componentDidUpdate；
• componentWillUnmount。

Function Component

典型模型：

props
→ render function
→ Hooks
→ state / effect / context / reusable logic

相关状态与副作用更容易按“同一业务关注点”组合进 Hook。

生命周期与 Effect

类组件倾向按生命周期阶段组织：

mount
update
unmount

函数组件中的 Effect 更适合按同步关系组织：

当这组依赖变化
→ 清理旧外部连接
→ 建立新同步关系

这也是为什么 useEffect 不应简单被记成 componentDidMount + componentDidUpdate。

逻辑复用

Class 时代常见：

• HOC；
• render props；
• mixin（更早期）。

Function + Hooks 常用：

• Custom Hook。

Custom Hook 复用的是状态、Effect 和行为逻辑，不增加额外组件层级。

this 与闭包

Class Component 需要理解：

• this；
• method binding；
• 实例生命周期。

Function Component 不依赖实例 this，但需要理解：

• 每次 render 的 snapshot；
• 闭包；
• Hook 依赖；
• stale closure。

所以函数组件不是“没有复杂度”，而是复杂度模型发生了变化。

迁移边界

稳定的旧 class 组件如果：

• 行为正确；
• 测试充分；
• 没有实际维护问题；

通常没有必要仅为了统一写法全部重写。

更稳的迁移策略是：

新功能默认 function + Hooks
→ 旧模块按真实收益逐步迁移
→ 不做无价值 rewrite

学习检查

1. Class 与 Function Component 最核心的差异为什么是“逻辑组织模型”，而不只是语法？
2. 同一个订阅逻辑在 class 生命周期中为什么容易被拆散？
3. Custom Hook 相比 HOC / render props 改善了什么？
4. 函数组件没有 this 后，又引入了哪些新的心智负担？
5. 为什么不能把 useEffect 机械等价成某几个 lifecycle method？
6. 一个稳定老 class 组件是否应该马上迁移？你会依据哪些工程信号判断？