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

React新的ContextAPI在前端状态管理中的实践应用繁琐难管理。通常我们需要使用Redux来帮助我们进行管理。不过，随着React16.3的发布，新的contextapi成为了新的选择。一、Redux简介及缺陷Redux来源于Flux，借鉴了Elm的思想。主要原理如下图所示：可以看到，Redux的数据流其实很简单。外部事件通过actionCreator函数调用dipsatch向reducer发布action。然后各个reducer根据action类型（action.type）按需更新整个应用的状态。redux的设计有以下几个要点：1.state是单例模式，不可变。单例模式避免了不同商店之间数据交换的复杂性，不可变的数据提供了非常快速的撤销和重做，“时间旅行”等功能。2.state只能通过reducer更新，不能直接修改3.reducer必须是纯函数，比如(state,action)=>newStateredux本身就是一个很纯的状态管理库，需要借助react-redux库来管理反应的状态。react-redux主要由两部分组成。1、Provider组件：Store可以注入到子组件的cotext中，所以一般放在应用程序的顶部。2.connect函数：返回一个高层函数，将context中Provider注入的store取出来，通过props传给子组件，让子组件成功获取store。虽然redux在React项目中得到了广泛的认可和使用，但是redux在实际项目中仍然存在很多不足：1.样板代码过多：添加一个action往往需要同时定义对应的actionType，然后编写N个相关reducer。比如在添加异步加载事件时，需要同时定义加载、加载失败、加载完成三种actionType，并需要相应的reducer通过switch分支处理相应的actionType，有冗余代码太多。2、更新效率问题：由于采用了不可变数据模式，每次更新状态都需要复制一份完整的状态，造成内存浪费和性能损失。3、数据传递效率问题：由于react-redux采用的contextAPI是老版本，context的传递存在效率问题。其中，第一个问题目前有很多解决方案，比如dva、rematch、mirror等，笔者也搭建了类似的wheelrestated，这里不再赘述。第二个问题，redux和react-redux做了非常详细的优化。其次，使用shouldComponentUpdate方法也可以避免很多不必要的更新。最后还可以使用一些不可变的数据结构如immutable、Immr等，从根本上解决copy开销问题。第三个问题属于React自身API的限制。从第三方库的角度来看，能做的很有限。2.ContextAPIContextAPI主要用于解决跨组件参数泛洪（propdrilling）问题。旧的contextAPI语法如下：//Deliverer，生成数据放入contextclassDeliverComponentextendsComponent{getChildContext(){return{color:"purple"};render(){return}}DeliverComponent.childContextTypes={color:PropTypes.string};//与上下文无关的中间组件constMidComponent=(props)=>;//receiver需要使用context中的数据constReceiverComponent=(props,context)=>你好，这里是receiver。