# 高阶组件（HOC）：最经典的组件逻辑复用方式

# 什么是高阶组件

高阶组件（HOC）是 React 中用于复用组件逻辑的一种高级技巧。HOC 自身不是 React API 的一部分，它是一种基于 React 的组合特性而形成的设计模式。——React 官方

高阶函数的概念：接收函数作为输入，或者输出另一个函数的一类函数，就是高阶函数。

相应的，高阶组件指的就是参数为组件，返回值为新组件的函数。没错，高阶组件本质上是一个函数。下面是一个简单的高阶组件示例：

const withProps = (WrappedComponent) => {
    const targetComponent = (props) => (
        <div className="wrapper-container">
            <WrappedComponent {...props} />
        </div>
    );
    return targetComponent;
};

@前端进阶之旅: 代码已经复制到剪贴板

在这段代码中，withProps 就是一个高阶组件。

# 高阶组件是如何实现逻辑复用的？

现在我们考虑这样一种情况：我有一个名为 checkUserAccess 的方法，这个方法专门用来校验用户的身份是否合法，若不合法，那么一部分组件就要根据这个不合法的身份调整自身的展示逻辑（比如查看个人信息界面需要提示“请校验身份”等）。

假如说页面中的 A、B、C、D、E 五个组件都需要甄别用户身份是否合法，那么这五个组件在理论上都需要先请求一遍 checkUserAccess 这个接口。但一个一个对组件进行修改未免太麻烦了，我们期望对“获取 checkUserAccess 接口信息，并通知到对应组件”这层逻辑进行复用，这时候就可以请出高阶组件来帮忙了。

我们可以像下面代码这样在高阶组件中定义这层通用的逻辑：

// 假设 checkUserAccess 已经在 utils 文件中被封装为了一段独立的逻辑
import checkUserAccess from './utils
// 用高阶组件包裹目标组件
const withCheckAccess = (WrappedComponent) => {
    // 这部分是通用的逻辑：判断用户身份是否合法
    const isAccessible = checkUserAccess()  
    // 将 isAccessible（是否合法） 这个信息传递给目标组件
    const targetComponent = (props) => (
        <div className="wrapper-container">
            <WrappedComponent {...props} isAccessible={isAccessible} />
        </div>
    );
    return targetComponent;
};

@前端进阶之旅: 代码已经复制到剪贴板

这样当我们需要为某个组件复用这层请求逻辑的时候，只需要直接用 withCheckAccess 包裹这个组件就可以了。以 A 组件为例，假设 A 组件的原始版本为 AComponent，那么包裹它的形式就是下面代码这样：

const EnhancedAComponent = withCheckAccess(Acomponent);

@前端进阶之旅: 代码已经复制到剪贴板

通过简单地对高阶组件 withCheckAccess 进行引入，EnhancedAComponent 轻松具备了校验用户合法性的能力。这样一来，即便再多出 5 个组件想要引入 checkUserAccess，我们也不会怂——毕竟包裹五个组件和重写五段逻辑的工作量是没法相提并论的

高阶组件不仅能够帮助我们简化逻辑的引入过程，还可以帮助我们规避掉逻辑变更带来的烦琐的修改步骤：假如这段 checkUserAccess 的逻辑是散落在 A、B、C、D、E 这五个组件之中的，那么一旦 checkUserAccess 的判定规则需要修改，我们就得需要去修改五段代码；但现在，checkUserAccess 被抽离进了一个独立的高阶组件里，我们在高阶组件中的一次修改，将在所有被它处理过的组件中生效。

由此可以看出，高阶组件可以帮助我们从根本上减少重复的编写和修改工作，这不仅是高阶组件这一种模式的利好，更是“逻辑复用”这件事情的意义所在。

# Render Props：逻辑复用的另一种思路

术语“render prop”是指一种在 React 组件之间使用一个值为函数的 prop 共享代码的简单技术。——React 官方

# 什么是 render props

render props 是 React 中复用组件逻辑的另一种思路，它在实现上和高阶组件有异曲同工之妙——两者都是把通用的逻辑提取到某一处。区别主要在于使用层面，高阶组件的使用姿势是用“函数”包裹“组件”，而 render props 恰恰相反，它强调的是用“组件”包裹“函数”

一个简单的 render props 可以是这样的，见下面代码：

import React from 'react'  
const RenderChildren = (props) => {
  return(
     <React.Fragment>
        {props.children(props)}
     </React.Fragment>
  );
};

@前端进阶之旅: 代码已经复制到剪贴板

RenderChildren 将渲染它所有的子组件。从这段代码里，你需要把握住两个要点：

render props 的载体应该是一个React 组件，这一点是与高阶组件不同的（高阶组件本质是函数）；
render props 组件正常工作的前提是它的子组件需要以函数形式存在。

第 1 点相对明显一点，你可能会对第 2 点感到迷惑。没关系，我们直接来看 RenderChildren 的使用方式，请看下面代码：

