我的 React 最佳实践

14,418 阅读14分钟

持续创作,加速成长!这是我参与「掘金日新计划 · 10 月更文挑战」的第2天,点击查看活动详情

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

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

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

前置理解

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

函数式编程

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

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

以一元二次方程为例, 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),包括一些图表和表格

第一类

image.png

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

首先,我们将这一类页面抽象成如下结构

image.png

如此一来,我们不难实现如下的 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 发生改变进行请求
  • 交互修改数据后进行请求(如删除,新增等)

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

image.png

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

  • 页面初始化
  • 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 还是路由的方式,我们都需要将表单内容抽离出一个新的组件。

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

image.png

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

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

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

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

{[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@4onValuesChange函数,来把所有相关组件的 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 onValuesChange={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 表单页面的概览大致如下图所示

image.png

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

第三类

通常概览页面的要素是,统计数据、时间选择、图表。这一类页面由于通常是作为用户第一个打开的页面,所以需要额外注意的是 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。做到不脱离当前的上下文,又实现了相关逻辑的提取。比函数中定义函数更好一些。

总结

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