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

业务开发

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

筛选条件（Filter）+ 表格（Table）

表单（Form）相关的新增，编辑功能

概览页面（Overview），包括一些图表和表格

第一类

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

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

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

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

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

即

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

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

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

接着，我们实现表格区，有经验的同学可以知道，一个 Table 需要 dataSource 数据，columns，pagination，total，有时候还需要 selectedRow 和 sorter 和 filter。

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

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

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

这里存在部分分歧，有部分人认为需要加上 useMemo。为什么不加 useMemo？

因为 useMemo 主要是为了缓存计算量比较大的值，而此处并没有计算量，只是一个变量的声明而已

如果重复声明 useMemo 的话，是否会导致 Table 的重复渲染。我认为过早的性能优化不如不优化，如果真的存在这样子的问题再进行优化也不急。

如果这里加上 useMemo 在某些情况下会有比较多的 depths 需要加到依赖项里，个人感觉这不优雅

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

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

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

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

页面初始化

Pagination 改变进行请求

筛选条件改变进行请求

Table 的 filter 或 sorter 发生改变进行请求

交互修改数据后进行请求（如删除，新增等）

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

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

页面初始化

Pagination 改变

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

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

问：为什么这里的 rowSelection 不提出来，放到 useMemo 里去？

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

第二类

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

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

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

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

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

因为 data 是一份的，如果用第二种做法，需要将一份 data 拆分成三份

倘若出现在第一步中填写某个值会影响第二步中的下拉项，如果是第二种做法，还需要将 Form 的值传给第二步的组件。第一步的做法可以直接通过 form.getFieldValue('xxx')

无它，就是图个简洁

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

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

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

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

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

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

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

初始化阶段（该阶段 Form 表单用 initialValue把表单 UI 渲染出来）

赋值阶段（该阶段用户通过 set 操作把初始值赋给表单的 state）

交互阶段

提交阶段

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

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

总结后，可以得出整个 Form 表单页面的概览大致如下图所示

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

第三类

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

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

整个页面的 loading，这种情况通常是全局的一个时间选择器，然后同时获取统计数据和图表，需要借助 Promise.all 或 Promise.allSettled 实现。

分区域的 loading，如图表区有图表区的 loading，表格区有表格的 loading，统计数据区有统计数据区的 loading，这种时候需要把 loading 更加细分，为每一个区域增加 loading 变量，确保各个请求都有 loading 状态展示

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

代码开发

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

hooks

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

减少 useState的使用，将不影响渲染的数据放到 useRef 里去，甚至说常量可以放到函数外部。同时，如果是同一个种类的可以进行合并

减少 useMemo 的时候，普通的赋值或声明或简单的计算完全不需要引入 useMemo，可以在复杂的计算时加上 useMemo

避免 useCallback 的使用，目前想到的 useCallback 的场景，只有addEventListener的时候，其余情况下大部分都用不到。

useEffect 可以进行写多个的，所以有些时候不同的逻辑可以放到不同的 useEffect 里去

useRef 可以大量持有，useRef 能 cover 的场景远大于 ref

useContext在简单场景下完全可以替代 redux，但是有性能问题。所以复杂场景下，建议是配合use-context-selector使用，或者选择其他状态管理工具，如：recoil

useLayoutEffect 和 useEffect在绝大部分应用情况下没有差异，只需要直接使用 useEffect 即可。目前考虑前者的唯一不可替代性仅存在于「闪烁」场景。

useReducer 一般来说用不到，其使用场景应该是当存在多个数据，而某一个参数的改变会引起其他数据同时改变，从而引起页面重渲染。

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}。另外需要注意 requiredMark 和 required 的区别，validator 和其他 rules 的区别，setFieldsValue 和 setFields 的区别

Input等输入控件需要注意 placeholder 的值，Select 需要额外主要 allowSearch

Select个人习惯直接通过 options 赋值，而不是 children（原因：相比 jsx 会有更加好的渲染性能）

select可以通过 dropdownRender自定义下拉内容

Tree 组件面向的场景比较复杂的情况下，个人觉得 antd 的 tree 组件不好用，偏向于自己手写

所有的 popup 相关组件都可以设置 getPopupContainer，该属性用来修改组件渲染位置，如果遇到弹出层没有随滚动条滚动可以设置，但是设置完可能需要考虑 overflow:hidden 的问题

Table组件的 rowKey 属性很重要，必加。

需要注意 Table + Modal 的写法，不要把 Modal 写到操作列里面去

Modal 和 Drawer组件不推荐用 visible && <Modal />的写法，会导致动画丢失。建议在写 Modal 或者 Drawer 的时候，把「空状态」考虑进去。同时可以配合 Modal 的 destroyOnClose属性可以让每次 Modal 打开内容都是新内容。（PS：Form 除外）

Spin 可以多，但不能少

其他

爱惜你的 div，不要动不动就搞个 div，过多的层级结构会影响加载速度的。量变引起质变

尽量避免 ref 的使用，在通常情况下如果考虑用 ref 解决问题的话，那可能代表了你的思路不对或代码设计不对。

有时候，可以用 IIFE。做到不脱离当前的上下文，又实现了相关逻辑的提取。比函数中定义函数更好一些。

总结

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

Last update: 2023-9-17