如何写出更优雅的 React 组件 - 设计思维篇

我们从设计思维的角度来谈谈如何设计一个更优雅的 React 组件。

基本原则

单一职责

单一职责的原则是让一个模块都专注于一个功能，即让一个模块的责任尽量少。若一个模块功能过多，则应当拆分为多个模块，这样更有利于代码的维护。

就如同一个人最好专注做一件事，将负责的每件事情做到最好。而组件也是如此，要求将组件限制在一个合适可被复用的粒度。如果一个组件的功能过于复杂就会导致代码量变大，这个时候就需要考虑拆分为职责单一的小组件。每个小组件只关心自己的功能，组合起来就能满足复杂需求。

单一组件更易于维护和测试，但也不要滥用，必要的时候才去拆分组件，粒度最小化是一个极端, 可能会导致大量模块, 模块离散化也会让项目变得难以管理。

划分边界

如何拆分组件，如果两个组件的关联过于紧密，从逻辑上无法清晰定义各自的职责，那么这两个组件不应该被拆分。否则各自职责不清，边界不分，则会产生逻辑混乱的问题。那么拆分组件最关键在于确定好边界，通过抽象化的参数通信，让每个组件发挥出各自特有的能力。

高内聚/低耦合

高质量的组件要满足高内聚和低耦合的原则。

高内聚意思是把逻辑紧密相关的内容聚合在一起。在 jQuery 时代，我们将一个功能的资源放在了 js、html、css 等目录，开发时，我们需要到不同的目录中寻找相关的逻辑资源。再比如 Redux 的建议将 actions、reducers、store 拆分到不同的地方，将一个很简单的功能逻辑分散开来。这很不满足高内聚的特点。抛开 Redux，在 React 组件化的思维本身很满足高内聚的原则，即一个组件是一个自包含的单元, 它包含了逻辑/样式/结构, 甚至是依赖的静态资源。

低耦合指的是要降低不同组件之间的依赖关系，让每个组件要尽量独立。也就是说平时写代码都是为了低耦合而进行。通过责任分离、划分边界的方式，将复杂的业务解耦。

遵循基本原则好处：

1. 降低单个组件的复杂度，可读性高
2. 降低耦合，不至于牵一发而动全身
3. 提高可复用性
4. 边界透明，易于测试
5. 流程清晰，降低出错率，并调试方便

进阶设计

受控/非受控状态

在 React 表单管理中有两个经常使用的术语: 受控输入和非受控输入。简单来说，受控的意思是当前组件的状态成为该表单的唯一数据源。表明这个表单的值在当前组件的控制中，并只能通过 setState 来更新。

受控/非受控的概念在组件设计上极为常见。受控组件通常以 value 与 onChange 成对出现。传入到子组件中，子组件无法直接修改这个 value，只能通过 onChange 回调告诉父组件更新。 非受控组件则可以传入 defaultValue 属性来提供初始值。

Modal 组件的 visible 受控/非受控：

// 受控
<Modal visible={visible} onVisibleChange={handleVisibleChange} />

// 非受控
<Modal defaultVisible={visible} />

若该状态作为组件的核心逻辑时，那么它应该支持受控，或兼容非受控模式。若该状态为次要逻辑，可以根据实际情况选择性支持受控模式。

例如 Select 组件处理受控与非受控逻辑：

function Select(props: SelectProps) {
  // value 和 onChange 为核心逻辑，支持受控。兼容传入 defaultValue 成为非受控
  // defaultOpen 为次要逻辑，可以非受控
  const { value: controlledValue, onChange: onControlledChange, defaultValue, defaultOpen } = props;
  // 非受控模式使用内部 state
  const [innerValue, onInnerValueChange] = React.useState(defaultValue);
  // 次要逻辑，选择框展开状态
  const [visible, setVisible] = React.useState(defaultOpen);

  // 通过检测参数上是否包含 value 的属性判断是否为受控，尽管 value 为 undefined
  const shouldControlled = Reflect.has(props, 'value');

  // 支持受控和非受控处理
  const value = shouldControlled ? controlledValue : innerValue;
  const onChange = shouldControlled ? onControlledChange : onInnerValueChange;

  // ...
}

配合 hooks 受控

一个组件是否受控，通常来说针对其本身的支持，现在自定义 hooks 的出现可以突破此限制。复杂的组件，配合 hooks 会更加得心应手。