<RenderChildren>         
  {() => <p>我是 RenderChildren 的子组件</p>}       
</RenderChildren>

@前端进阶之旅: 代码已经复制到剪贴板

RenderChildren 本身是一个 React 组件，它可以包裹其他的 React 组件。一般来说，我们习惯于看到的包裹形式是“标签包裹着标签”，也就是下面代码演示的这种效果：

<RenderChildren>         
  <p>我是 RenderChildren 的子组件</p>     
</RenderChildren>

@前端进阶之旅: 代码已经复制到剪贴板

但在 render props 这种模式下，它要求被 render props 组件标签包裹的一定是个函数，也就是所谓的“函数作为子组件传入”。这样一来，render props 组件就可以通过调用这个函数，传递 props，从而实现和目标组件的通信了。

# render props 是如何实现逻辑复用的

这里我仍然以 checkUserAccess 这个场景举例。使用 render props 复用 checkUserAccess 这段逻辑，我们可以这样做，请看下面代码：

// 假设 checkUserAccess 已经在 utils 文件中被封装为了一段独立的逻辑
import checkUserAccess from './utils
// 定义 render props 组件
const CheckAccess = (props) => {
    // 这部分是通用的逻辑：判断用户身份是否合法
    const isAccessible = checkUserAccess()  
    // 将 isAccessible（是否合法） 这个信息传递给目标组件
    return <React.Fragment>
        {props.children({ ...props, isAccessible })}
      </React.Fragment>
};

@前端进阶之旅: 代码已经复制到剪贴板

接下来 CheckAccess 子组件就可以这样获取 isAccessible 的值，见下面代码：

<CheckAccess>
  {
    (props) => {
      const { isAccessible } = props;
      return <ChildComponent {...props} isAccessible={isAccessible} />
    }
  }
</CheckAccess>

@前端进阶之旅: 代码已经复制到剪贴板

到这里，“函数作为子组件传入”这种情况，我们已经了解了它的来龙去脉。但其实，对于 render props 这种模式来说，函数并不一定要作为子组件传入，它也可以以任意属性名传入，只要 render props 组件可以感知到它就行`。

举个例子，我可以允许函数通过一个名为 checkTaget 的属性传入 render props 组件，那么 CheckAccess 组件只需要改写一下它接收函数的形式即可，见下面代码：

// 假设 checkUserAccess 已经在 utils 文件中被封装为了一段独立的逻辑
import checkUserAccess from './utils
// 定义 render props 组件
const CheckAccess = (props) => {
    // 这部分是通用的逻辑：判断用户身份是否合法
    const isAccessible = checkUserAccess()  
    // 将 isAccessible（是否合法） 这个信息传递给目标组件
    return <React.Fragment>
        {props.checkTaget({ ...props, isAccessible })}
      </React.Fragment>
};

@前端进阶之旅: 代码已经复制到剪贴板

在使用 CheckAccess 组件的时候，我们将函数放在 checkTaget 中传入组件即可，见下面代码：

<CheckAccess
    checkTaget={(props) => {
      const { isAccessible } = props;
      return <ChildComponent {...props} isAccessible={isAccessible} />
    }}
  />

@前端进阶之旅: 代码已经复制到剪贴板

像这样使用 render props，也是完全可以的。

# 理解 render props 的灵活之处

读到这里，你不免会产生这样的困惑：高阶组件和 render props 都能复用逻辑，那我到底用哪个好呢？

这里我先给出结论：render props 将是你更好的选择，因为它更灵活。这“更灵活”从何说起呢？

render props 和高阶组件一个非常重要的区别，在于对数据的处理上：在高阶组件中，目标组件对于数据的获取没有主动权，数据的分发逻辑全部收敛在高阶组件的内部；而在 render props 中，除了父组件可以对数据进行分发处理之外，子组件也可以选择性地对数据进行接收

这样说你可能会觉得有点抽象，我举个例子：假如说我们现在多出一个 F 组件，它同样需要 checkUserAccess 这段逻辑。但是这个 F 组件是一个老组件，它识别不了 props.isAccessible，只认识 props.isValidated。带着这个需求，我们先来看看高阶组件怎么解决问题。原有的高阶组件逻辑是下面这样的：

它会不由分说地给所有组件安装上 isAccessible 这个变量。要想让它适配 F 组件的逻辑，最直接的一个思路就是在 withCheckAccess 中增加一个组件类型的判断，一旦判断出当前入参是 F 组件，就专门将 isAccessible 改名为 isValidated。

这样做虽然能够暂时解决问题，但这并不是一个灵活的解法：假如需要改属性名的组件越来越多，那么withCheckAccess 内部将不可避免变得越来越臃肿，长此以往将难以维护。

什么是“单一职责”原则？

设计模式虽好，但它并非万能。

跟 React 学设计模式|原理篇

跟 React 学设计模式|原理篇