React中怎么实现组件逻辑复用，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
创新互联建站于2013年开始，先为沂源等服务建站，沂源等地企业，进行企业商务咨询服务。为沂源企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
1. Mixins
Mixins 事实上是 React.createClass 的产物了。当然，如果你曾经在低版本的 react 中使用过 Mixins，例如 react-timer-mixin， react-addons-pure-render-mixin，那么你可能知道，在 React 的新版本中我们其实还是可以使用 mixin，虽然 React.createClass 已经被移除了，但是仍然可以使用第三方库 create-react-class，来继续使用 mixin。甚至，ES6 写法的组件，也同样有方式去使用 mixin。当然啦，这不是本文讨论的重点，就不多做介绍了，如果你维护的老项目在升级的过程中遇到这类问题，可以与我探讨。
新的项目中基本不会出现 Mixins，但是如果你们公司还有一些老项目要维护，其中可能就应用了 Mixins，因此稍微花点时间，了解下 Mixins 的使用方法和原理，还是有必要的。倘若你完全没有这方面的需求，那么跳过本节亦是可以的。
Mixins 的使用
React 15.3.0 版本中增加了 PureComponent。而在此之前，或者如果你使用的是 React.createClass 的方式创建组件，那么想要同样的功能，就是使用 react-addons-pure-render-mixin，例如:
//下面代码在新版React中可正常运行，因为现在已经无法使用 `React.createClass`，我就不使用 `React.createClass` 来写了。 const createReactClass = require('create-react-class'); const PureRenderMixin = require('react-addons-pure-render-mixin'); const MyDialog = createReactClass({ displayName: 'MyDialog', mixins: [PureRenderMixin], //other code render() { return ( {/* other code */} ) } });首先，需要注意，mixins 的值是一个数组，如果有多个 Mixins，那么只需要依次放在数组中即可，例如: mixins: [PureRenderMixin, TimerMixin]。
Mixins 的原理
Mixins 的原理可以简单理解为将一个 mixin 对象上的方法增加到组件上。类似于 $.extend 方法，不过 React 还进行了一些其它的处理，例如：除了生命周期函数外，不同的 mixins 中是不允许有相同的属性的，并且也不能和组件中的属性和方法同名，否则会抛出异常。另外即使是生命周期函数，constructor 、render 和 shouldComponentUpdate 也是不允许重复的。
而如 compoentDidMount 的生命周期，会依次调用 Mixins，然后再调用组件中定义的 compoentDidMount。
例如，上面的 PureRenderMixin 提供的对象中，有一个 shouldComponentUpdate 方法，即是将这个方法增加到了 MyDialog 上，此时 MyDialog 中不能再定义 shouldComponentUpdate，否则会抛出异常。
//react-addons-pure-render-mixin 源码 var shallowEqual = require('fbjs/lib/shallowEqual'); module.exports = { shouldComponentUpdate: function(nextProps, nextState) { return ( !shallowEqual(this.props, nextProps) || !shallowEqual(this.state, nextState) ); }, };Mixins 的缺点
鸿蒙官方战略合作共建——HarmonyOS技术社区
Mixins 引入了隐式的依赖关系。
例如，每个 mixin 依赖于其他的 mixin，那么修改其中一个就可能破坏另一个。
2. Mixins 会导致名称冲突
如果两个 mixin 中存在同名方法，就会抛出异常。另外，假设你引入了一个第三方的 mixin，该 mixin 上的方法和你组件的方法名发生冲突，你就不得不对方法进行重命名。
3. Mixins 会导致越来越复杂
mixin 开始的时候是简单的，但是随着时间的推移，容易变得越来越复杂。例如，一个组件需要一些状态来跟踪鼠标悬停，为了保持逻辑的可重用性，将 handleMouseEnter()、handleMouseLeave() 和 isHovering() 提取到 HoverMixin() 中。
然后其他人可能需要实现一个提示框，他们不想复制 HoverMixin() 的逻辑，于是他们创建了一个使用 HoverMixin 的 TooltipMixin，TooltipMixin 在它的 componentDidUpdate 中读取 HoverMixin() 提供的 isHovering() 来决定显示或隐藏提示框。
几个月之后，有人想将提示框的方向设置为可配置的。为了避免代码重复，他们将 getTooltipOptions() 方法增加到了 TooltipMixin 中。结果过了段时间，你需要再同一个组件中显示多个提示框，提示框不再是悬停时显示了，或者一些其他的功能，你需要解耦 HoverMixin() 和 TooltipMixin 。另外，如果很多组件使用了某个 mixin，mixin 中新增的功能都会被添加到所有组件中，事实上很多组件完全不需要这些新功能。
渐渐地，封装的边界被侵蚀了，由于很难更改或移除现有的mixin，它们变得越来越抽象，直到没有人理解它们是如何工作的。
React 官方认为在 React 代码库中，Mixin 是不必要的，也是有问题的。推荐开发者使用高阶组件来进行组件逻辑的复用。
2. HOC
React 官方文档对 HOC 进行了如下的定义：高阶组件（HOC）是 React 中用于复用组件逻辑的一种高级技巧。HOC 自身不是 React API 的一部分，它是一种基于 React 的组合特性而形成的设计模式。
简而言之，高阶组件就是一个函数，它接受一个组件为参数，返回一个新组件。
高阶组件的定义形如下面这样:
//接受一个组件 WrappedComponent 作为参数，返回一个新组件 Proxy function withXXX(WrappedComponent) { return class Proxy extends React.Component { render() { return } } } 开发项目时，当你发现不同的组件有相似的逻辑，或者发现自己在写重复代码的时候，这时候就需要考虑组件复用的问题了。
这里我以一个实际开发的例子来说明，近期各大APP都在适配暗黑模式，而暗黑模式下的背景色、字体颜色等等和正常模式肯定是不一样的。那么就需要监听暗黑模式开启关闭事件，每个UI组件都需要根据当前的模式来设置样式。
每个组件都去监听事件变化来 setState 肯定是不可能的，因为会造成多次渲染。
这里我们需要借助 context API 来做，我以新的 Context API 为例。如果使用老的 context API 实现该功能，需要使用发布订阅模式来做，最后利用 react-native / react-dom 提供的 unstable_batchedUpdates 来统一更新，避免多次渲染的问题（老的 context API 在值发生变化时，如果组件中 shouldComponentUpdate 返回了 false，那么它的子孙组件就不会重新渲染了）。
顺便多说一句，很多新的API出来的时候，不要急着在项目中使用，比如新的 Context API，如果你的 react 版本是 16.3.1， react-dom 版本是16.3.3，你会发现，当你的子组件是函数组件时，即是用 Context.Consumer 的形式时，你是能获取到 context 上的值，而你的组件是个类组件时，你根本拿不到 context 上的值。
同样的 React.forwardRef 在该版本食用时，某种情况下也有多次渲染的bug。都是血和泪的教训，不多说了，继续暗黑模式这个需求。
我的想法是将当前的模式(假设值为 light / dark)挂载到 context 上。其它组件直接从 context 上获取即可。不过我们知道的是，新版的 ContextAPI 函数组件和类组件，获取 context 的方法是不一致的。而且一个项目中有非常多的组件，每个组件都进行一次这样的操作，也是重复的工作量。于是，高阶组件就派上用场啦（PS：React16.8 版本中提供了 useContext 的 Hook，用起来很方便）
当然，这里我使用高阶组件还有一个原因，就是我们的项目中还包含老的 context API （不要问我为什么不直接重构下，牵扯的人员太多了，没法随便改），新老 context API 在一个项目中是可以共存的，不过我们不能在同一个组件中同时使用。所以如果一个组件中已经使用的旧的 context API，要想从新的 context API 上获取值，也需要使用高阶组件来处理它。
于是，我编写了一个 withColorTheme 的高阶组件的雏形(这里也可以认为 withColorTheme 是一个返回高阶组件的高阶函数)：
import ThemeContext from './context'; function withColorTheme(options={}) { return function(WrappedComponent) { return class ProxyComponent extends React.Component { static contextType = ThemeContext; render() { return (包装显示名称
上面这个雏形存在几个问题，首先，我们没有为 ProxyComponent 包装显示名称，因此，为其加上:
import ThemeContext from './context'; function withColorTheme(options={}) { return function(WrappedComponent) { class ProxyComponent extends React.Component { static contextType = ThemeContext; render() { return (我们来看一下，不包装显示名称和包装显示名称的区别:
React Developer Tools 中调试
ReactNative的红屏报错
复制静态方法
众所周知，使用 HOC 包装组件，需要复制静态方法，如果你的 HOC 仅仅是某几个组件使用，没有静态方法需要拷贝，或者需要拷贝的静态方法是确定的，那么你手动处理一下也可以。
因为 withColorTheme 这个高阶组件，最终是要提供给很多业务使用的，无法限制别人的组件写法，因此这里我们必须将其写得通用一些。
hoist-non-react-statics 这个依赖可以帮助我们自动拷贝非 React 的静态方法，这里有一点需要注意，它只会帮助你拷贝非 React 的静态方法，而非被包装组件的所有静态方法。我第一次使用这个依赖的时候，没有仔细看，以为是将 WrappedComponent 上所有的静态方法都拷贝到 ProxyComponent。然后就遇到了 XXX.propsTypes.style undefined is not an object 的红屏报错(ReactNative调试)。因为我没有手动拷贝 propTypes，错误的以为 hoist-non-react-statics 会帮我处理了。
hoist-non-react-statics 的源码非常短，有兴趣的话，可以看一下，我当前使用的 3.3.2 版本。
因此，诸如 childContextTypes、contextType、contextTypes、defaultProps、displayName、getDefaultProps、getDerivedStateFromError、getDerivedStateFromProps
mixins、propTypes、type 等不会被拷贝，其实也比较容易理解，因为 ProxyComponent 中可能也需要设置这些，不能简单去覆盖。
import ThemeContext from './context'; import hoistNonReactStatics from 'hoist-non-react-statics'; function withColorTheme(options={}) { return function(WrappedComponent) { class ProxyComponent extends React.Component { static contextType = ThemeContext; render() { return (现在似乎差不多了，不过呢，HOC 还有一个问题，就是 ref 传递的问题。如果不经过任何处理，我们通过 ref 拿到的是 ProxyComponent 的实例，而不是原本想要获取的 WrappedComponent 的实例。
ref 传递
虽然我们已经用无关的 props 进行了透传，但是 key 和 ref 不是普通的 prop，React 会对它进行特别处理。
所以这里我们需要对 ref 特别处理一下。如果你的 reac-dom 是 16.4.2 或者你的 react-native 版本是 0.59.9 以上，那么可以放心的使用 React.forwardRef 进行 ref 转发，这样使用起来也是最方便的。
使用 React.forwardRef 转发
import ThemeContext from './context'; import hoistNonReactStatics from 'hoist-non-react-statics'; function withColorTheme(options={}) { return function(WrappedComponent) { class ProxyComponent extends React.Component { static contextType = ThemeContext; render() { const { forwardRef, ...wrapperProps } = this.props; return 假设，我们对 TextInput 进行了装饰，如 export default withColorTheme({forwardRef: true})(TextInput)。
使用：
如果要获取 WrappedComponent 的实例，直接通过 this.textInput 即可，和未使用 withColorTheme 装饰前一样获取。
通过方法调用 getWrappedInstance
import ThemeContext from './context'; import hoistNonReactStatics from 'hoist-non-react-statics'; function withColorTheme(options={}) { return function(WrappedComponent) { class ProxyComponent extends React.Component { static contextType = ThemeContext; getWrappedInstance = () => { if (options.forwardRef) { return this.wrappedInstance; } } setWrappedInstance = (ref) => { this.wrappedInstance = ref; } render() { const { forwardRef, ...wrapperProps } = this.props; let props = { ...this.props }; if (options.forwardRef) { props.ref = this.setWrappedInstance; } return 同样的，我们对 TextInput 进行了装饰，如 export default withColorTheme({forwardRef: true})(TextInput)。
使用：
如果要获取 WrappedComponent 的实例，那么需要通过 this.textInput.getWrappedInstance() 获取被包装组件 TextInput 的实例。
最大化可组合
我先说一下，为什么我将它设计为下面这样：
function withColorTheme(options={}) { function(WrappedComponent) { } }而不是像这样：
function withColorTheme(WrappedComponent, options={}) { }主要是使用装饰器语法比较方便，而且很多业务中也使用了 react-redux：
@connect(mapStateToProps, mapDispatchToProps) @withColorTheme() export default class TextInput extends Component { render() {} }这样设计，可以不破坏原本的代码结构。否则的话，原本使用装饰器语法的业务改起来就有点麻烦。
回归到最大化可组合，看看官方文档怎么说：
像 connect(react-redux 提供) 函数返回的单参数 HOC 具有签名 Component => Component。输出类型与输入类型相同的函数很容易组合在一起。
// ... 你可以编写组合工具函数 // compose(f, g, h) 等同于 (...args) => f(g(h(...args))) const enhance = compose( // 这些都是单参数的 HOC withRouter, connect(commentSelector) ) const EnhancedComponent = enhance(WrappedComponent)
compose 的源码可以看下 redux 的实现，代码很短。
再复杂化一下就是:
withRouter(connect(commentSelector)(withColorTheme(options)(WrappedComponent)));
我们的 enhance 可以编写为:
const enhance = compose( withRouter, connect(commentSelector), withColorTheme(options) ) const EnhancedComponent = enhance(WrappedComponent)
如果我们是写成 XXX(WrappedComponent, options) 的形式的话，那么上面的代码将变成:
const EnhancedComponent = withRouter(connect(withColorTheme(WrappedComponent, options), commentSelector))
试想一下，如果还有更多的 HOC 要使用，这个代码会变成什么样子？
HOC的约定和注意事项
约定
将不相关的 props 传递给被包裹的组件(HOC应透传与自身无关的 props)
最大化可组合性
包装显示名称以便轻松调试
注意事项
不要在 render 方法中使用 HOC
React 的 diff 算法（称为协调）使用组件标识来确定它是应该更新现有子树还是将其丢弃并挂载新子树。 如果从 render 返回的组件与前一个渲染中的组件相同（===），则 React 通过将子树与新子树进行区分来递归更新子树。 如果它们不相等，则完全卸载前一个子树。
这不仅仅是性能问题 —— 重新挂载组件会导致该组件及其所有子组件的状态丢失。
如果在组件之外创建 HOC，这样一来组件只会创建一次。因此，每次 render 时都会是同一个组件。
务必复制静态方法
Refs 不会被传递(需要额外处理)
3. 反向继承
React 官方文档上有这样一段描述: HOC 不会修改传入的组件，也不会使用继承来复制其行为。相反，HOC 通过将组件包装在容器组件中来组成新组件。HOC 是纯函数，没有副作用。
因此呢，我觉得反向继承不是 React 推崇的方式，这里我们可以做一下了解，某些场景下也有可能会用到。
反向继承
function withColor(WrappedComponent) { class ProxyComponent extends WrappedComponent { //注意 ProxyComponent 会覆盖 WrappedComponent 的同名函数，包括 state 和 props render() { //React.cloneElement(super.render(), { style: { color:'red' }}) return super.render(); } } return ProxyComponent; }和上一节不同，反向继承不会增加组件的层级，并且也不会有静态属性拷贝和 refs 丢失的问题。可以利用它来做渲染劫持，不过我目前没有什么必须要使用反向继承的场景。
虽然它没有静态属性和 refs的问题，也不会增加层级，但是它也不是那么好用，会覆盖同名属性和方法这点就让人很无奈。另外虽然可以修改渲染结果，但是不好注入 props。
4. render props
首先， render props 是指一种在 React 组件之间使用一个值为函数的 prop 共享代码的简单技术。
具有 render prop 的组件接受一个函数，该函数返回一个 React 元素并调用它而不是实现自己的渲染逻辑。