封装此类组件，将逻辑放在 hooks 中，组件本身则被掏空，其作用是主要配合自定义 hooks 进行渲染。

function Demo() {
  // 主要的逻辑在自定义 hook 中
  const sheet = useSheetTable();

  // 组件本身只接收一个参数，为 hook 的返回值
  <SheetTable sheet={sheet} />;
}

这样做的好处是逻辑与组件彻底分离，更利于状态提升，可以直接访问 sheet 所有的状态，这种模式受控会更加彻底。 简单的组件也许不适合做成这种模式，本身没这么大的受控需求，这样封装会增加一些使用复杂度。

单一数据源

单一数据源原则，指组件的一个状态以 props 的形式传给子组件，并且在传递过程中具有延续性。也就是说状态在传递到各个子组件中不用 useState 去接收，这会使传递的状态失去响应特性。

以下代码违背了单一数据源的原则，因为在子组件中定义了状态 searchResult 缓存了搜索结果，这会导致 options 参数在 onFilter 后与子组件失去响应特性。

function SelectDropdown({ options = [], onFilter }: SelectDropdownProps) {
  // 缓存搜索结果
  const [searchResult, setSearchResult] = React.useState<Option[] | undefined>(undefined);

  return (
    <div>
      <Input.Search
        onSearch={(keyword) => {
          setSearchResult(keyword ? onFilter(keyword) : undefined);
        }}
      />

      <OptionList options={searchResult ?? options} />
    </div>
  );
}

应当遵循单一数据源的原则。将关键词存为 state，通过响应 keyword 变化生成新的 options：

function SelectDropdown({ options = [], onFilter }: SelectDropdownProps) {
  // 搜索关键词
  const [keyword, setKeyword] = React.useState<string | undefined>(undefined);
  // 使用过滤条件筛选数据
  const currentOptions = React.useMemo(() => {
    return keyword && onFilter ? options.filter((n) => onFilter(keyword, n)) : options;
  }, [options, onFilter, keyword]);

  return (
    <div>
      <Input.Search
        onSearch={(text) => {
          setKeyword(text);
        }}
      />
      <OptionList options={currentOptions} />
    </div>
  );
}

减少 useEffect

useEffect 即副作用。如果没有必要，尽量减少 useEffect 的使用。React 官方将这个 API 的使用场景归纳为改变 DOM、添加订阅、异步任务、记录日志等。先来看一段代码：

function Demo({ value, onChange }) {
  const [labelList, setLabelList] = React.useState(() => value.map(customFn));

  // value 变化后，使内部状态更新
  React.useEffect(() => {
    setLabelList(value.map(customFn));
  }, [value]);
}

上面代码为了保持 labelList 与 value 的响应，使用了 useEffect。也许你现在看这个代码的本身能正常执行。如果现在有个需求： labelList 变化后也同步到 value，字面理解下你可能会写出如下代码：

React.useEffect(() => {
  onChange(labelList.map(customFn));
}, [labelList]);

你会发现应用进入了永久循环中，浏览器失去控制，这就是没必要的 useEffect 。可以理解为不做改变 DOM、添加订阅、异步任务、记录日志等场景的操作，就尽量别用 useEffect，比如监听 state 再改变别的 state。结局就是应用复杂度达到一定程度，不是浏览器先崩溃，就是开发者崩溃。

那有好的方式解决吗？我们可以将逻辑理解为 动作 + 状态。其中 状态 的变更只能由 动作 触发。这就能很好解决上面代码中的问题，将 labelList 的状态提升，找出改变 value 的 动作，封装一个联动改变 labelList 的方法给各个 动作，越复杂的场景这种模式越高效。

通用性原则

通用性设计其实是一定意义上放弃对 DOM 的掌控,而将 DOM 结构的决定权转移给开发者，比如预留自定义渲染。

举个例子， antd 中的 Table通过 render 函数将每个单元格渲染的决定权交给使用者，这样极大提高了组件的可扩展性：

const columns = [
  {
    title: '名称',
    dataIndex: 'name',
    width: 200,
    render(text) {
      return <em>{text}</em>;
    },
  },
];

<Table columns={columns} />;

优秀的组件，会通过参数预设默认的渲染行为，同时支持自定义渲染。

统一 API

当各个组件数量变多之后，组件与组件直接可能存在某种契合的关系，我们可以统一某种行为 API 的一致性，这样可以降低使用者对各个组件 API 名称的心智负担。否则组件传参就会如同一根一根数面条一样痛苦。

