index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html
![]()
本文深入探讨了 Ant Design Form 的实现原理，从 3.x 版本的 HOC 模式到 4.x/5.x 版本的 Hooks API，揭示了 API 设计背后的技术考量。通过分析状态管理思路的转变，文章阐述了 HOC 模式的局限性以及 Hooks API 如何解决这些问题。文章最后还给出了 Ant Design Form Hooks 版本的简化实现示例，帮助读者更好地理解其核心概念。
💡Ant Design Form 3.x 版本采用 HOC 模式，通过状态提升策略将表单状态集中管理，利用高阶组件实现逻辑解耦、复用能力和状态隔离。
🔑HOC 模式的核心在于 `getFieldDecorator`，它通过 `cloneElement` 为表单控件注入 `name`、`value` 和 `onChange` 属性，实现对表单状态的控制和更新。
⚠️HOC 模式存在性能缺陷，状态更新会触发整个组件树的重新计算，导致不必要的重渲染，且组件优化手段失效，状态粒度粗，组件层级复杂，调试困难。
✨4.x/5.x 版本引入 Hooks API，借鉴 Redux 思想，创建独立的 FormStore 管理状态，通过发布订阅模式实现更细粒度的状态更新，解决了 HOC 的固有问题。
✅Hooks API 版本通过 `useForm` Hook 和 FormContext 机制，将状态管理从组件中抽离，实现了组件的解耦和性能优化，并为表单功能的扩展提供了更大的灵活性。
原创 不爱动脑 2025-06-18 08:30 重庆
作为前端开发者，表单几乎是我们日常工作中最频繁接触的组件。而 Ant Design Form 又是 React 开发者最常用的组件库。从简单的登录框到复杂的数据录入界面，它几乎无处不在。
（💰金石瓜分计划15天倒计时，速戳上图了解详情🔍）❝作为前端开发者，表单几乎是我们日常工作中最频繁接触的组件。而 Ant Design Form 又是 React 开发者最常用的组件库。从简单的登录框到复杂的数据录入界面，它几乎无处不在。❞你是否曾好奇过它的实现原理？或者注意到从3.x到4.x版本时的那次重大变化？从Form.create()高阶组件到Form.useForm() Hooks API，这不仅是API设计的改变，更是整个表单状态管理思路的转变。这种演进背后有着怎样的技术考量？旧版实现存在哪些局限？新版又是如何解决这些问题的？本文将带你深入理解 Ant Design Form 的实现原理，探索从高阶组件到 Hooks 的演进历程。3.x 版本——HOC 模式设计思想在 3.x 版本中，Ant Design Form 的核心设计采用状态提升（State Lifting）策略。通过将表单控件（如 Input）和提交按钮的共有状态（values/errors）存储在它们最近的共同祖先组件中，实现了：跨组件状态共享统一校验逻辑数据流集中管理HOC 模式解析高阶组件（Higher-Order Component，HOC）是该版本的核心实现模式，其本质是一个函数，接受一个组件返回一个新组件的函数式编程范式。核心优势包括：「逻辑解耦」：分离表单逻辑与 UI 呈现「复用能力」：通用表单逻辑可跨组件复用「状态隔离」：维护独立的状态管理上下文实战演示：Form 表单 HOC 版本简化实现使用示例我们从一个简单的使用示例开始：const nameRules = {required: true, message: "请输入用户名！"};
const passwordRules = {required: true, message: "请输入密码！"};
@Form.create()
class MyForm extends Component {
componentDidMount() {
this.props.form.setFieldsValue({username: "小明"});
}
submit = () => {
const {getFieldsValue, validateFields} = this.props.form;
console.log("submit", getFieldsValue());
validateFields((err, val) => {
if (err) {
console.log("err", err);
} else {
console.log("校验成功", val);
}
});
};
render() {
const {getFieldDecorator} = this.props.form;
return (
<div>
<h3>MyForm</h3>
{getFieldDecorator("username", {rules: [nameRules]})(
<Input placeholder="Username" />
)}
{getFieldDecorator("password", {rules: [passwordRules]})(
<Input placeholder="Password" />
)}
<button onClick={this.submit}>submit</button>
</div>
);
}
}
export default MyForm;
手写 Form.create()以这个 demo 为例，如果我们要自己实现一个高阶组件来替代 Form.create() API，该如何着手呢？HOC 核心架构初始化首先高阶组件是接收一个组件，返回一个组件：import React, {Component} from "react";
export default function createForm(WrappedComponent) {
return class extends Component {
render() {
return <WrappedComponent {...this.props} />;
}
};
}
状态提升集中管理文章开头我们提到过，它使用状态提升实现了对表单数据的统一管理，结合我们的示例，数据流向示意图如下：Form.create()返回的HOC组件
├── 存储表单状态
└── 渲染 MyForm 组件 (对应WrappedComponent)
├── 渲染 Input 控件 (username)
├── 渲染 Input 控件 (password)
└── 渲染 submit 按钮
那么如何在 HOC 中收集这些状态呢？ 首先给它创建一个 state
用于存储所有表单项的值： return class extends Component {
constructor(props) {
super(props);
this.state = {};
}
}
至于收集，那就要依靠每个表单项外面包裹的 getFieldDecorator
了， 它是整个实现的关键： getFieldDecorator = (field, options) => (InputComponent) => {
return React.cloneElement(InputComponent, {
name: field,
value: this.state[field],
onChange: this.handleChange,
});
};
这里采用了双层函数的设计：第一层接收字段名和配置选项 第二层接收表单控件组件最终返回注入了特定属性的克隆组件通过 cloneElement，它为原始表单控件注入了三个关键属性：name：字段标识，用于追踪状态value：从 HOC 的 state 中读取值onChange：统一的事件处理函数当用户输入时，handleChange 方法被调用：handleChange = (e) => {
this.setState({
[e.target.name]: e.target.value,
});
};
这里使用了计算属性名，根据事件对象的 name 属性更新对应的状态。这样一来，所有表单控件的状态变更都会统一流向 HOC 的 state。最后，通过 getForm 方法将 getFieldDecorator 传递给被包装组件，完整代码如下：import React, { Component } from "react";
export default function createForm(WrappedComponent) {
return class extends Component {
constructor(props) {
super(props);
this.state = {};
}
handleChange = (e) => {
this.setState({
[e.target.name]: e.target.value,
});
};
getFieldDecorator = (field, options) => (InputComponent) => {
return React.cloneElement(InputComponent, {
name: field,
value: this.state[field],
onChange: this.handleChange,
});
};
validateFields = () => {};
getFieldsValue = () => {};
setFieldsValue = () => {};
getForm = () => {
return {
form: {
getFieldDecorator: this.getFieldDecorator,
validateFields: this.validateFields,
getFieldsValue: this.getFieldsValue,
setFieldsValue: this.setFieldsValue,
},
};
};
render() {
return <WrappedComponent {...this.props} {...this.getForm()} />;
}
};
}
这里为了防止代码报错，定义了 demo 中引用到的其他方法，正好大家也可以在这里暂停一下，拿这段代码作为起点，尝试自己实现 Form.create()
提供的其他的方法。表单 API 封装 (get、set、校验)getFieldsValue
和 setFieldsValue
实现起来是比较简单的：getFieldsValue = () => {
return { ...this.state };
};
setFieldsValue = (newState) => {
this.setState(newState);
};
这里我们重点看一下校验的实现：export default function createForm(WrappedComponent) {
return class extends Component {
constructor(props) {
super(props);
this.state = {};
this.options = {};
}
getFieldDecorator = (field, options) => (InputComponent) => {
this.options[field] = options;
};
validateFields = (callback) => {
let error = {};
for (let field in this.options) {
if (!this.state[field]) {
error[field] = this.options[field].required;
}
}
if (Object.keys(error).length > 0) {
callback(error, this.state);
} else {
callback(null, this.state);
}
};
};
}
整体工作流程：在表单初始化时，this.options 为空对象当使用 getFieldDecorator 装饰字段时，将校验规则存入 this.options用户点击提交按钮时，调用 validateFields 方法validateFields 遍历 this.options 中的所有字段进行校验将校验结果通过回调函数返回给调用者最终代码import React, { Component } from "react";
export default function createForm(WrappedComponent) {
return class extends Component {
constructor(props) {
super(props);
this.state = {};
this.options = {};
}
handleChange = (e) => {
this.setState({
[e.target.name]: e.target.value,
});
};
getFieldDecorator = (field, options) => (InputComponent) => {
this.options[field] = options;
return React.cloneElement(InputComponent, {
name: field,
value: this.state[field],
onChange: this.handleChange,
});
};
validateFields = (callback) => {
let error = {};
for (let field in this.options) {
if (!this.state[field]) {
error[field] = this.options[field].required;
}
}
if (Object.keys(error).length > 0) {
callback(error, this.state);
} else {
callback(null, this.state);
}
};
getFieldsValue = () => {
return { ...this.state };
};
setFieldsValue = (newState) => {
this.setState(newState);
};
getForm = () => {
return {
form: {
getFieldDecorator: this.getFieldDecorator,
validateFields: this.validateFields,
getFieldsValue: this.getFieldsValue,
setFieldsValue: this.setFieldsValue,
},
};
};
render() {
return <WrappedComponent {...this.props} {...this.getForm()} />;
}
};
}
思考HOC 实现的性能缺陷HOC 模式虽然设计巧妙，但其核心缺陷在于状态提升导致的渲染效率问题。由于表单状态集中存储在 HOC 组件中，任何字段的变化都会触发整个组件树的重新计算：每当用户在输入框中输入内容时，会引发以下级联反应：触发 handleChange 事件处理执行 this.setState() 更新 HOC 状态树HOC 组件因状态变化而重新渲染作为子组件的 MyForm 接收新的 props 引用，触发完整重渲染所有表单字段组件（包括未修改的）一同重新渲染大家可以在 MyForm
的 render 函数中打个 console 验证一下。这意味着即使用户仅修改 "用户名" 输入框，"密码" 输入框以及整个表单结构都会不必要地重新计算和渲染，在表单项较多或结构复杂时会造成明显的性能损耗。HOC 优化的局限性在 HOC 架构下，这类性能问题的解决面临多重障碍：组件优化手段失效：即使在被包装组件上应用 React.memo 或使用 PureComponent，由于每次都会接收新的 props 引用，浅比较机制无法阻止重渲染状态粒度问题：所有字段状态被合并在同一对象中（this.state），缺乏独立更新的机制，难以实现字段级的渲染优化组件层级复杂化：HOC 模式增加了组件嵌套深度，使性能优化需要在多个层级协同处理，增加了维护难度调试与追踪困难：由于 props 来源不直观，排查渲染性能问题时难以确定变更的确切来源这些问题正是 React Hooks 设计所要解决的关键痛点，也解释了为什么表单实现会从 HOC 模式转向 Hooks 模式。4.x/5.x 版本——Hooks API设计思想HOC 的状态提升存在一些固有的缺陷，比如组件嵌套层级过深、状态更新可能触发不必要的重渲染、状态管理逻辑与 UI 组件耦合等问题。那么，还有什么更好的方式来统一管理 Form 中的状态值呢？我们可以借鉴 Redux 的思想，创建一个独立的数据管理仓库（FormStore），通过发布订阅模式来实现状态管理。这种方式的核心是：将状态管理从组件中抽离出来，统一由 FormStore 来管理，并规定好这个数据仓库的 get、set 方法。当状态发生变化时，FormStore 会通知相关的订阅者（表单项组件）进行更新，而不是触发整个表单树的重渲染。这种实现方式不仅解决了 HOC 的固有问题，还为表单功能的扩展（如表单验证、依赖关系等）提供了更大的灵活性。通过发布订阅模式，我们可以实现更细粒度的状态更新，支持更复杂的表单联动，同时保持代码的可维护性和可测试性。实战演示：Form 表单 Hooks 版本简化实现使用示例还是从一个简单的使用示例开始：import React, { Component } from "react";
import { Form, Button, Input } from "antd";
const FormItem = Form.Item;
const nameRules = { required: true, message: "请输入姓名！" };
const passworRules = { required: true, message: "请输入密码！" };
export default function MyForm(props) {
const [form] = Form.useForm();
const onFinish = (val) => {
console.log("onFinish", val);
};
const onFinishFailed = (val) => {
console.log("onFinishFailed", val);
};
useEffect(() => {
console.log("form", form);
}, []);
return (
<div>
<h3>AntdFormPage</h3>
<Form
ref={formRef}
onFinish={onFinish}
onFinishFailed={onFinishFailed}
>
<FormItem rules={[nameRules]}>
<Input placeholder="username placeholder" />
</FormItem>
<FormItem rules={[passworRules]}>
<Input placeholder="password placeholder" />
</FormItem>
<FormItem>
<Button type="primary" size="large" htmlType="submit">
Submit
</Button>
</FormItem>
</Form>
</div>
);
}
架构设计在开始编码之前，我们需要先规划好整体架构。从使用示例来看，我们的简化版 Form 需要以下部分：Form 容器组件Form.Item 表单项组件FormStore 状态管理Context 通信机制/my-form
├── FormContext.js - 用于传递表单实例
├── Form.js - 表单容器组件
├── index.js - 导出入口文件
├── Item.js - 表单项组件
└── useForm.js - 表单状态管理逻辑
入口文件
import React from "react";
import _Form from "./Form";
import Item from "./Item";
const Form = React.forwardRef(_Form);
Form.Item = Item;
export { Item };
export default Form;
这里 React.forwardRef() 的作用是使 Form 组件能够接收并转发 ref 到其内部元素或组件。使用 forwardRef 后：可以直接 <Form ref={myRef}>...</Form>
，ref 会被正确传递不使用 forwardRef：<Form ref={myRef}>...</Form>
中的 ref 会被忽略，无法传递到组件内部❝在 React 19 中，所有函数组件都默认接收 ref 作为第二个参数。这意味着不再需要显式地使用 forwardRef 来包装组件，组件可以直接访问并使用 ref。❞Form.item 表单项组件第一步，把 Form.Item
包裹的组件变成受控组件。这个过程与旧版 antd 中的 getFieldDecorator HOC 原理类似。实现受控组件的关键技巧在于使用 React.cloneElement
'劫持'原始输入框，注入自定义的 value
和 onChange
属性，从而接管组件的数据流向。import React from "react";
export default function Item(props) {
const { children } = props;
const getControlled = () => {
return {
value: "初始值",
onChange: (e) => {
const newValue = e.target.value;
console.log("新的值", newValue);
},
};
};
const returnChildNode = React.cloneElement(children, getControlled());
return returnChildNode;
}
初始化状态管理库
class FormStore {
constructor() {
this.store = {};
}
getFieldsValue = () => {
return { ...this.store };
};
getFieldValue = (name) => {
return this.store[name];
};
setFieldsValue = (newStore) => {
this.store = {
...this.store,
...newStore,
};
};
getForm = () => {
return {
getFieldsValue: this.getFieldsValue,
getFieldValue: this.getFieldValue,
setFieldsValue: this.setFieldsValue,
};
};
}
那么当我们要使用 Form
的时候，应该在哪创建这个对象的实例呢？为避免表单状态丢失和重置，FormStore 实例应在组件首次渲染时创建一次，在多次渲染和状态更新时复用同一实例，只有在组件完全卸载后重新挂载时才创建新实例。这个场景我们应该想到 useRef：❝使用 ref 可以确保：可以在重新渲染之间 「存储信息」（普通对象存储的值每次渲染都会重置）。改变它 「不会触发重新渲染」（状态变量会触发重新渲染）。对于组件的每个副本而言，「这些信息都是本地的」（外部变量则是共享的）。 改变 ref 不会触发重新渲染，所以 ref 不适合用于存储期望显示在屏幕上的信息。如有需要，使用 state 代替。❞
import { useRef } from "react";
export default function useForm(form) {
const formRef = useRef();
if (!formRef.current) {
const formStore = new FormStore();
formRef.current = formStore.getForm();
}
return [formRef.current];
}
此时已经可以通过 useForm
钩子创建数据仓库实例了，但通过 useForm
钩子创建的表单数据仓库需要在 Form 组件树的各个层级间共享。由于表单组件（如 Form.Item、Input、Button 等）可能位于不同嵌套层级且需要统一访问表单状态，使用 props 逐层传递显然不够优雅。此时，React 的 Context API 提供了理想解决方案，允许我们在 Form 根组件提供数据仓库实例，并让任意层级的子组件直接访问，实现高效的跨层级状态共享。表单组件间通信首先，创建一个 Context 来共享表单实例：
import { createContext } from "react";
const FormContext = createContext();
export default FormContext;
接下来，在 Form 组件中，我们使用 Provider 将表单实例提供给子组件树。Form 组件是整个表单的容器，负责创建表单实例并通过 Context 分发给子组件：
import FormContext from "./FormContext";
import useForm from "./useForm";
export default function Form({ children, form }) {
const [formInstance] = useForm(form);
return (
<form>
<FormContext.Provider value={formInstance}>
{children}
</FormContext.Provider>
</form>
);
}
最后，在 Item 组件中，我们通过 useContext 访问表单实例，从而实现对输入控件的 "劫持"，将其转变为受控组件。这里的关键是 getControlled 方法，它为原始输入组件注入了 value 和 onChange 属性：
import React, { useContext } from "react";
import FormContext from "./FormContext";
export default function Item(props) {
const { children } = props;
const formInstance = useContext(FormContext);
const { getFieldValue, setFieldsValue } = formInstance;
const getControlled = () => {
return {
value: getFieldValue(props.name),
onChange: (e) => {
const newValue = e.target.value;
setFieldsValue({ [props.name]: newValue });
console.log("新的值", newValue);
},
};
};
const returnChildNode = React.cloneElement(children, getControlled());
return returnChildNode;
}
不过，需要注意的是，目前的实现还缺少响应式更新机制。虽然我们能够修改表单状态，但当 value 被修改后，它只存在于 React 的数据结构中（即虚拟 DOM），只有当 React 执行渲染过程时，这个修改才会被应用到实际的 DOM 元素上。即 value 是 input 上的属性，input 作为一个 HTML 元素，不重新渲染 React 组件是无法更新这个属性的。没有渲染，变化就停留在虚拟 DOM 层面，用户界面上的 input 元素不会更新。要实现真正的响应式表单，我们还需要添加订阅发布机制，让 FormStore 在状态变化时能够通知相关的表单项组件进行更新。通过发布订阅实现响应式更新实现订阅首先，我们需要建立一个中央存储系统来管理表单状态和订阅者：
class FormStore {
constructor() {
this.store = {};
this.itemEntities = [];
}
registerItemEntities = (entity) => {
this.itemEntities.push(entity);
return () => {
this.itemEntities = this.itemEntities.filter((item) => item !== entity);
delete this.store[entity.props.name];
};
};
getForm = () => {
return {
registerItemEntities: this.registerItemEntities,
};
};
}
「使用数组存储订阅者，」itemEntities
数组存储了所有需要响应数据变化的表单项组件。当表单数据发生变化时，我们可以遍历这个数组，通知每个订阅者进行更新。「为什么返回取消订阅函数？」 这是一个经典的订阅模式实现。返回的函数用于组件卸载时清理订阅关系，防止内存泄漏。这种设计让订阅和取消订阅的逻辑保持一致性。「为什么同时删除 store 中的数据？」 当组件卸载时，对应的表单字段也应该从数据存储中移除，保持数据的一致性和内存的有效利用。Item 组件中的订阅处理
export default function Item(props) {
const {children, name} = props;
const {
getFieldValue,
setFieldsValue,
registerItemEntities,
} = React.useContext(FormContext);
const [, forceUpdate] = React.useReducer((x) => x + 1, 0);
React.useLayoutEffect(() => {
const unregister = registerItemEntities({
props,
onStoreChange: forceUpdate,
});
return unregister;
}, []);
}
这里为什么不能用 useEffect 呢？这是因为执行时机的差异：useLayoutEffect
会在浏览器执行绘制之前「同步调用」，确保在用户看到页面之前就完成了订阅useEffect
是异步执行的，会导致「页面先渲染一次后再订阅」，造成闪烁或初始值不正确的问题实现发布发布机制负责在数据变化时通知所有相关的订阅者：
setFieldsValue = (newStore) => {
this.store = {
...this.store,
...newStore,
};
this.itemEntities.forEach((entity) => {
Object.keys(newStore).forEach((k) => {
if (k === entity.props.name) {
entity.onStoreChange();
}
});
});
};
表单提交表单提交需要一个统一的入口来处理成功和失败的回调：
import React from "react";
import FormContext from "./FormContext";
import useForm from "./useForm";
export default function Form(
{ children, form, onFinish, onFinishFailed },
ref
) {
const [formInstance] = useForm(form);
formInstance.setCallbacks({
onFinish,
onFinishFailed,
});
return (
<form
onSubmit={(e) => {
e.preventDefault();
formInstance.submit();
}}
>
<FormContext.Provider value={formInstance}>
{children}
</FormContext.Provider>
</form>
);
}
「为什么每次渲染都调用 setCallbacks？」 由于函数组件每次渲染都会重新执行，onFinish
和 onFinishFailed
可能是新的函数引用。通过每次都调用 setCallbacks
，确保 FormStore 中保存的始终是最新的回调函数。表单校验提交和校验需要 Form.Item 中的数据，所以也得放在 FormStore 中统一处理。
validate = () => {
let err = [];
this.itemEntities.forEach((entity) => {
const { name, rules } = entity.props;
const value = this.getFieldValue(name);
let rule = rules[0];
if (rule && rule.required && (value === undefined || value === "")) {
err.push({ [name]: rule.message, value });
}
});
return err;
};
总结无论是 HOC 还是 Hooks 的实现方式，都蕴含着丰富的设计智慧值得我们深入学习。虽然 HOC 在现代 React 开发中逐渐被 Hooks 所取代，但其装饰器模式的核心思想依然具有重要的借鉴价值。或许一直使用 antd Form 这样的成熟组件库并不会遇到什么问题，但当我们亲自动手实现 FormStore 时，就能更深刻地理解独立状态管理仓库的设计哲学。这种理解是可以举一反三的——我们能够更好地掌握 Redux、Zustand 等状态管理库的核心原理，也能深刻理解为什么 React 18 要推出 useSyncExternalStore 这样的 Hook 来解决并发渲染场景下的状态同步问题。技术的每一次演进都是为了解决实际开发中遇到的具体问题。作为开发者，我们不应该仅仅满足于掌握 API 的使用方法，更重要的是要透过源码看到作者的技术理念和设计范式。代码本身只是这些抽象思想的具象表达，真正有价值的是隐藏在代码背后的设计哲学和解决问题的思维方式。AI编程资讯AI Coding专区指南：https://aicoding.juejin.cn/aicoding
点击"阅读原文"了解详情~
阅读原文
跳转微信打开
