Y世代写给Z世代的一封情书：了解React的演变

在我被“取消关注”之前，让我解释一下😅 我正处于Y世代和Z世代的交界处，我在类组件时代学习了React。然而，我使用类组件的时间只有两年，巧合的是，这正好是我和Y世代官方划分界限之间的年龄差。这让我想到——大多数Z世代的人很可能是从函数式组件和Hooks开始学习React的！

请将这封信视为我对“类组件一代”和“新一代 React 开发者”之间代沟的思考，以及一些旨在弥合这一代沟的实用编码技巧。因此，真正包容的标题是：

“来自 React 类组件一代开发者的一封致新一代 React 开发者的情书”

我最亲爱的Z世代/新一代React开发者们，

无论是从熙熙攘攘的编程训练营虚拟教室，到在深夜编程时将咖啡因转化为代码，我们都踏上了各自独特的 React 学习之旅。

你们是从函数式组件开始的，而我们是从类组件开始的。

当钩子偷走了我们的心

2019 年，随着 React 16.8 中 Hooks 的发布，我们学习 React 的方式发生了显著变化。在 Hooks 出现之前，函数式组件主要用于简单的、无状态的渲染，而类组件则处理更复杂的逻辑、状态管理和生命周期方法。然而，Hooks 的引入使函数式组件能够管理状态和副作用，从而改变了 React 应用的构建方式。

可以理解的是，Hooks 文档假定读者熟悉类组件。然而，2018 年之后学习 React 的人可能并没有优先学习类组件，因为 React 生态系统正在转向函数式组件方法，这使得学习“旧方法”的动力不足。这导致了一些问题：

意料之外的差异（但是，差异反而会让彼此更加思念）

由于你们的学习历程，在你们的 React 开发方法上，与我们相比存在一些显著的“代际差异”，如下文引述所示。让我们来解释一下每一种差异及其成因：

1.“你们这代人没学过生命周期方法”

解释：这是最显著的区别。对我们而言，类组件的生成和状态管理意味着我们必须理解生命周期方法（` initialize` componentDidMount()、componentDidUpdate()`update` 和 ` componentWillUnmount()cleaned`）的细微差别。这些方法为初始化、更新和清理状态提供了清晰的入口点，而钩子函数则抽象化了这些细节。

2.“你们这一代人往往会直接跳到国家管理图书馆去。”

解释：在 Hooks 出现之前，将 Redux 集成到 React 应用中简直是噩梦。它需要对 Flux 架构有深入的理解，而且需要编写大量的样板代码。因此，尽管有了 Hooks，集成 Redux（或者更确切地说是 Redux Toolkit）的过程变得容易得多，但过去的种种弊端仍然提醒着我们潜在的复杂性，让我们不太愿意使用状态管理库。

3.“你们这代人不喜欢用TypeScript”

解释：类组件为 React 提供了一种面向对象编程 (OOP) 的方法，这与 TypeScript 的类型化特性非常契合。因此，我们更倾向于使用 TypeScript 来增强代码的可维护性，并弥补切换到函数式组件后类型安全性的损失。

4. “你们这代人喜欢用钩子”

解释：类组件拥有特定的生命周期方法，例如 `onResources` 和 ` shouldComponentUpdateonResources`，允许手动控制组件的重新渲染，从而鼓励开发者考虑性能优化。而像 `onResources`useCallback和 `onResources`这样的钩子useMemo，其优化技巧并不那么明确或直观，因此更难确定这些钩子的最佳使用方式。同样，由于类组件需要对组件生命周期及其与渲染和更新的关系有更深入的理解，因此在使用 `onResources` 时，我们能够理解何时应该操作 DOM useRef()。

5.“你们这一代人把检测视为理所当然”

解释：（这大概是我个人最主观的看法）类组件的逐步特性促使我们进行测试实践，因为我们必须单独处理每个组件的生命周期事件和行为。此外，类组件需要更明确的测试设置，例如模拟生命周期方法。相比之下，现在测试函数式组件要“容易得多”，所以对我们来说这是“理所当然”的，但对你们来说可能感觉像是事后才想到的。

