如何写出更优雅的 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.   // ... 

配合 hooks 受控

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

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

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

这样做的好处是逻辑与组件彻底分离,更利于状态提升,可以直接访问 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.   ); 

应当遵循单一数据源的原则。将关键词存为 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.   ); 

减少 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]); 

上面代码为了保持 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>; 

所以传递给 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>; 

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.   // ... 

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

结语

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

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