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

359次阅读 | 发布于2年以前

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

基本原则

单一职责

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

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

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

划分边界

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

高内聚/低耦合

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

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

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

遵循基本原则好处：

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

进阶设计

受控/非受控状态

在 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` 陷阱

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

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

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

exportfunction 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 组件 - 设计思维篇