React 不是难点，设计以应对变化才是

Source: Dev.to

Introduction

大多数 React 教程教你如何使用 hooks。很少有教程教你如何用 React 思考。
在构建和维护真实项目的 React 应用后，我发现最难的不是编写组件，而是设计出在六个月后也不会与你作对的系统。
本文不讨论语法，而是讨论思维方式。

Components Are Contracts, Not Just UI

当我设计一个组件时，我把它视为一个 合同：

• 它承诺做什么？
• 它有意不做什么？
• 它被误用的难度有多大？

像复合组件（compound components）这样的模式之所以存在，是因为它们自然地引导使用方式。

// Example placeholder for a compound component pattern

这并不高深，而是防御性设计。它在保持灵活性的同时限制了误用。

State Is a Liability

每一份状态都有代价：

• 更多的重新渲染
• 更多的边缘情况
• 更多的 bug

**经验法则：**如果状态可以推导出来，就不要存储它。

与其直接使用 useEffect，不如先问自己：

• 这可以计算出来吗？
• 它能更靠近使用它的地方吗？
• 它可以搬进一个 hook 吗？

Custom Hooks Are How You Tell a Story

Hooks 不仅用于复用，更用于表达意义。

// Low‑level
useEffect(() => { /* ... */ }, []);

// High‑level
useUserSession();

第二个例子告诉后来的开发者 为什么 会有这个功能，而不仅仅是 它是怎么工作的。好的 hook 像句子一样易读。

Hook Best Practices

• 避免过早使用 useMemo。
• 倾向更简单的组件边界。
• 保持组件小巧，拥有明确的职责并尽量少传递 props。
• 当设计改进时，性能问题往往会消失。

如果一个 useEffect 看起来很巧妙，那它很可能是错误的。Effect 应该是：

• 小的
• 可预测的
• 易于删除的

任何复杂的逻辑都应该放在 hook 或服务层中。

Folder Structure Reflects System Thinking

按功能而不是按技术关注点组织代码，使代码库更具适应性。

features/
  auth/
  billing/
  dashboard/

功能往往一起变化，所以它们应该放在一起。

Goal

我的目标不是写“高级 React”。我的目标是写出：

• 能自我解释的代码
• 能经受变化的代码
• 让下一个功能更容易实现，而不是更难

React 为我们提供了工具，设计才是让这些工具发挥作用的关键。