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

时间：2022-06-04 07:57:00

如何写出更优雅的 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 受控/非受控：

  1. // 受控 
  2. <Modal visible={visible} onVisibleChange={handleVisibleChange} /> 
  3.  
  4. // 非受控 
  5. <Modal defaultVisible={visible} /> 

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

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

  1. function Select(props: SelectProps) { 
  2.   // value 和 onChange 为核心逻辑，支持受控。兼容传入 defaultValue 成为非受控 
  3.   // defaultOpen 为次要逻辑，可以非受控 
  4.   const { value: controlledValue, onChange: onControlledChange, defaultValue, defaultOpen } = props; 
  5.   // 非受控模式使用内部 state 
  6.   const [innerValue, onInnerValueChange] = React.useState(defaultValue); 
  7.   // 次要逻辑，选择框展开状态 
  8.   const [visible, setVisible] = React.useState(defaultOpen); 
  9.  
  10.   // 通过检测参数上是否包含 value 的属性判断是否为受控，尽管 value 为 undefined 
  11.   const shouldControlled = Reflect.has(props, 'value'); 
  12.  
  13.   // 支持受控和非受控处理 
  14.   const value = shouldControlled ? controlledValue : innerValue; 
  15.   const onChange = shouldControlled ? onControlledChange : onInnerValueChange; 
  16.  
  17.   // ... 
  18. } 

配合 hooks 受控

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

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

  1. function Demo() { 
  2.   // 主要的逻辑在自定义 hook 中 
  3.   const sheet = useSheetTable(); 
  4.  
  5.   // 组件本身只接收一个参数，为 hook 的返回值 
  6.   <SheetTable sheet={sheet} />; 
  7. } 

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

单一数据源

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

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

  1. function SelectDropdown({ options = [], onFilter }: SelectDropdownProps) { 
  2.   // 缓存搜索结果 
  3.   const [searchResult, setSearchResult] = React.useState<Option[] | undefined>(undefined); 
  4.  
  5.   return ( 
  6.     <div> 
  7.       <Input.Search 
  8.         onSearch={(keyword) => { 
  9.           setSearchResult(keyword ? onFilter(keyword) : undefined); 
  10.         }} 
  11.       /> 
  12.  
  13.       <OptionList options={searchResult ?? options} /> 
  14.     </div> 
  15.   ); 
  16. } 

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

  1. function SelectDropdown({ options = [], onFilter }: SelectDropdownProps) { 
  2.   // 搜索关键词 
  3.   const [keyword, setKeyword] = React.useState<string | undefined>(undefined); 
  4.   // 使用过滤条件筛选数据 
  5.   const currentOptions = React.useMemo(() => { 
  6.     return keyword && onFilter ? options.filter((n) => onFilter(keyword, n)) : options; 
  7.   }, [options, onFilter, keyword]); 
  8.  
  9.   return ( 
  10.     <div> 
  11.       <Input.Search 
  12.         onSearch={(text) => { 
  13.           setKeyword(text); 
  14.         }} 
  15.       /> 
  16.       <OptionList options={currentOptions} /> 
  17.     </div> 
  18.   ); 
  19. } 

减少 useEffect

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

  1. function Demo({ value, onChange }) { 
  2.   const [labelList, setLabelList] = React.useState(() => value.map(customFn)); 
  3.  
  4.   // value 变化后，使内部状态更新 
  5.   React.useEffect(() => { 
  6.     setLabelList(value.map(customFn)); 
  7.   }, [value]); 
  8. } 

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

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

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

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

通用性原则

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

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

  1. const columns = [ 
  2.   { 
  3.     title: '名称', 
  4.     dataIndex: 'name', 
  5.     width: 200, 
  6.     render(text) { 
  7.       return<em>{text}</em>; 
  8.     }, 
  9.   }, 
  10. ]; 
  11.  
  12. <Table columns={columns} />; 

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

统一 API

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

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

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

不可变状态

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

注意陷阱

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

Context 陷阱

  1. exportfunction ThemeProvider(props) { 
  2.   const [theme, switchTheme] = useState(redTheme); 
  3.  
  4.   // 这里每一次渲染 ThemeProvider, 都会创建一个新的 value 从而导致强制渲染所有使用该 Context 的组件 
  5.   return<Context.Provider value={{ theme, switchTheme }}>{props.children}</Context.Provider>; 
  6. } 

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

  1. exportfunction ThemeProvider(props) { 
  2.   const [theme, switchTheme] = useState(redTheme); 
  3.   const value = React.useMemo(() => ({ theme, switchTheme }), [theme]); 
  4.  
  5.   return<Context.Provider value={value}>{props.children}</Context.Provider>; 
  6. } 

render props 陷阱

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

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

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

社区实践

高阶组件/装饰器模式

  1. const HOC = (Component) => EnhancedComponent; 

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

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

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

Render Props

  1. <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 一样具备链式调用的同时又可以操作其状态与生命周期。

示例：

  1. function Component() { 
  2.   const value = useSelectStore(); 
  3.   const keyboardEvents = useInteractive(value); 
  4.   const label = useSelectPresent(keyboardEvents); 
  5.   // ... 
  6. } 

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

结语

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

原文链接：https://mp.weixin.qq.com/s/t8NChmdca_YUYSSObt1kHw

标签：

相关文章