我的 React 最佳实践

  • 我的 React 最佳实践已关闭评论
  • 14 次浏览
  • A+
所属分类:Web前端
摘要

There are a thousand Hamlets in a thousand people’s eyes. —– 威廉·莎士比亚免责声明:以下充满个人观点,辩证学习

There are a thousand Hamlets in a thousand people's eyes. ----- 威廉·莎士比亚

免责声明:以下充满个人观点,辩证学习

React 目前开发以函数组件为主,辅以 hooks 实现大部分的页面逻辑。目前数栈的 react 版本是 16.13.1,该版本是支持 hooks 的,故以下实践是 hooks 相关的最佳实践。

前置理解

首先,应当明确 React 所推崇的函数式编程以及 f(data) = UI 是什么?

函数式编程

函数式编程是什么?这里的函数并非 JavaScript 中的函数,或任何语言中的函数。此处的函数是数学概念中的函数。让我们来回忆一下数学中的函数是什么。

我的 React 最佳实践

在数学概念中,函数即一种特殊的映射,如何理解映射

以一元二次方程为例, f(x) 是一种映射关系,给定一个的 x ,则存在 y 与之对应。

我们将一元二次方程理解为一个黑盒,该黑盒存在一个输入,一个输出,在输入端我们给入一个值 x = 2 则输出端必然会给出一个 y = 4

f(data)=UI

在了解了数学中函数的概念后,将其概念套用到 React 中,我们就可以明白 f(data)=UI 到底指什么意思?

结论:个人理解,将当前组件内部的所有逻辑视为一个黑盒,该黑盒有且仅有一个输入,有且仅有一个输出,输入端为 props,输出端则是当前组件的 UI ,不同的输入会决定不同的输出,就像把 x = 1x = 2 给到所得到的结果是不一样的一样。而将这样的组件组合起来就是每一个页面,即 React 应用。

业务开发

目前绝大部分的后台管理系统,不仅仅是数栈,包括所有 ERP 系统,图书管理系统等等。其主体页面大致可以包括一下三类:

  • 筛选条件(Filter)+ 表格(Table)
  • 表单(Form)相关的新增,编辑功能
  • 概览页面(Overview),包括一些图表和表格

第一类

我的 React 最佳实践

以上是这次在资产中负责开发的文件治理规则页面,属于是第一类的典型页面,那这一类的页面应该如何开发才是最佳实践?

首先,我们将这一类页面抽象成如下结构
我的 React 最佳实践

如此一来,我们不难实现如下的 dom 结构

<div className="container">   <div className="header">     <div className="filter">筛选区</div>     <div className="buttonGroup">按钮区</div>   </div>   <div className="content">表格区</div> </div> 

接下来,我们需要补充各个区域的内容。

筛选区通常会有一些筛选项,这里我们有两个选择,如果比较复杂的筛选项,如存在 5 个以上或存在联动的交互,则选择通过 Form 来实现,而上图中这种比较简单的则可以直接实现。
这里我们不难观察到我们需要 3 个 value 值来实现这 3 个输入框或下拉框的受控模式,这里我们通过声明一个 filter 的变量,将这 3 个值做一个整合。

function (){   const [filter, setFilter] = useState({     a: undefined,     b: undefined,     c: undefined   });      return <><> } 

提问:为什么要 3 个值都放入到一个变量里?

答:1. 减少冗长的定义。 2. 为后续铺垫。

声明完 3 个值后,我们把组件填入

