React新Context API在前端状态管理的实践，web编程开发学习

最新推荐文章于 2024-08-12 20:58:49 发布

2401_84098018

最新推荐文章于 2024-08-12 20:58:49 发布

阅读量655

点赞数 21

分类专栏：程序员文章标签：前端 react.js 学习

本文链接：https://blog.csdn.net/2401_84098018/article/details/137370860

版权

程序员专栏收录该内容

144 篇文章 0 订阅

订阅专栏

context API主要用来解决跨组件传参泛滥的问题（prop drilling)，旧的context API的语法形式如下：

React新Context API在前端状态管理的实践

可以看到，使用context api可以把DeliverComponent中的参数color直接跨越MidComponent传递到ReceiverComponent中，不需要冗余的使用props参数传递，特别是ReceiverComponent层级特别深的时候，使用context api能够很大程度上节省重复代码避免bug。

旧Context API的缺陷

======================================================================================

旧的context api主要存在如下的缺陷：

==============================================================================================

1.代码冗余：提供context的组件要定义childContextTypes与getChildContext才能把context传下去。同时接收context的也要先定义contextTypes才能正确拿到数据。

2.传递效率：虽然功能上context可以跨层级传递，但是本质上context也是同props一样一层一层的往下传递的，当层级过深的时候还是会出现效率问题。

3.shouldComponentUpdate：由于context的传递也是一层一层传递，因此它也会受到shouldComponent的阻断。换句话说，当传递组件的context变化时，如果其下面某一个中间组件的shouldComponentUpdate方法返回false，那么之后的接收组件将不会受到任何context变化。

为了解决旧版本的shouldComponentUpdate问题，保证所有的组件都能收到store的变化，react-redux只能传递一个getState方法给各个组件用于获取最新的state（直接传递state可能会被阻断，后面的组件将接收不到state的变化），然后每个connect组件都需要直接或间接监听state的变化，当state发生改变时，通过内部notifyNestedSubs方法从上往下依次触发各个子组件通过getState方法获取最新的state更新视图。这种方式效率较低而且比较hack。

三、新Context API

React自16.3开始提供了一个新的context api，彻底解决了旧Context API存在的种种问题。

下面是新context api（右）与使用旧context api的react-redux（左）数据流的比较：

React新Context API在前端状态管理的实践

可以看到，新的context api可以直接将context数据传递到传递到子组件中而不需要像旧context api那样级联传递。因此也可以突破shouldComponentUpdate的限制。新版的context api的定义如下：

React新Context API在前端状态管理的实践

下面是一个比较简单的应用示例：

React新Context API在前端状态管理的实践

可以看到新的context api主要包含一个Provider和Consumer对，在Provider输入的数据可以在Consumer中获得。新context api的要点如下：

1. Provider和 Consumer必须来自同一次 React.createContext调用。也就是说 NameContext.Provider和 AgeContext.Consumer是无法搭配使用的。

2. React.createContext方法接收一个默认值作为参数。当 Consumer外层没有对应的 Provider时就会使用该默认值。

3. Provider 组件的 valueprop 值发生变更时，其内部组件树中对应的 Consumer组件会接收到新值并重新执行 children函数。此过程不受 shouldComponentUpdete 方法的影响。

4. Provider组件利用 Object.is 检测 value prop 的值是否有更新。注意 Object.is和 === 的行为不完全相同。

5. Consumer组件接收一个函数作为 children prop 并利用该函数的返回值生成组件树的模式被称为 Render Props 模式。

四、新Context API的应用

========================================================================================

新的Context API大大简化了react状态传递的问题，也出现了一些基于它的状态管理库，诸如：unstated、react-waterfall等等。下面我们主要尝试使用新context api来造一个react-redux的轮子。

1. Provider

由于新的context api传递过程中不会被shouldComponentUpdate阻断，所以我们只需要在Provider里面监听store变化即可：

React新Context API在前端状态管理的实践

2. connect

相比较于react-redux，connect中的高阶组件逻辑就简单的多，不需要监听store变化，直接获得Provider传入的state然后再传递给子组件即可：

React新Context API在前端状态管理的实践

好了，至此整个React-redux的接口和功能都已经基本cover了，下面继续介绍一些比较重要的性能优化。

3. 性能优化 - 减少重复渲染

性能优化最大的一部分就是要减少无意义的重复渲染，当WrappedComponent的参数值没有变化时我们应该阻止其重新渲染。可以通过手写shouldComponentUpdate方法实现，也可以直接通过PureComponent组件来达到我们的目标：

React新Context API在前端状态管理的实践

这里需要注意的是，本示例的mapDispatchToProps未支持ownProps参数，因此可以把它的返回值看成是不变的，否则每次调用它返回的action函数都是新创建的，从而导致Prevent接收到的参数始终是不同的，达不到预期效果。更为复杂的情况请参考react-redux源码中selector相关的部分。

4. 性能优化 - 减少层级嵌套

性能优化另一个要点就是减少组件的层级嵌套，新context api在获取context值的时候需要嵌套一层Consumer组件，这也是其比旧context api劣势的地方。除此之外，我们应该尽量减少层级的嵌套。因此在前一个性能优化中我们不应该再次嵌套一个PureComponent，取而代之的是，我们可以直接在Cunsumer中实现一个memory机制，实现代码如下：

React新Context API在前端状态管理的实践