React设计模式：从经典面向对象到现代Hooks

解释了单例、工厂模式和观察者模式等经典软件设计模式在 React 中的应用方式，以及 HOC、Hooks 和复合组件等 React 特有的设计模式。

1624 词

许多刚接触 React 的开发者并没有立刻意识到，设计模式其实也适用于后端系统之外。人们常常以为这些概念仅与服务器端架构相关，直到在专业开发前端应用时才发现，其实很多设计模式早已被他们在无意识中运用了。

设计模式本质上是经过验证、可重复使用的模板，用于解决软件项目中反复出现的各类问题。当你需要让代码库保持有序、结构合理且逻辑清晰时，这些模式就能为你提供遵循的蓝图。它们相当于标准化的最佳实践，能够提升代码质量并延长其可维护的时间长度。

设计模式带来的最大优势包括可重用性、可维护性、可扩展性，以及速度和效率的提升。在深入探讨特定于 React 的模式之前，先回顾那些早于前端框架就已存在的基础软件工程模式是很有必要的。

经典软件工程模式

这些模式独立于任何特定语言而存在，可广泛应用于面向对象和函数式编程范式。React 本身在内部就依赖多种此类模式，而参与 React 代码库开发的工程师则利用它们来组织状态、协调组件间的生命周期依赖关系、减小代码包大小，并让复杂的 UI 逻辑更易于理解。

单例模式

这种模式能够确保在应用程序的整个运行时期内，一个类或对象仅有唯一的一个实例，并提供一个全局访问点来操作该实例。

在前端开发中，单例模式非常适合管理共享资源——比如集中式的状态存储、整个应用范围的配置对象、分析跟踪实例，或是唯一的共享 API 客户端。

// Singleton API Service
class APIClient {
  constructor() {
    if (APIClient.instance) {
      return APIClient.instance;
    }
    this.baseURL = "https://api.example.com";
    APIClient.instance = this;
  }

  fetchData(endpoint) {
    return fetch(`${this.baseURL}${endpoint}`).then(res => res.json());
  }
}

// Any module importing/instantiating this gets the exact same instance
const client1 = new APIClient();
const client2 = new APIClient();
console.log(client1 === client2); // true

借助现代的 ES 模块，无需再手动实现实例检查逻辑——只需导出一个共享对象或实例，即可自动获得单例行为。

// apiClient.js
export const apiClient = new APIClient(); // ES modules cache exports automatically

工厂模式

工厂模式定义了用于创建对象的接口，这样调用代码就无需知道负责生成该对象的具体类或构造函数是什么。

当需要动态生成用户界面元素、处理形式各异的API响应，或构建能够隐藏平台差异的抽象层（例如统一处理网页和移动端的输入事件）时，这种模式尤为有用。

// Button Factory for dynamically rendering UI elements
function createButton(type, config) {
  switch (type) {
    case 'primary':
      return { role: 'btn-primary', label: config.label, onClick: config.onClick };
    case 'icon':
      return { role: 'btn-icon', icon: config.iconName, onClick: config.onClick };
    case 'link':
      return { role: 'btn-link', href: config.url };
    default:
      throw new Error(`Unsupported button type: ${type}`);
  }
}

const primaryBtn = createButton('primary', { label: 'Submit', onClick: () => {} });

观察者模式

这是事件监听器以及Redux、Zustand和MobX等状态管理库背后的核心机制。值得注意的是，React的Context API并不依赖这种模式。

class EventEmitter {
  constructor() {
    this.events = {};
  }

  // Subscribe
  on(event, listener) {
    if (!this.events[event]) this.events[event] = [];
    this.events[event].push(listener);
  }

  // Publish
  emit(event, data) {
    if (this.events[event]) {
      this.events[event].forEach(listener => listener(data));
    }
  }
}

// Usage
const store = new EventEmitter();

// Component A subscribes to state changes
store.on('userLoggedIn', user => console.log(`Welcome, ${user.name}!`));

// Login Service triggers event
store.emit('userLoggedIn', { name: 'Sarah' });

模块模式

该模式通过闭包将代码封装起来，从而使内部变量和函数保持私有状态，仅暴露经过精心设计的公共接口。

在原生ES6模块出现之前，这是保持全局window对象整洁并在JavaScript中实现真正变量隐私性的标准方法。

// Module using IIFE (Immediately Invoked Function Expression)
const ShoppingCartModule = (function () {
  // Private variable
  const cart = [];

  // Private function
  function calculateTotal() {
    return cart.reduce((sum, item) => sum + item.price, 0);
  }

  // Public API
  return {
    addItem(item) {
      cart.push(item);
    },
    getTotal() {
      return calculateTotal();
    }
  };
})();