举个例子，经典的 value 与 onChange 的 API 可以在各个不同的表单域上出现。可以通过包装的方式导出更多高阶组件，这些高阶组件又可以被表单管理组件所容纳。

我们可以约定在各个组件上比如 visible、onVisibleChange、bordered、size、allowClear 这样的 API，使其在各个组件中保持一致性。

不可变状态

对于函数式编程范式的 React 来说，不可变状态与单向数据流是其核心概念。如果一个复杂的组件手动保持不可变状态繁杂程度也是相当高，这里推荐使用 immer 做不可变数据管理。如果一个对象内部属性变化了，那么整个对象就是全新的，不变的部分会保持引用，这样天生契合 React.memo 做浅对比，减少 shouldComponentUpdate 比较的性能消耗。

注意陷阱

React 在某个意义上说一个状态机，每次 render 所定义的变量会重新声明。

Context 陷阱

export function ThemeProvider(props) {
  const [theme, switchTheme] = useState(redTheme);

  // 这里每一次渲染 ThemeProvider, 都会创建一个新的 value 从而导致强制渲染所有使用该 Context 的组件
  return <Context.Provider value={{ theme, switchTheme }}>{props.children}</Context.Provider>;
}

所以传递给 Context 的 value 做一下记忆缓存:

export function ThemeProvider(props) {
  const [theme, switchTheme] = useState(redTheme);
  const value = React.useMemo(() => ({ theme, switchTheme }), [theme]);

  return <Context.Provider value={value}>{props.children}</Context.Provider>;
}

render props 陷阱

render 方法里创建函数，那么使用 render props 会抵消使用 React.memo 带来的优势。因为浅比较 props 的时候总会得到 false，并且在这种情况下每一个 render 对于 render props 将会生成一个新的值。

<CustomComponent renderFooter={() => <em>Footer</em>} />

可以使用 useMethods 代替： github.com/MinJieLiu/heo/blob/main/src/useMethods.tsx

社区实践

高阶组件/装饰器模式

const HOC = (Component) => EnhancedComponent;

装饰器模式是在不改变原对象的基础上，通过对其进行包装扩展（添加属性或方法），使原有对象可以满足用户的更复杂需求，满足开闭原则，也不会破坏现有的操作。组件是将 props 转化成 UI ，然而高阶组件将一个组件转化成另外一个组件。

例如漫威电影中的钢铁侠，本身就是一个普通人，可以行走、跳跃。经过战衣的装饰，可以跑得更快，还具备飞行能力。

在普通组件中包装一个 withRouter(react-router)，就具备了操作路由的能力。包装一个 connect(react-redux)，就具备了操作全局数据的能力。

Render Props

<Component render={(props) => <EnhancedComponent {...props} />} />

Render Props 用于使用一个值为函数的 prop 在 React 组件之间的代码共享。Render Props 其实和高阶组件一样，是为了给纯函数组件加上 state，响应 react 的生命周期。它以一种回调的方式，传入一个函数给子组件调用，获得状态可以与父组件交互。

链式 Hooks

在 React Hooks 时代，高阶组件和 render props 使用频率会下降很多，很多场景下会被 hooks 所替代。

我们看看 hooks 的规则：

• 只在最顶层使用 Hook
• 不在循环，条件或嵌套函数中调用 Hook
• 只在 React 函数中调用 Hook

hook 都是按照一定的顺序调用，因为其内部使用链表实现。我们可以通过 单一职责 的概念将每个 hook 作为模块去呈现，通过组合自定义 hook 就可以实现渐进式功能增强。如同 rxjs 一样具备链式调用的同时又可以操作其状态与生命周期。

示例：

function Component() {
  const value = useSelectStore();
  const keyboardEvents = useInteractive(value);
  const label = useSelectPresent(keyboardEvents);
  // ...
}

用过语义化组合可以选择使用需要的 hooks 来创造出适应各个需求的自定义组件。在某种意义上说最小单元不止是组件，也可以是自定义 hooks。

结语

希望每个人都能写出高质量的组件。

优雅篇章

最近两个月才开始写，希望能帮到大家，或者也可以加群一起学习进步。

• 如何写出更优雅的 React 组件 - 代码结构篇
• 如何写出更优雅的代码- JavaScript 篇