所以我想说的是，我们可能对你们的代码选择评判得太快，代码审查也过于严苛。但反思之后，很明显，我们不同的学习经历塑造了我们对 React 开发的不同理解。就像我们不会指望你们理解我们对翻盖手机和紧身牛仔裤的热爱一样，期望你们对类组件和生命周期方法有同样的理解也是不公平的。

所以现在，与其纠结于彼此的差异，不如让我们专注于如何弥合分歧，互相学习。

与其批评，不如让我们提供：回应爱的建议

不要背负不必要的包袱：避免积攒不必要的情绪（“你们这一代人没有学会生命周期方法”）。

• 我们曾付出惨痛的代价才明白，不必要的状态会迅速导致系统复杂度增加和性能问题。应避免存储可以从其他状态值、属性值计算得出的状态，或者并非必不可少的状态。
• 强制执行不可变性，不要在状态中转换数据——而是在渲染时转换数据。
• 注意避免重复或深度嵌套的状态。

掌握钩子这种爱的语言！（“你们这一代人喜欢用钩子”）

• 明确地管理组件生命周期让我们深刻体会到关注点分离的重要性。useEffect虽然使用 useEffect 处理副作用和状态更新看似简单，但我们发现，如果依赖项过多，多次调用 useEffect 会很快导致代码混乱和性能问题。
• 另一方面，要注意 useEffects 中缺少依赖项，因为这可能会导致应用程序出现意外行为。
• 利用useEffect 返回的清理函数来避免内存泄漏并正确处理组件卸载。
• 不要过度使用类似 ` useMemoand` 和 `or`useCallback这样的钩子函数，因为这属于过早优化，而且由于这些钩子函数的开销，可能会产生与预期目的相反的效果。
• 关于使用 Hooks，有两篇很棒的演讲：David Khourshid 的《有效使用 useEffect》和ByteGrad 的《2024 年初级 React 开发人员仍然会犯的 12 个 useState 和 useEffect 错误》。

用 TypeScript 构建更牢固的关系！（“你们这代人不喜欢用 TypeScript”）

• TypeScript 提高了类型安全性、可维护性和可扩展性——随着应用程序的增长，这些都至关重要！
• 许多流行的库和框架（例如 React Native）现在都默认使用TypeScript。

管理我们的爱情状态（管理）（“你们这一代人跳转到状态管理库”）

• 要了解何时使用状态管理库，只有在有明确的使用场景时才选择 Redux 或类似的库。
• 同时，不要把所有内容都放在一个上下文中，而是将状态分解成更小、更易于管理的上下文，每个上下文对应应用程序的不同部分。肯特·C·多兹的这篇文章很棒。
• 对于管理异步操作，可以考虑使用TanStack Query之类的库。

用考试来滋养我们的爱（“你们这一代人把考试视为理所当然”）

• 保持组件专注于单一职责。将复杂的逻辑重构为自定义钩子或实用函数。罗伯特·马丁的《代码整洁之道》是一本很好的参考书。
• 确保你的组件不要太大、耦合度太高或嵌套层级太深，并考虑依赖关系流程。
• 遵循单向数据流、原子设计和组件解耦等原则。
• 优先选择可组合性而非继承。我非常喜欢旧版 React 文档中的这一页。
• React 引入 hooks 之后，项目结构发生了变化（例如不再使用容器）。建议为 hooks、context 和 types 创建文件夹，并从一开始就考虑可读性、可维护性和可重用性的核心原则。这将避免日后重构的麻烦。
• 从外部将依赖项传递给函数或组件，而不是让函数或组件在内部创建或管理其依赖项（依赖注入）。

未来，我们一定会携手共渡难关。

现在，我们即将踏入React 19的未知世界，探索它的服务器组件和全新的 React 编译器。我们可以分享心得，共同思考编译器能否简化 useMemo() 和 useCallback() 的使用，或者我们是否需要合作撰写一篇面向后编译器时代的论文 😉

带着我所有的爱，
Y世代/React开发者的类组件一代

非常感谢 Joe Brady、Charlotte Isambart、Justin Zelinsky、Justin Kek、@hellonehha和 Antony Clements 为“经验教训”部分提供的帮助。

请留下您其他经验教训或心得体会！