精读《How to safely use React context》

[BlackGanglion]

文章地址：https://medium.com/@mweststrate/how-to-safely-use-react-context-b7e343eff076

context 一直存在 React 中，官方却不建议大量使用，那么哪些场景需要使用 context，context 又会有哪些坑呢？让我们一起讨论一下

为了方便大家阅读，提供中文翻译地址：http://zhaozhiming.github.io/blog/2017/02/19/how-to-safely-use-react-context-zh-cn/

[DanielWLam]

好长耶。。。不过话说回来，用习惯了vue，一直觉得react很折腾，boilerplate就够折腾了，实际使用又有这么多坑，为什么react还能持续兴旺？

[BlackGanglion]

@DanielWLam 框架之争这里不过多展开，国内外社区已经有过无数讨论。无论是 react 还是 vue，它们背后都是需要一套生态系统进行支持的，比如：优秀的组件库、良好的数据流方案，开发迭代的脚手架与构建工具等等。我们团队在 react 上浸润多年，既有生态系统的完善，也有最佳实践的沉淀，已经能有效地支持业务。我并不太了解 vue，但应该 vue 相对 react 的一些优势并不足以打动我们去更换整套生态系统（对比一下 jquery 与 react，再对比一下 react 与 vue），而是让我们思考如何改进 react 的痛点，我想其他团队应该和我们有类似的想法。

扯得有点远哈，还是让我们回归精读话题吧，欢迎点评哦~~

[monkingxue]

这一期的主题比较简单，而且倾向性很明显（手动斜眼），啊喂是不是又要准备推广 dynamic-object 啊摔！
开个小玩笑，回归文章来看，这次主要探讨的是 react context 在 pureComponent 下的异常解决方案。简单来说就是，shouldComponentUpdate 返回的 false 会 block 住 context，让你第一次传入的值无法发生变化。而解决方案也比较简单，DI + observable，既然无法修改传入的 context，那直接让依赖 context 的组件注册在 context 上，利用 React 的生命周期监听 context 的改变，然后调用 subscription，满满的 Vue 既视感。

[alcat2008]

使用场景

在考虑什么场景下需要用到 Context 之前，先看看 Context 的作用是什么，能提供哪些支持。

官网上说的非常明白：

In some cases, you want to pass data through the component tree without having to pass the props down manually at every level.

说白了，就是 在组件树上提供一种跨层级通信的能力，可以理解成一种 另类的数据源。

想一想，这不就是 Redux 吗？Context 为 React 提供了一种全局 state 管理的方式，并且这种方式无需依赖任何第三方插件。

所以，在很多 React 库中，都采用了 Context 的方式来传递数据，以保持自身的独立性。

遇到的 “坑”

在使用 Context 中可能遇到的坑，文章中说的很清楚，以上几位也都做了补充。

这里只想谈谈为什么会出现这些 “坑”。个人观点：都是 多数据源 惹得祸。

shouldComponentUpdate(nextProps, nextState)

React 定义 shouldComponentUpdate 时并不会主动从 Context 中获取数据，这是合理的设置，因为它默认将全局 state 的管理职能托付于你，组件只考虑本身的 prop 或 state，这种 分治 的思想极大简化了 React 的实现及使用过程。

React 所推崇的 单向数据流 也是寄希望于类似 Redux 等方案来管理数据，而自己只想静静的渲染 view 而已。

所以，如果需要全局数据，并且有 state 管理方案，那么还是不要用 Context 了！

[monkingxue]

建议前端精读的范围在React之外可以更广一些哦，比如之前的tcma和动画系列就很棒，或者可以尝试一下Vue、工程化之类的？博采众长也是React社区的一个特点嘛

[ascoders]

Context 未来可能废弃？

就算 Context 被废弃了，也会有下一个 Context 站出来：基于 React.Component 封装一层，访问共享变量。这个功能是 DI 必备的，而且实现难度不高，问题是名字不好取，且容易被滥用。

就好比前端代码规范禁止挂全局变量扰乱程序稳定性一样，然而 mobx 必须这么做。这是因为多个 Mobx 实例必须共享一份 observable 对象才能保证不同 Mobx 实例注册的对象都可以被 autoRun，当然 Do 也是一样。

存在即合理，合理使用不被推荐的 api 可以提升开发效率与可维护性，包括 DI 也会借鉴这种思想（否则 umd 包为什么能同样 work？）。

最后，Context 在框架和库中很常见，业务代码中坚决抵制使用 Context。

[zhangdongming0607]

话说既然context会在pureComponent里出问题，那是讲道理用react-redux也会出问题？它里面也实现了一个类似的shallow compare？

[BlackGanglion]

@zhangdongming1989
react-redux 中方案和文中阐述的基本是一致的，redux store 有 subscribe 来监听 store 的变化，具体可以参考 react-redux 的源码：
https://github.com/reactjs/react-redux/blob/master/src/components/connectAdvanced.js#L154