ShoppingCartModule.addItem({ name: 'Keyboard', price: 100 });
console.log(ShoppingCartModule.getTotal()); // 100
console.log(ShoppingCartModule.cart); // undefined (Private!)

如今，带有 import 和 export 的原生 ES 模块能够自动处理作用域问题，因此你几乎无需手动创建闭包来确保变量私有性。

// cart.js
const cart = []; // Private to cart.js file
export const addItem = (item) => cart.push(item);
export const getTotal = () => cart.reduce((sum, i) => sum + i.price, 0);

React 特有的组件设计模式

以下模式旨在解决 UI 渲染、组件间逻辑共享、树形结构中的状态管理以及避免过度传递属性等独特挑战。

本节将介绍以下组件级模式：

HOC 模式
基于钩子的模式
复合组件模式
容器组件与表现层组件的分离
渲染属性方法
新兴的 AI UI 模式

HOC 模式

高阶组件（HOC）是 React 早期为处理横切关注点而提供的技术之一。设想这样一种场景：当用户同意被追踪后，需要在组件加载时立即触发一次分析事件。如果将这种逻辑硬编码到每个页面组件中，很快就会变得重复繁琐；而日后在分析 SDK 发生变化时进行更新，则会带来维护上的极大困扰。高阶组件模式正是为了解决这类问题而存在的。

高阶组件会基于现有的组件在其之上添加额外的行为，而原始组件无需知晓这些额外行为的存在。这种分离正是该模式的精髓所在。例如，Page 组件只需专注于渲染功能，而通过 withAnalytics(Page) 将其包裹起来后，追踪逻辑便由高阶组件单独处理。

在较新的代码库中，钩子已在很大程度上承担起了这一职责，但在旧版的 React 项目中仍会频繁见到 HOC 模式。

钩子模式

几乎没有哪种新功能能像钩子那样从根本上改变 React。它们于 2019 年在 React 16.8 中引入，此后便成为编写大多数现代 React 代码时的默认且首选的方法。

钩子模式允许开发者使用普通函数将带状态的逻辑和副作用提取出来并在不同组件之间重用，从而有效替代 HOC 和渲染属性等旧有方法。

复合模式

复合模式能让一组组件在无需通过属性手动传递所有内容的情况下，隐式地协同处理共享的状态和逻辑。它最常出现在下拉菜单、折叠面板、标签页以及导航菜单等复杂的交互式用户界面中。

容器/呈现模式

该模式通过将组件的职责划分为两个独立的角色来实现清晰的职责分离：一个负责处理应用逻辑，另一个则专门负责渲染用户界面。

容器组件负责决定用户应看到哪些数据。它掌控着状态，处理各种副作用，并包含应用逻辑。

相比之下，呈现组件则关注这些数据如何被展示。它仅通过属性接收数据和回调函数，而不会修改底层数据本身。

现代 React 开发更倾向于使用自定义钩子，而非采用容器/表现层分离的模式。无需专门创建一个用于获取数据的容器组件，只需将该数据获取逻辑提取到自定义钩子中，然后在需要它的组件内部直接调用即可。这样既能保持职责分离，又能避免额外的组件嵌套和重复的样板代码。

渲染属性模式

在这种模式下，一个函数作为属性传递给某个组件，使该组件能够掌控状态和逻辑，而具体要渲染什么则由使用该组件的地方决定。

渲染属性模式的核心思想是：包装组件不直接渲染固定的 UI，而是先执行其内部逻辑，再通过函数属性来生成相应的 JSX。

在现代 React 中，自定义钩子已基本取代了用于传递纯数据逻辑的 render props。不过，当组件需要掌控整个子树的同时仍允许调用方决定标记结构时，render props 依然很有用。像 React Aria 和 TanStack Table 这样的无头 UI 库便采用这种方式来实现复杂功能——如无障碍处理、焦点管理等相关功能——而无需指定特定的样式或 DOM 结构。

AI UI 模式

这是该列表中相对较新加入的内容。构建人工智能驱动的界面，无论是聊天机器人还是更通用的智能助手，都需要在后端人工智能服务与响应式用户界面层之间进行精心协调。AI UI模式的核心在于将大型语言模型后端与响应式客户端界面相连，从而使它们能够流畅地处理对话交流、流式响应以及异步模型执行。

其中的一个核心理念是将后端和代理层与客户端分开。为避免暴露API密钥并合理管理计算负载，所有与人工智能相关的调用都必须通过服务器端层处理——比如Next.js的路由处理器，或是位于Vite之前的Node.js API代理。应完全避免直接从浏览器调用人工智能服务。