function (){   const [filter, setFilter] = useState({     a: undefined,     b: undefined,     c: undefined   });    return (     <div className="container">       <div className="header">         <div className="filter">           <Input value={filter.a} onChange={(e) => setFilter(f => ({...f, a: e.target.value})} />           <Input value={filter.b} onChange={(e) => setFilter(f => ({...f, b: e.target.value})} />           <Input value={filter.c} onChange={(e) => setFilter(f => ({...f, c: e.target.value})} />         </div>         <div className="buttonGroup">按钮区</div>       </div>       <div className="content">表格区</div>     </div>   ) } 

接着,我们实现表格区,有经验的同学可以知道,一个 Table 需要 dataSource 数据,columnspaginationtotal,有时候还需要 selectedRowsorterfilter

我们先考虑 dataSource 和 columns。首先,我们先考虑数据获取,实现 getDataSourceList

interface ITableProps {}  function (){   const [filter, setFilter] = useState({     a: undefined,     b: undefined,     c: undefined   });   const [loading, setLoading] = useState(false);   const [dataSource, setDataSource] = useState<ITableProps>([]);    const getDataSourceList = () => {     setLoading(true);     Promise.then(() => {       /// xxxx     }).finally(() => {       setLoading(false);     })   };    return (     <div className="container">       <div className="header">         <div className="filter">           <Input value={filter.a} onChange={(e) => setFilter(f => ({...f, a: e.target.value})} />           <Input value={filter.b} onChange={(e) => setFilter(f => ({...f, b: e.target.value})} />           <Input value={filter.c} onChange={(e) => setFilter(f => ({...f, c: e.target.value})} />         </div>         <div className="buttonGroup">按钮区</div>       </div>       <div className="content">表格区</div>     </div>   ) } 

可以看到,我们新增了 loading 变量,用来优化交互的过程,新增了 ITableProps 类型,用来声明表格数据的类型,此时应当和服务端的同学沟通,从接口文档中获取到相关的数据结构,并补全这一块的类型

假设我们此时已经完成了类型的补全,那接下来我们需要完善 columns

const columns: ColumnType<ITableProps>[] = []; 

这里存在部分分歧,有部分人认为需要加上 useMemo
为什么不加 useMemo?

  1. 因为 useMemo 主要是为了缓存计算量比较大的值,而此处并没有计算量,只是一个变量的声明而已
  2. 如果重复声明 useMemo 的话,是否会导致 Table 的重复渲染。我认为过早的性能优化不如不优化,如果真的存在这样子的问题再进行优化也不急。
  3. 如果这里加上 useMemo 在某些情况下会有比较多的 depths 需要加到依赖项里,个人感觉这不优雅

在完善 columns 后,我们继续刚才提到的 Paginationtotal 字段。
这里我们需要声明两个变量

const [pagination, setPagination] = useState({current: 1, pageSize: 20}); const [total, setTotal] = useState(0); 

思考:这里的 total 和 pagination 是否可以合并成一个变量?

答:可以,但是我不愿意,因为我们后面会有存在如下代码,会导致无限循环

useEffect(() => {    // getDataSourceList 中存在改变 total 的值,会导致无限循环   // 如果要解决这个问题,则需要在 depths 中分别写 current 和 pageSize   // 我不愿意   getDataSourceList(); },[pagination]); 

然后接下来我们要实现请求功能,不难总结出我们需要在以下几种情况下做请求:

  • 页面初始化
  • Pagination 改变进行请求
  • 筛选条件改变进行请求
  • Table 的 filter 或 sorter 发生改变进行请求
  • 交互修改数据后进行请求(如删除,新增等)

除了最后这个暂时不做考虑,第三第四项的请求我们可以再细分为如图所示
我的 React 最佳实践

那么,就可以和前两项进行合并,总结如下:

  • 页面初始化
  • Pagination 改变

将上述思路转化为代码可得

function (){   const [filter, setFilter] = useState<Record<string, any>>({     a: undefined,     b: undefined,     c: undefined,     d: undefined,     sorter: undefined   });   const [pagination, setPagination] = useState({ current: 1, pageSize: 20 });    const getDataSourceList = () => {};    useEffect(() => {     setPagination(p => ({ ...p, current: 1 }));   }, [filter]);    useEffect(() => {     getDataSourceList();   }, [pagination]); } 

到这里,我们已经实现了绝大部分主要功能,接下来我们简单实现一个 selectedRows即可。

function (){   const [selectedRows, setSelectedRows] = useState([]);    return (     <Table       rowSelection={{         selectedRowKeys,         onChange: (selected) => setSelectedRows(selected)       }}     />   ) } 

问:为什么这里的 rowSelection 不提出来,放到 useMemo 里去?

至此,一个满足业务的一类业务相关的框架代码已经编写完成。
到这里之后,一类业务页面还有剩下什么东西需要开发?

第二类

二类页面的特点通常是新增和编辑复用同一个页面,需要 Form 表单。

除此之外,通常二类页面有通过 Drawer 或者 Modal 或者跳转路由的方式,但这不影响代码的书写。
不论是 Drawer 还是 Modal 还是路由的方式,我们都需要将表单内容抽离出一个新的组件。

首先,我们看一个比较普遍且较为简单的新增或编辑页面
我的 React 最佳实践

可以观察到,这个表单通过 Steps 组件分割成了 3 个步骤

这里我们需要明确一个思想,即上面强调的 ,那么这里不论是新增还是编辑,其差异只存在于 data 中是否存在 id 值。
这里有两种做法,第一种做法是 3 个步骤只用一个 Form,第二种做法是 3 个步骤 3 个 Form。我个人比较喜欢第一种做法。理由如下:

  • 因为 data 是一份的,如果用第二种做法,需要将一份 data 拆分成三份
  • 倘若出现在第一步中填写某个值会影响第二步中的下拉项,如果是第二种做法,还需要将 Form 的值传给第二步的组件。第一步的做法可以直接通过 form.getFieldValue('xxx')
  • 无它,就是图个简洁

比较复杂的表单通常都有联动情况,比如数据同步任务的表单,或者这里的数据源和表选择的交互。
这一类交互在 antd@3 中通常实现起来会比较的繁琐,在 antd@4中善用 dependenciesonValuesChanged可以很好地解决这一类问题。

{[TRINO, KINGBASEES8, SAPHANA1X].includes(dataSourceType) && (   <FormItem     name="schemaName"     label="选择Schema"     initialValue={schemaName}     rules={[       {         required: true,         message: '请选择Schema',       },     ]}     >     <Select       showSearch       style={{         width: '100%',       }}       onSelect={this.onSchemaChange}       onPopupScroll={this.handleSchemaScroll}       onSearch={this.handleSchemaSearch}       >       {this.renderSchemaListOption(currentSchema)}     </Select>   </FormItem> )} 

如上代码所示, schema 的字段只有在所选择的数据源是 xxx 这几种情况下才会展示,如果我们按照上述代码的写法的话,需要在 state 中新增 dataSourceType字段
那如果用 dependencies的话,可以改成如下写法:

<FormItem noStyle dependencies={['sourceId']}>   {({ getFieldValue }) => (   isXXXXX(options.find(o => o.sourceId === getFieldValue('sourceId'))?.type) && (     <FormItem       name="schemaName"       label="选择Schema"       initialValue={schemaName}       rules={[         {           required: true,           message: '请选择Schema',         },       ]}       >       <Select         showSearch         style={{           width: '100%',         }}         onSelect={this.onSchemaChange}         onPopupScroll={this.handleSchemaScroll}         onSearch={this.handleSchemaSearch}         >         {this.renderSchemaListOption(currentSchema)}       </Select>     </FormItem>   ) )} </FormItem> 

更进一步,可以把 find 抽象一个 getTypeBySourceId函数出来,即优化了可维护性,又减少了变量声明。

除此之外,还有下拉菜单的联动,如 A 的选择会引起 B 的下拉菜单获取,B 的下拉菜单可能又会引起 C 的下拉菜单改变,如此链路下去,会导致声明的 handleChange 函数又多又长

function(){   const handleAChanged = () => {};      const handleBChanged = () => {};      const handleCChanged = () => {};      return (     <Form>       <FormItem name ="a">         <Select onChange={handleAChanged} />       </FormItem>       <FormItem name ="b">         <Select onChange={handleBChanged} />       </FormItem>       <FormItem name ="c">         <Select onChange={handleCChanged} />       </FormItem>     </Form>   )	 } 

那我们可以借助 antd@4onValuesChanged函数,来把所有相关组件的 onChange 做合并,即如下:

function(){    const handleFormFieldChanged = (changed: Partial<IFormFieldProps>) => {     if('a' in changed){       // do something about a       getOptionsForB();       form.resetFields(['b', 'c']);     }      if('b' in changed){       // do something about b       getOptionsForC();       form.resetFields(['c']);     }      if('c' in changed){       // do something about c       getOptionsForD();     }   }      return (     <Form onValuesChanged={handleFormFieldChanged}>       <FormItem name ="a">         <Select />       </FormItem>       <FormItem name ="b">         <Select />       </FormItem>       <FormItem name ="c">         <Select />       </FormItem>     </Form>   )	 } 

同时,在这个函数里我们也可以顺便把 reset 的操作做了

到这里,我们大致完成了 Form 表单的架构思路。接下来,我们需要处理新增和编辑的区分。
通常来说,新增是不需要赋初始值的,而编辑是需要赋初始值的。
这里需要注意的点在于,我们所理解的初始值并不是 Form 组件中 initialValue 的含义。(至少我认为不是)
我认为 Form 组件的生命周期应当分为如下部分:

  • 初始化阶段(该阶段 Form 表单用 initialValue把表单 UI 渲染出来)
  • 赋值阶段(该阶段用户通过 set 操作把初始值赋给表单的 state)
  • 交互阶段
  • 提交阶段

如上阶段中说明所示,我认为初始值的操作应当通过 set 操作完成,那代码实现起来应当如下所示:

function(){   useEffect(() => {     if(router.record.id){       setLoading(true);       api.getxxx({recordId: record.id}).then(res => {         if(res.success){           form.setFieldsValue({             a: res.data.a,             b: res.data.b           })         }       }).finally(() => {         setLoading(false);       });     }   }, []); } 

把编辑的赋值操作全都放到 useEffect 中执行,统一了书写的地方,有利于后期的维护。

总结后,可以得出整个 Form 表单页面的概览大致如下图所示
我的 React 最佳实践

相信各位同学到这里之后,面对一个表单的原型图,心里已经有一个大致的伪代码的实现了。

第三类

通常概览页面的要素是,统计数据、时间选择、图表。这一类页面由于通常是作为用户第一个打开的页面,所以需要额外注意的是 loading 状态的展示。

需要注意的是这里的 loading 会存在以下几种情况:

  • 整个页面的 loading,这种情况通常是全局的一个时间选择器,然后同时获取统计数据和图表,需要借助 Promise.allPromise.allSettled 实现。
  • 分区域的 loading,如图表区有图表区的 loading,表格区有表格的 loading,统计数据区有统计数据区的 loading,这种时候需要把 loading 更加细分,为每一个区域增加 loading 变量,确保各个请求都有 loading 状态展示

其他没什么好说的,主要是 CSS 的要求会更高。大致的伪代码会如下:

function(){   const [options, setOptions] = useState({...defaultOptions});   const [loading, setLoading] = useState(false);   const [timeRange, setTimeRange] = useState([moment(), moment()]);   const [statistic, setStatistic] = useState({     a: 0,     b: 0,   });    const getStatistic = () => {     return new Promise((resolve) => {       setStatistic({a: 1000, b: 30});       resolve();     });   };    const getCharts = () => {     return new Promise((resolve) => {       options.xxx = xxxx;       setOptions({...options});     });   };    useEffect(() => {     setLoading(true);     Promise.all([getStatistic(), getCharts()]).finally(() => {       setLoading(false);     });   }, [timeRange]);     return (     <>       <DateRange value={timeRange} onChange={(val) => setTimeRange(val)} />       <Statistic />       <LineCharts />     </>   ) } 

代码开发

通常来说,我个人的习惯是先实现需求,再进行代码优化和分割,模块的提取等。所以以下优化都是基于所有业务逻辑已经完成的情况下。

hooks

通常,在完成业务后,一个组件内部会包含大量的 hooks 相关的东西。通常优化手段如下:

  • 减少 useState的使用,将不影响渲染的数据放到 useRef 里去,甚至说常量可以放到函数外部。同时,如果是同一个种类的可以进行合并
  • 减少 useMemo 的时候,普通的赋值或声明或简单的计算完全不需要引入 useMemo,可以在复杂的计算时加上 useMemo
  • 避免 useCallback 的使用,目前想到的 useCallback 的场景,只有addEventListener的时候,其余情况下大部分都用不到。
  • useEffect 可以进行写多个的,所以有些时候不同的逻辑可以放到不同的 useEffect 里去
  • useRef 可以大量持有,useRefcover 的场景远大于 ref
  • useContext在简单场景下完全可以替代 redux,但是有性能问题。所以复杂场景下,建议是配合use-context-selector使用,或者选择其他状态管理工具,如:recoil
  • useLayoutEffectuseEffect在绝大部分应用情况下没有差异,只需要直接使用 useEffect 即可。目前考虑前者的唯一不可替代性仅存在于「闪烁」场景。
  • useReducer 一般来说用不到,其使用场景应该是当存在多个数据,而某一个参数的改变会引起其他数据同时改变,从而引起页面重渲染。
const initialState = {count: 0};  function reducer(state, action) {   switch (action.type) {     case 'increment':       return {count: state.count + 1};     case 'decrement':       return {count: state.count - 1};     default:       throw new Error();   } }  function Counter() {   const [state, dispatch] = useReducer(reducer, initialState);   return (     <>       Count: {state.count}       <button onClick={() => dispatch({type: 'decrement'})}>-</button>       <button onClick={() => dispatch({type: 'increment'})}>+</button>     </>   ); } 
  • useImperativeHandler在通常情况下避免使用,使用场景应该只有两种。第一种是要做 ref 的转发,比如封装了一个组件,需要把组件内部的某一个 input 的 ref 转发给父组件。第二种是封装了一个组件,该组件内部实现逻辑是非 JSX 的,存在实例,则需要通过该 hooks 把相关实例转发给父组件。
  • useDebugValue不熟
  • useDeferredValue不熟
  • useTransition不熟
  • useId不熟
  • useSyncExternalStore不熟
  • useInsertionEffect不熟

Ant Design 相关

众所周知,React 库搭配 Ant Design 食用是后台管理系统的高效的原因之一。
Ant Design 相关实践如下:

  • 巧用 Space 组件,个人感觉有点类似于简单场景的 Grid 组件
  • 复杂表单经常使用 Steps 做步骤分割,个人更加推荐 Steps+Form 而不是 Steps.item+Form
  • AutoComplete 个人感觉有很多问题,譬如数据回填高亮等问题,个人感觉不如直接 Input
  • Form组件比较复杂,且配合其他组件的用法比较多,如 Form+Steps Form+Tabs Form+Modal 等,需要注意 inactiveDestroy + preserve={false}。另外需要注意 requiredMarkrequired 的区别,validator 和其他 rules 的区别,setFieldsValuesetFields 的区别
  • Input等输入控件需要注意 placeholder 的值,Select 需要额外主要 allowSearch
  • Select个人习惯直接通过 options 赋值,而不是 children(原因:相比 jsx 会有更加好的渲染性能)
  • select可以通过 dropdownRender自定义下拉内容
  • Tree 组件面向的场景比较复杂的情况下,个人觉得 antd 的 tree 组件不好用,偏向于自己手写
  • 所有的 popup 相关组件都可以设置 getPopupContainer,该属性用来修改组件渲染位置,如果遇到弹出层没有随滚动条滚动可以设置,但是设置完可能需要考虑 overflow:hidden 的问题
  • Table组件的 rowKey 属性很重要,必加。
  • 需要注意 Table + Modal 的写法,不要把 Modal 写到操作列里面去
  • ModalDrawer组件不推荐用 visible && <Modal />的写法,会导致动画丢失。建议在写 Modal 或者 Drawer 的时候,把「空状态」考虑进去。同时可以配合 ModaldestroyOnClose属性可以让每次 Modal 打开内容都是新内容。(PS:Form 除外)
  • Spin 可以多,但不能少

其他

  • 爱惜你的 div,不要动不动就搞个 div,过多的层级结构会影响加载速度的。量变引起质变
  • 尽量避免 ref 的使用,在通常情况下如果考虑用 ref 解决问题的话,那可能代表了你的思路不对或代码设计不对。
  • 有时候,可以用 IIFE。做到不脱离当前的上下文,又实现了相关逻辑的提取。比函数中定义函数更好一些。

总结

以上的相关实践,是本人在日积月累中总结和摸索出来的。
如有雷同,说明你和我有一样的感受。