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

我们从设计思维的角度来谈谈如何设计一个更优雅的 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。

结语

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