文档技术博客教程【免费下载链接】weekly前端精读周刊。帮你理解最前沿、实用的技术。项目地址https://gitcode.com/GitHub_Trending/we/weekly点击查看免费下载本文是《前端精读周刊》系列技术指南之一完整原文见 前沿技术/12.精读《React 高阶组件》.md。HOCHigher-Order Component高阶组件是 React 中复用组件逻辑的核心进阶技巧本文将以该精读为主体完整讲解 HOC 的两种实现方式Props Proxy 与 Inheritance Inversion、适用范围判断标准以及它在数据请求、Form 表单校验等真实场景中的落地写法并延伸到 render props 与 Hooks 的演进对比帮助读者在业务中做出正确的抽象选型。引言从高阶函数到高阶组件高阶组件higher-order componentHOC是 React 中复用组件逻辑的一种进阶技巧。需要特别强调的是它本身并不是 React 的 API而是一种 React 组件的设计理念是社区在实践中沉淀出的组合模式。众多 React 库已经证明了它的价值例如耳熟能详的 react-redux 就是通过 HOC 把 store 注入到组件中的。理解 HOC 最自然的路径是类比高阶函数Higher-Order Function高阶函数是把函数作为参数传入到函数中并返回一个新的函数这里把函数替换为组件就是高阶组件了。用一行公式可以概括 HOC 的调用形态const EnhancedComponent higherOrderComponent(WrappedComponent);即输入一个组件输出一个增强后的新组件。需要注意的是只理解概念只是万里长征第一步HOC 的实现方式、适用范围、局限性以及与替代方案的比较才是真正决定能否用好它的关键。下面从两种主流实现方式讲起。高阶组件的两种核心实现方式HOC 常见有两种实现方式**Props Proxy属性代理**与Inheritance Inversion反向继承。二者能力边界与侵入性截然不同。Props Proxy属性代理Props Proxy 能够对 WrappedComponent 的 props 进行操作提取 WrappedComponent 的 state以及使用其他元素来包裹 WrappedComponent。它的核心思路是HOC 在渲染层作为一层代理把处理后的 props 传给被包裹组件。一个值得注意的细节是Props Proxy 作为一层代理具有隔离作用因此传入 WrappedComponent 的 ref 将无法直接访问到其本身需要在 Props Proxy 内部完成中转。此外各个 Props Proxy 的默认名称是相同的例如下面代码中的类名PP导致在 React DevTools 中难以区分不同 HOC 增强后的组件因此需要根据 WrappedComponent 进行不同命名。完整的参考实现如下function ppHOC(WrappedComponent) { return class PP extends React.Component { // 实现 HOC 不同的命名 static displayName HOC(${WrappedComponent.displayName}); getWrappedInstance() { return this.wrappedInstance; } // 实现 ref 的访问 setWrappedInstance(ref) { this.wrappedInstance ref; } render() { return WrappedComponent { ...this.props, ref: this.setWrappedInstance.bind(this), } / } } } ppHOC class Example extends React.Component { static displayName Example; handleClick() { ... } ... } class App extends React.Component { handleClick() { this.refs.example.getWrappedInstance().handleClick(); } render() { return ( div button onClick{this.handleClick.bind(this)}按钮/button Example refexample / /div ); } }这段代码中有三个关键点值得拆解displayName 命名static displayName \HOC(${WrappedComponent.displayName})会在 DevTools 中显示为HOC(Example)这样的可读名称避免多个 HOC 都显示成PP 这类雷同名字方便调试定位。ref 中转在render()中ref被当作 props 传给 WrappedComponentReact 内部会把ref从普通 props 中剥离并作为实例引用处理通过ref: this.setWrappedInstance.bind(this)回调把被包裹组件的真实实例存到 HOC 的this.wrappedInstance上。实例暴露外部通过this.refs.example.getWrappedInstance()拿到被包裹组件的真实实例从而绕过 Props Proxy 的隔离直接调用handleClick()等实例方法。这里ppHOC是装饰器Decorator语法需要 Babel 的 decorators 插件支持它本质上是ppHOC(Example)的语法糖。react-redux 的connect也正是采用这种 Props Proxy 思路实现的外层拦截 props 注入 dispatch 与 state 切片内层再把完整 props 传给业务组件。Inheritance Inversion反向继承另一种实现是 Inheritance Inversion。此时 HOC 类继承了 WrappedComponent这意味着 HOC 可以访问到 WrappedComponent 的 state、props、生命周期和 render 等方法function ppHOC(WrappedComponent) { return class ExampleEnhance extends WrappedComponent { ... componentDidMount() { super.componentDidMount(); } componentWillUnmount() { super.componentWillUnmount(); } render() { ... return super.render(); } } }由于继承关系HOC 类天然拥有父类的实例方法与状态但同时带来两个关键约束同名方法覆盖如果在 HOC 中定义了与 WrappedComponent 同名的方法将会发生覆盖此时就必须手动通过super进行调用了。例如上面代码中HOC 自定义了componentDidMount与componentWillUnmount都需要显式super.componentDidMount()才能保留父类原有的生命周期逻辑。渲染劫持Render Hijacking通过完全操作super.render()返回的元素树React 元素树可以真正实现渲染劫持——例如在渲染前插入/删除元素、修改子元素的 props甚至直接不调用super.render()来阻止渲染。这种方案依然是继承的思想对 WrappedComponent 有较强的侵入性父类的内部实现细节state 结构、渲染输出都被 HOC 直接耦合因此在真实项目中并不常见。相比之下Props Proxy 的组合代理思路更贴合 React 的组合哲学应用更广。高阶组件的适用范围逻辑与 DOM 的三种关联理解了实现方式之后更现实的问题是什么时候该用 HOC什么时候该用普通父组件对比 HOC 范式compose(render)(state)与父组件Parent Component的范式render(render(state))如果完全利用 HOC 来实现 React 的应用将操作与 view 分离也未尝不可但却不优雅。HOC 本质上是统一功能抽象强调逻辑与 UI 分离而在实际开发中前端无法逃离 DOM逻辑与 DOM 的相关性主要呈现 3 种关联形式关联形式建议方案说明与 DOM 相关使用父组件类似于原生 HTML 编写是 React JSX 原生支持的方式清晰易懂与 DOM 不相关使用 HOC 抽象如校验、权限、请求发送、数据转换这类通过数据变化间接控制 DOM交叉部分DOM 相关但完全内聚均可这些 DOM 不会和外部有关联两种方案都能胜任DOM 的渲染适合使用父组件这是 React JSX 原生支持的方式清晰易懂最好能封装成木偶组件Dumb Component。HOC 适合做 DOM 不相关、又是多个组件共性的操作。一个典型的例子是 Form 场景validator 校验操作是纯数据操作被放到了 HOC 中但 validator 的元信息比如校验规则没有放到 HOC 中。反过来如果能把 Error 信息展示这类逻辑完全隔离也可以放到 HOC 中可结合下文 Form 的具体实践详细了解。典型场景一数据请求react-refetch数据请求是另一类 DOM 不相关的场景。react-refetch的实现就使用了 HOC做到了高效和优雅——组件本身完全不关心请求如何发起、数据从哪来只声明我依赖哪些接口connect(props ({ usersFetch: /users?status${props.status}page${props.page}, userStatsFetch: { url: /users/stats, force: true } }))(UsersList)可以看到connect返回的 HOC 接收一个由 props 推导出请求描述的函数字符串形式如/users?status...page...表示普通的 GET 请求对象形式如{ url: /users/stats, force: true }则可以附带force等请求行为配置。被包裹的UsersList组件完全只关心渲染取数逻辑被整体隔离在 HOC 层这正是逻辑与 UI 分离理念的落地。典型场景二通过 HOC 抽象 Form 表单校验HOC 在真实场景中的运行非常多。Form 组件就是最能体现 HOC良好扩展机制的案例下面通过 Form 组件的抽象来完整还原这一实践。为什么 Form 必须抽象功能而非 UI一个 Form 中会包含各种不同的组件常见的有 Input、Selector、Checkbox 等也会有根据业务需求加入的自定义组件。Form 灵活多变从功能上看表单校验可能为单组件值校验也可能为全表单值校验可能为常规校验如非空、输入限制也可能需要与服务端配合甚至需要根据业务特点进行定制从 UI 上看校验结果显示的位置可能在组件下方也可能是在组件右侧。直接裸写 Form 无疑是机械而又重复的。观察所有 Form 的共性路径将 Form 中组件的 value 经过 validator把 value 与 validator 产生的 error 信息储存到 state 或 redux store 中然后在 view 层完成显示。这条路大家都是相同的可以进行复用只是我们面对的是不同的组件、不同的 validator、不同的 view 而已。对于 Form 而言既要满足通用又要满足部分个性化的需求。以往单纯的配置化只会让使用愈加繁琐因此我们所需要抽象的是Form 功能而非 UI——通过 HOC 针对 Form 的功能进行提取就成为了必然。具体实现formFactoryFactory 与 Decorator首先将表单中的组件Input、Selector...与相应 validator 及组件值回调函数名trigger传入 Decorator将 validator 与 trigger 相绑定。Decorator 完成了各种不同组件与 Form 内置 Store 间 value 的传递、校验功能的抽象——这正是精读文章中 Props Proxy 方式的其中两种作用提取 state与操作 propsfunction formFactoryFactory({ validator, trigger onChange, ... }) { return FormFactory(WrappedComponent) { return class Decorator extends React.Component { getBind(trigger, validator) { ... } render() { const newProps { ...this.props, [trigger]: this.getBind(trigger, validator), ... } return WrappedComponent {...newProps} / } } } } // 调用 formFactoryFactory({ validator: (value) { return value ! ; } })(Input placeholder请输入... /)这里出现了一个工厂套工厂的结构值得展开最外层formFactoryFactory接收配置validator 校验函数、trigger 事件名默认onChange它的作用是为不同组件定制化每个表单控件可以传入自己的 validator 与触发时机中间层FormFactory(WrappedComponent)与内层Decorator是标准的 Props Proxy 形态在render()中通过...this.props保留原有 props再把[trigger]: this.getBind(trigger, validator)动态注入到 newProps 中——getBind内部会把用户触发事件与validator 校验绑定起来形成值变化即校验的闭环。这样一来Input只需要声明我的校验规则是 value 非空HOC 就自动替它完成了值同步与校验UI 层零侵入。Form Store 与个性化校验setError 的用法当然为了考虑个性化需求Form Store 也向外暴露很多 API可以直接获取和修改 value、error 的值。例如现在需要对一个表单的所有值提交到后端进行校验根据后端返回分别列出各项的校验错误信息就需要借助相应项的setError去完成——先正常收集 value 提交后端再逐项调用 setError 把后端返回的错误信息写回对应的字段。这里主要参考了rc-form的实现方式。rc-form通过createForm这个 HOC 包装组件在 props 中注入form对象提供getFieldDecorator字段装饰绑定取值与规则、getFieldError读取字段错误、validateFields整体校验等能力import { createForm } from rc-form; class Form extends React.Component { submit () { this.props.form.validateFields((error, value) { console.log(error, value); }); } render() { const { getFieldError, getFieldDecorator } this.props.form; const errors getFieldError(required); return ( div {getFieldDecorator(required, { rules: [{ required: true }], })(Input /)} {errors ? errors.join(,) : null} button onClick{this.submit}submit/button /div ); } } export createForm()(Form);这段代码精确展示了 HOC 在 Form 场景的完整闭环createForm()(Form)将普通 Form 组件包装为受控表单组件getFieldDecorator(required, { rules: [...] })(Input /)返回一个高阶装饰函数把 Input 绑定到名为required的表单字段上并注入校验规则——这本质上是 HOC 思想的函数化变体返回的装饰函数内部依然是对组件的包装与 props 注入getFieldError(required)读取该字段当前错误渲染到组件下方errors ? errors.join(,) : null解决校验结果展示位置的个性化问题validateFields((error, value) ...)在提交时对全表单做统一校验回调中拿到整体错误对象与值对象。由此可见rc-form把值存取、校验、错误读取全部抽象进了 HOC/装饰器层业务组件只负责声明字段名与规则同时通过form暴露的 API 保留了足够的个性化出口如自定义 setError、自定义展示位置。HOC 的局限性嵌套、命名冲突与 props 覆盖掌握 HOC 的威力之后同样需要正视它的代价。周刊后续的 前沿技术/31.精读《我不再使用高阶组件》.md 一文对 HOC 的问题做了集中剖析嵌套地狱与黑盒HOC 可嵌套叠加如果有一环 HOC 没有将内部 wrappedComponent 暴露出来会导致后续叠加的 HOC 都无法获取、注入到原始组件即使所有 HOC 都遵循规范组件也难以察觉被注入的数据是由哪些 HOC 提供的props 覆盖风险HOC 之间互相隔离多个 HOC 可能注入同名 props导致相互覆盖的危险情况而这些问题 HOC 都束手无策约定 vs 约束HOC 依赖命名规范这类软约定如所有 HOC 统一叫EnhancedComponent而约定的可维护性低于硬约束。正因为这些局限社区才逐步演进出了替代方案这也是理解 HOC 时不可缺失的一环。替代方案的演进render props 与 React Hooksrender props看得见的数据流针对 HOC 的嵌套黑盒问题render props也叫 render callback、function as child方案直接把要注入什么写成 JSX 子元素函数import React, { Component } from react; import PropTypes from prop-types; class Caffeinate extends Component { propTypes { children: PropTypes.func.isRequired }; state { coffee: Americano }; render() { return this.props.children(this.state.coffee); } }使用时将函数作为子元素可以认为是一个匿名组件render( Caffeinate {(beverage) divDrinking an {beverage}./div} /Caffeinate, document.querySelector(#root) ); // Drinking an Americano.相比 HOCrender props 的开放性提升明显原本 HOC 所做的功能抽象可通过 render props 获取render 函数内也可以访问到父级的一切嵌套结构在 JSX 中一目了然数据流动清晰可见解决了 HOC 反复嵌套导致的各类问题详见 前沿技术/31.精读《我不再使用高阶组件》.md。当然 render props 也有自己的短板this.props.children本不该作为函数调用渲染粒度变大表格等需要性能优化的场景不适合render props 渲染的并不是 React 组件无法单独为其接入 redux、mobx、dob 等依赖收集粒度。因此在精读中也强调这些最佳实践在不同场景、不同团队、不同项目下都有所侧重不必追求唯一完美写法——在不为组件做注入的场景下如利用生命周期实现权限、埋点层级少时 HOC 依然非常方便。React Hooks官方给出的第三种状态共享方案React Hooks 被官方定位为继 render props 和 HOC 之后的第三种状态共享方案准确说是状态逻辑复用——只共享数据处理逻辑不共享数据本身并且不会产生 JSX 嵌套地狱问题。以useState为例function App() { const [open, setOpen] useState(false); return ( Button typeprimary onClick{() setOpen(true)} Open Modal /Button Modal visible{open} onOk{() setOpen(false)} onCancel{() setOpen(false)} / / ); }这段代码等价于一个内置的打平 renderProps随时创建一个值与修改这个值的方法同时保持代码平铺、无嵌套。Hooks 还可以引用其他 Hooks自定义 Hook 组合更容易将组件的 UI 与状态分离详见 前沿技术/79.精读《React Hooks》.md。从精读 前沿技术/132.精读《正交的 React 组件》.md 的正交性视角看Hooks 解决了状态管理与 UI 分离的问题与 HOC 的逻辑与 UI 分离追求一脉相承但约束更强use命名约定、顶层调用顺序也因此更可预期。而从 前沿技术/95.精读《Function VS Class 组件》.md 的角度看Function Component Hooks 还天然具备 capture props / capture value 特性进一步强化了纯函数化 UI 组件的写法。需要说明的是HOC 并未因此消亡react-redux、react-refetch、rc-form 等生态依然以 HOC 为根基对于无法使用 Hooks 的 Class 组件场景、以及按层注入能力这种正交抽象的诉求HOC 仍是简洁可靠的选项。总结React 始终强调组合优于继承的理念期望通过复用小组件来构建大组件使开发变得简单而又高效这与传统面向对象思想是截然不同的。HOC 的出现替代了原有 Mixin 侵入式的方案——对比隐式的 Mixin 或是继承HOC 能够在 DevTools 中显示出来通过 displayName满足抽象之余也方便了开发与测试。回到本精读的完整脉络值得记住的核心结论有三条实现上Props Proxy 通过组合代理实现可操作 props、提取 state、包裹元素、中转 refInheritance Inversion 通过继承实现可访问 state/生命周期、可渲染劫持前者更贴合 React 组合哲学、应用更广选型上与 DOM 强相关用父组件与 DOM 无关的共性逻辑校验、权限、请求、数据转换用 HOC完全内聚的交叉场景两者皆可心态上不可过度抽象是始终要秉持的原则。HOC、render props 与 Hooks 各有适用边界结合具体的业务开发场景做取舍比追逐最完美实践更有价值。延伸阅读本文内容源自周刊第 12 期精读与 前沿技术/31.精读《我不再使用高阶组件》.mdHOC 的局限与 render props 对比、前沿技术/79.精读《React Hooks》.mdHooks 作为第三种状态共享方案、前沿技术/132.精读《正交的 React 组件》.md正交抽象视角、前沿技术/95.精读《Function VS Class 组件》.md函数组件的演进互为补充可在 readme.md 中查看周刊全部主题索引。赞分享文档技术博客教程【免费下载链接】weekly前端精读周刊。帮你理解最前沿、实用的技术。项目地址https://gitcode.com/GitHub_Trending/we/weekly点击查看免费下载相关推荐React in Patterns 组合篇下高阶组件 HOC 与 Render Props 深度对比到底该选谁React in Patterns 组合篇下高阶组件 HOC 与 Render Props 深度对比到底该选谁 在《React in Patterns教程前端react-bits 实战用 Props Proxy 高阶组件统一增改 Props处理多品牌 UX 变体react bits 实战用 Props Proxy 高阶组件统一增改 Props处理多品牌 UX 变体 导读 本文聚焦 react bits 仓库中 ux前端教程React组件设计模式FE-Interview中的HOC与Render PropsReact组件设计模式FE Interview中的HOC与Render Props 在React开发中组件复用一直是前端工程师需要攻克的难题。当你的项目中出教程前端上一篇Humanizer 本地化接口 IDateOnlyToOrdinalWordConverter 深度解析DateOnly 序数词日期的转换机制与自定义实现下一篇MyBatis原生镜像构建教程Spring Boot 4.0与GraalVM集成完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考