React 表单源码阅读笔记_reac formtype="onlyshow-CSDN博客

本文链接：https://blog.csdn.net/2401_84152232/article/details/138804136

class NameForm extends React.Component {

constructor(props) {

super(props);

this.state = {value: ‘’};

this.handleChange = this.handleChange.bind(this);

this.handleSubmit = this.handleSubmit.bind(this);

}

handleChange(event) {

this.setState({value: event.target.value});

}

handleSubmit(event) {

alert('A name was submitted: ’ + this.state.value);

event.preventDefault();

}

render() {

return (

Name:

);

}

2.2 非受控组件

刚说到受控组件所有的状态都由外界接管，非受控组件则恰恰相反，它将状态存储在自身内部，我们可以借用 React 中的 ref 来访问它。同样还是官方的例子：

class NameForm extends React.Component {

constructor(props) {

super(props);

this.handleSubmit = this.handleSubmit.bind(this);

this.input = React.createRef();

}

handleSubmit(event) {

alert('A name was submitted: ’ + this.input.current.value);

event.preventDefault();

}

render() {

return (

Name:

);

}

2.3 该用哪个

关于受控 vs 非受控的选择，我查阅了许多资料，大部分文档认为应该优先考虑受控模式，可惜还是没有找到一个能让人信服的理由。大量文档无非是列举受控之于非受控更灵活，更 React 单项数据流，感觉更像是为了政治正确而不是基于真实的开发体验来看这个东西。甚至有一张广为流传的对比图：

我个人认为这个图实际上是有问题的，下面所列举的一些非受控组件无法覆盖的场景，实际上 ref 配合组件 onChange 是可以做到的，例如字段级别实时校验，我们完全可以在字段上挂上监听函数，在其值发生改变的时候进行字段校验，然后通过 ref 控制组件的内部状态。所以我认为上述场景并不能作为不推崇非受控组件的理由。

我们之前也讨论过这个问题，有一个比较有意思的说法是：

实际上问题的关键不在于 react，而在于 react 实现的背后思想是 ViewModel。理所应当的，react core team 希望使用 react 开发出来的东西也应该受 viewModel 控制。

但是我个人的理解是，受控和非受控是站在组件状态(值)的存储位置来看的，或者说是基于组件是否是所谓的 Dummy Compnent，本质上受控与非受控的表达能力是相同的，从某种层面上看可以互相实现。

3 React 社区表单方案

官方给出的方案虽然简洁直观，但是直接拿来写需求的话还是有些简陋的，场景稍微一复杂其实效率不是很高。所以很自然地，React 社区给出了相当多的三方表单方案，下面我会分别提几个比较典型的来讲。要注意的是，由于许多设计上各个表单都是互通的(互相借鉴)的，所以有些功能(例如对嵌套数据的支持)的规范/实现我只会挑一个表单来讲。

3.0 前置概念

在深入各个表单方案之前，我想补充一个前置的概念，即 Field。那 Field 是什么？

Field 的概念比较宽泛，它可以简单理解为表单组件（比如输入框）的抽象体。要更具体的讨论这个问题，我们可以先从头来看，我们要如何在 React 当中写一个表单？

1. 从受控的角度来讲，首先我们会定义一个 state 来管理表单的状态，然后我们会给每个表单组件挂载上 value+onChange。

接下来我们可能会希望加上表单项的校验规则的定义，添加标题，声明 name，完成表单项与底层数据结构的映射，其实就是 Field 的作用。所以 Field 主要是帮我们解决了具体表单组件的状态绑定、校验绑定，以及其他的一些像 label 的设置甚至样式，错误信息展示等一系列通用的逻辑。
我们熟悉的 antdesign 表单中的 Form.Item 其实就可以理解为一个 Field。

后面你会看到，几乎所有的类库都包含这个概念。本质上，你可以这么认为，每一个 Field 封装了与它所包含的输入框相关的一切信息。

3.1 rc-form[1] (Antd Form 3.x[2] )

3.1.1 背景

这个表单实际上是大家很熟悉的组件库 Antd Design Form 3.x 的底层依赖，本质上用过 Antd Design Form 的同学都可以认为是用过这个表单。决定先讲这个表单也是基于这一点。

当然表单本身不算复杂，特点鲜明，不管是源码还是暴露的 API 都比较有年代感，一看就能看出是 class component 时代的产物。

3.1.2 例子

简单来看一下官方的例子，感受下:

import { Form， Icon， Input， Button } from ‘antd’;

function hasErrors(fieldsError) {

return Object.keys(fieldsError).some(field => fieldsError[field]);

}

class HorizontalLoginForm extends React.Component {

componentDidMount() {

// To disable submit button at the beginning.

this.props.form.validateFields();

}

handleSubmit = e => {

e.preventDefault();

this.props.form.validateFields((err， values) => {

if (!err) {

console.log('Received values of form: '， values);

}

});

};

render() {

const { getFieldDecorator， getFieldsError， getFieldError， isFieldTouched } = this.props.form;

// Only show error after a field is touched.

const usernameError = isFieldTouched(‘username’) && getFieldError(‘username’);

const passwordError = isFieldTouched(‘password’) && getFieldError(‘password’);

return (

<Form.Item validateStatus={usernameError ? ‘error’ : ‘’} help={usernameError || ‘’}>

{getFieldDecorator(‘username’， {

rules: [{ required: true， message: ‘Please input your username!’ }]，

})(

<Input

prefix={<Icon type=“user” style={{ color: ‘rgba(0，0，0，.25)’ }} />}

placeholder=“Username”

/>，

)}

</Form.Item>

<Form.Item validateStatus={passwordError ? ‘error’ : ‘’} help={passwordError || ‘’}>

{getFieldDecorator(‘password’， {

rules: [{ required: true， message: ‘Please input your Password!’ }]，

})(

<Input

prefix={<Icon type=“lock” style={{ color: ‘rgba(0，0，0，.25)’ }} />}

type=“password”

placeholder=“Password”

/>，

)}

</Form.Item>

<Form.Item>

</Form.Item>

);

}

const WrappedHorizontalLoginForm = Form.create({ name: ‘horizontal_login’ })(HorizontalLoginForm);

ReactDOM.render(， mountNode);

对应的页面如下图：

3.1.3 试跑源码

简单克隆下源码，nvm 切换到 10.x 下，yarn 然后 yarn start 即可，本身项目自带 dev server，然后尝试修改源码即可立即生效。

源码阅读过程中，有一些不太常用的小知识，希望对大家阅读源码有帮助：

Mixin[3]

react 早期提供的基于 createReactClass 的逻辑复用手段，不过官方文档说问题很多，在 ES6 class 中甚至直接不支持了，从目的来看是为了复用一些具体组件类无关的通用方法。

hoist-non-react-statics[4]

用来拷贝 React Class Component 中的静态方法。应用场景是 Hoc 包裹的时候，很难知道有哪些方法是 React 提供的，哪些是用户定义的，而这个方法可以方便地把被包裹组件的非 React 静态方法拷贝到向外暴露的 HOC 上面（详见链接）[5]，这样即使用 HOC 包裹过的组件类上的静态方法也不会丢失。

3.1.4 大体思路

这是我当时阅读源码时留下的一张图，希望对大家有所帮助。

3.1.5 整体设计

实际上，感觉 rc-form 整体设计上还是比较简单的，从官方的受控组件出发，getDecorator 实际上就是个 HOC，内部用 React#cloneElement 将 value & onChange 注入到表单控件上去。通过这种方法，所有的表单控件都被 rc-form 接管了，后续交互过程中不管是输入输出，校验后的错误状态信息都被托管在了组件的内部，用户确实被解放了出来。

美中不足的是，rc-form 使用了一个 forceUpdate 来完成内部状态与视图 UI 的同步，这个 forceUpdate 被放在了 Form 组件中，换句话说，任何一个微小的变动 (比如某个字段的输入) 都将导致整个表单层面的渲染 (我们习惯称之为全局渲染)，这也就是后来 rc-form 被广为诟病存在性能问题的根本原因，其本质就在于它粗犷的渲染粒度。

3.2 rc-field-form[6] (Antd Form 4.x[7])

3.2.1 背景

基于上述提到的一些缺陷，Antd 4.x 对于表单模块进行了重新设计。更具体来说，设计思路上，渲染粒度的把控从表单级别具化到了组件级别，使得表单性能大幅度提升。源码中大量使用 React Hooks，同时简化了暴露的 API，提升了易用性。

3.2.2 例子

可以和上述的代码实例对比下，最直观的变化是砍掉了不知所谓的 getFieldDecorator 整体上感觉确实清爽不少。

import { Form， Input， Button， Checkbox } from ‘antd’;

const layout = {

labelCol: { span: 8 }，

wrapperCol: { span: 16 }，

};

const tailLayout = {

wrapperCol: { offset: 8， span: 16 }，

};

const Demo = () => {

const onFinish = values => {

console.log(‘Success:’， values);

};

const onFinishFailed = errorInfo => {

console.log(‘Failed:’， errorInfo);

};

return (

{…layout}

name=“basic”

initialValues={{ remember: true }}

onFinish={onFinish}

onFinishFailed={onFinishFailed}

<Form.Item

label=“Username”

name=“username”

rules={[{ required: true， message: ‘Please input your username!’ }]}

</Form.Item>

<Form.Item

label=“Password”

name=“password”

rules={[{ required: true， message: ‘Please input your password!’ }]}

<Input.Password />

</Form.Item>

<Form.Item {…tailLayout} name=“remember” valuePropName=“checked”>

Remember me

</Form.Item>

<Form.Item {…tailLayout}>

Submit

</Form.Item>

);

};

ReactDOM.render(， mountNode);

3.2.3 试跑源码

简单克隆下源码，yarn 然后 yarn start 居然跑步起来，提示我漏装了 hast-util-is-element，安装完成后 yarn start 成功启动了 dev server，然后尝试修改源码发现可立即生效。这是我当时整理的一张大概的流转图：

整体的代码还是比较清晰可读的，其实这里的想法很简单，我们知道其实强制 rerender 本质上是将最新的 props / state 重新地沿着组件树往下传递，其本质也可以理解为一种通讯的方式。只不过这种通讯方法的代价就是导致所有的组件都重新渲染。
既然在 Form 上无脑地 rerender 将导致性能问题，那么解决的方向一定是尽可能地缩小 rerender 的范围，如何将最新的表单状态仅仅是同步到需要同步的表单项呢? 很自然地，这里用到了订阅模式模式。
基于上面的设计，展开其实就是 2 点：

a. 每个表单项各自维护自身的状态变化，value-onChange 实际只在当前表单项上面流传；

b. 流转之后通知其他表单项，这时候其他表单项如何知道自己关心当前变化的表单项呢? 这里 field-form 引入了 dependencies，shouldUpdate 来帮助使用者方便地声明自己所依赖的表单项。

3.2.4 支持嵌套数据结构

其实在 rc-form 中我漏了一块比较重要的内容没讲，那就是对嵌套数据结构的支持，比如我们知道实际上用户填写表单最终得到的实际上是一个大 json。对于比较简单的场景，可能表单的 json 只有一级。

譬如登录场景下，比较常见的结构：

{

phoneNumber: ‘110’， // 手机

captcha: ‘YxZd’ ， // 图片校验码

verificationCode: ‘2471’， // 短信验证码

}

但是实际上在复杂场景下，很有可能会出现形如：

{

companyName: ‘ALBB’，

location: ‘London’，

business: {

commerce: {

income: {

curYear: 110，

lastYear: 90，

}

}，

data: {

dau: 1，

}

}，

staffList: [

{

name: ‘zhang3’，

age: ‘22’

}，

{

name: ‘li3’，

age: ‘24’

}，

]

}

这时候，简单的 <FormItem name=“field1” 可能就不太够了，比如这里我们就需要表单项能表单包括对象和列表的嵌套结构，我们就势必需要在表单层面上表示我们所谓的嵌套关系。通常来讲，表单对于嵌套数据的支持都是通过表单项的唯一标识 name 上，这里就以 field-form 为例来看：

import React from “react”;

import ReactDOM from “react-dom”;

import “antd/dist/antd.css”;

import “./index.css”;

import { Form， Input， InputNumber， Button } from “antd”;

const Demo = () => {

const onFinish = (values) => {

console.log(values);

};

return (

<Form.Item

name={[“user”， “name”]}

label=“Name”

rules={[{ required: true }]}

</Form.Item>

<Form.Item

name={[“user”， “email”]}

label=“Email”

rules={[{ type: “email” }]}

</Form.Item>

<Form.Item

name={[“user”， “age”]}

label=“Age”

rules={[{ type: “number”， min: 0， max: 99 }]}

</Form.Item>

<Form.Item name={[“list”， 0]} label=“address1”>

</Form.Item>

<Form.Item name={[“list”， 1]} label=“address2”>

<Input.TextArea />

</Form.Item>

<Form.Item>

Submit

</Form.Item>

);

};

ReactDOM.render(， document.getElementById(“container”));

可以看到本质上就是将数据字段的嵌套的信息拍平存储在了 name 中(此时 name 是数组)，当然更常见的一种做法是形如 lodash get/set 类似的 path 规则：user.name user.age address[0]，只是表现上不同，本质上都是一样的。关于为什么 antd 4.x 要使用数组而不是更常见的做法，官方也给出了解释:

In rc-form, we support like user.name to be a name and convert value to { user: { name: ‘Bamboo’ } }. This makes ‘.’ always be the route of variable, this makes developer have to do additional work if name is real contains a point like app.config.start to be app_config_start and parse back to point when submit.

Field Form will only trade [‘user’, ‘name’] to be { user: { name: ‘Bamboo’ } }， and user.name to be { [‘user.name’]: ‘Bamboo’ }.

正如你所理解的一样，实际在表单的内部也确实是这么做的，所以的字段，无论层级，都是被拍平管理的，虽然本质上可以认为是一颗树，但是关于结构的信息只体现在了 name。例如我们把上面的例子打印出来本质上就是：

其实了解了这一点，再回过头来看 Antd 4.x 中 form 的一众 API 中的 NamePath 也不难理解了：

对于表单项的操作都是接受 NamePath 然后对对应的匹配项进行操作，换个维度来理解的话，本质上你传入的 NamePath 就是需要操作节点的路径。当然这里稍微有个要注意的点就是当操作的目标节点为非叶子节点时，更新需要同步到它的所有子孙上去。

这一块实现上并不复杂，想了解的同学可以翻翻源码，看看 valueUtil.ts，Field.ts#onStoreChange 即可，此处不再赘述。

3.2.5 动态增减数组

现在有了嵌套数据的支持，来看看另一个问题，很多时候我们并不事先知道表单中的某个数组总共有多少项，比如用户再输入他的爱好时，他可以有任意多个爱好，这时候我们就需要使用到动态增减数组。

虽然 antd 4.x 提供了 Form.List 组件来帮助我们很方便地构建动态增减数组的表单，但是实现上绕不开我们前面所说的嵌套数据结构。先看个官方的例子：

import React from “react”;

import ReactDOM from “react-dom”;

import “antd/dist/antd.css”;

import “./index.css”;

import { Form， Input， Button， Space } from “antd”;

import { MinusCircleOutlined， PlusOutlined } from “@ant-design/icons”;

const Demo = () => {

return (

<Form.List name=“sights”>

{(fields， { add， remove }) => (

{fields.map((field) => (

<Form.Item

{…field}

label=“Price”

name={[field.name， “price”]}

fieldKey={[field.fieldKey， “price”]}

rules={[{ required: true， message: “Missing price” }]}

</Form.Item>

<MinusCircleOutlined onClick={() => remove(field.name)} />

))}

<Form.Item>

<Button

type=“dashed”

onClick={() => add()}

block

icon={}

Add sights

</Form.Item>

</>

)}

</Form.List>

<Form.Item>

Submit

</Form.Item>

);

};

ReactDOM.render(， document.getElementById(“container”));

实际渲染的页面长这样:

关于这一块的源码很简单我就不多赘述，感兴趣可以看看 rc-field-form#src#List.tsx，本质上它要做的事情只有 3 个：

只是替用户维护一个可增减的数组，数组中每个对象对应表单数组中的一个节点；
当用户想新增 item 时，在数组中创建一个新的 field，并给予一个唯一的 key 同时根据 item 的位置生成 name，同时调用 onChange 来通知表单对象更新内部状态；
删除和新增同理。

问题: 那么在 antd 中上述每个 field 对象上的三个属性: fieldKey，key，name 都是干嘛的?

其中 name 最好理解，对应的是每个输入框在最终提交的数据结构中对应的位置，key 表示的是该节点的唯一 id (可做 react loop 中的 key)，一直让我很费解的是 fieldKey，因为事实上在 field-form 的源码中 field 并没有包含该值，antd 文档中也没有对该值进行特别的解释。不过最后发现 fieldKey 和 key 本质上是同一个东西，因为在 antd#components#Form#FormList 中我发现：

3.2.6 感想

其实单单对比 Antd 3.x 以及 Antd 4.x 背后的表单，我们已经可以得出一个有趣的结论：表单方案的性能问题本质是在解决各个表单项与项之间及与表单整体之间的通信问题。这里 antd 4.x 利用订阅有选择地通知替代了无脑 rerender 流重绘，实质上是更细粒度的组件通讯实现了更小的通讯代价。接下来我们会看看国外几个类似表单的发展，恰恰也印证了这个观点。

3.3 ------- 国际分割线 --------

其实国内社区主要还是是以 antd form 为主，但是实际上，国外 React 社区的表单方案也有着类似的发展思路。下面大概过一下，思路上类似的地方就不再展开细讲了。

3.4 Redux-Form

Redux-form 算是比较早的一款 react 表单方案了，由于 redux 的流行，使用 redux 进行表单的状态管理是一个很自然的思路。v6 以前的表单大概是这样的：

这里存在两个问题：

性能问题：用户的任何一个按键操作都会引发状态的更新而后全局渲染整个表单，可以看到这个问题和我们之前说的 rc-form 存在的问题是类似的。
依赖 redux：用 redux 来管理表单数据流后来被证明是没有必要的，总的来说就是增大了体积，而且导致很多原本不需要 redux 的项目强制安装 redux。关于这个可以看看 Dan 的说法。

如果你还在犹豫，可以看看：

Dan 发表的看法：良好实践标准[8]

redux 官网的看法：Should I put form state or other UI state in my store?[9]

redux-form 作者看法：redux-form[10]

事实上 redux-form 在 v6 之后更改了更新策略，将 Field 单独注册到 Redux，用 Redux 天然的订阅机制实现了直接对 Field 的更新。可以认为实现了类似 rc-field-form 对于 rc-form 的优化。

3.5 Formik

3.5.1 背景

鉴于 Redux-form 强依赖 Redux 所带来的的问题，Formik 抛开了 Redux，自己在内部维护了一个表单状态。大概看了下作者的设计动机，主要是减少模板代码&兼顾表单性能。虽然提供了 FastField 来做一定的性能优化，不过仍然是以表单整体为视角的粗粒度的状态更新，所以本质上并没有逃开全局渲染的，抛开 FastField 来看，它和 rc-field 的设计思路甚至有些类似。

3.5.2 例子

3.5.3 核心思路

所谓的 FastField 性能优化，不过是通过一层 HOC 包裹实际的 Field，然后在这个中间层中用 shouldComponentUpdate 决定当前更新的状态是否为该 HOC 包裹的 Field 状态。

可以看出来就是粗暴地对表单中几个关键的状态 value， error，touched 以及传入的 prop 的长度和 isSubmit 几个关键字段进行浅比较，如果碰到类似字段 a 决定字段 b 是一个输入框还是下拉框这种场景，还得自己实现 shouldUpdate 的逻辑。所以整体来看可以认为是这样：

3.5.4 React DevTools Tips

在探究这个表单的时候，碰到这里有个很有意思的结论，由于只是 FastField 这种外层 connect 接入 context，内层 shouldComponentUpdate 做优化的机制，这时候通过 devtools 中 highlight updates 并不能看出是否是全局渲染，那玩意在这种情况下会给你误导，这时候更好的方法应该是使用插件提供的 profiler，下面这个例子很好地诠释了这一点：

Demo 地址：https://codesandbox.io/s/7vhsw

3.5.5 感想

总的来看，Formik 完成了它最初的设计，从 redux 中解放出来，并一定程度缓解了表单全局渲染导致的性问题，打包体积也很小只有 12.7k，在 redux-form 横行的年代确实给力(怪不得会被官方推荐)。但是由于发布的年代早，对于后续 react hooks 的支持不是十分全面，且底层设计上还是没有支持到更细的空间更新粒度，所以当表单膨胀或是联动场景较多时，单单靠 FastField 也就力不从心了。

3.6 React-final-form

这是 Redux-form 的作者在维护了多年 Redux-form 之后的又一力作，作者的本意是写一个“无第三方依赖、pure JS、插件式”的表单。在渲染上，final-form 也采取了和 rc-field-form 类似的思路，Form 作为中心订阅器，负责各组件事件的分发，而每个 Field 管理自己的数据，独立地订阅自己感兴趣的其他表单项，并独立地完成渲染。

Final-form 我没有细看，只是大概了解了下，感兴趣的同学可以看看 final-form 作者的演讲: Next Generation Forms with React Final Form[11]

3.7 上述五个表单方案的变迁

其实你会发现历史总是惊人地相似，国内由于饱受 rc-form 全局渲染的困扰而推出了基于订阅的 rc-field-form，国外的发展历程也是类似的: redux-form(v5) => redux-form(v6)，formik => react-final-form。总结下，整个变迁大概可以这么理解：

3.8 React-hook-form

3.8.1 背景

上面已经说了几个表单，我们可以发现这些表单都是通过维护了一个 state 来处理表单的状态，无论是集中更新，还是以订阅的方式进行分布式更新，它们都是基于这个表单状态来完成的，这就是 react 的受控表单模式。

现在，我们不妨换个思路，从非受控的角度入手，非受控表单就不是使用 state 那一套了，它是通过 ref 来直接拿到表单组件，从而可以直接拿到表单的值，不需要对表单的值进行状态维护，这就使得非受控表单可以减少很多不必要的渲染。

但是非受控表单也存在着它的问题，在动态校验、动态修改（联动）方面不是很方便，于是在 react hooks 出现以后诞生了一个以非受控思想为基础的表单库 react-hook-form，这个表单的设计思路很新奇，完全是拥抱原生，拥抱非受控. 核心思路是各个组件自身维护各自的 ref，当校验、提交等发生时，便通过这些 ref 来获取表单项的值。