[react] 为什么React并不推荐我们优先考虑使用Context？

[haizhilin2013]

[react] 为什么React并不推荐我们优先考虑使用Context？

[MagicalBridge]

1、Context目前还处于实验阶段，可能会在后面的发行版本中有很大的变化，事实上这种情况已经发生了，所以为了避免给今后升级带来大的影响和麻烦，不建议在app中使用context。
2、尽管不建议在app中使用context，但是独有组件而言，由于影响范围小于app，如果可以做到高内聚，不破坏组件树之间的依赖关系，可以考虑使用context
3、对于组件之间的数据通信或者状态管理，有效使用props或者state解决，然后再考虑使用第三方的成熟库进行解决，以上的方法都不是最佳的方案的时候，在考虑context。
4、context的更新需要通过setState()触发，但是这并不是很可靠的，Context支持跨组件的访问，但是如果中间的子组件通过一些方法不影响更新，比如 shouldComponentUpdate() 返回false 那么不能保证Context的更新一定可以使用Context的子组件，因此，Context的可靠性需要关注。

[idododu]

All consumers that are descendants of a Provider will re-render whenever the Provider’s value prop changes. The propagation from Provider to its descendant consumers (including .contextType and useContext) is not subject to the shouldComponentUpdate method, so the consumer is updated even when an ancestor component skips an update.

从Provider到下属consumer的数据传递不受shouldComponentUpdate方法的约束，因此，即使上层组件跳过更新，Consumer也会被更新。

[pomelovico]

事实上现在很多组件库都转而改用Context来实现状态管理的，比如Formik这种表单库，通过Context的方式实现解耦，更容易封装局部字段组件实现表单复用，第三方的库比如redux，remath，mobx等等，其实在触发更新的时候反而会造成许多不必要的render，尤其是面向函数组件使用的时候。

Context不一定要传value，我们可以在Context层做一个事件发布订阅器，通过value传递下去，子组件从context中取出订阅器订阅数据，这样甚至不需要Context去setState，同样能实现数据更新，而且能达到局部更新的效果

[wjrhyw]

一般情况下不推荐使用，如果某些情况下无法使用state和props解决问题，同时第三方的数据流管理工具也无法很好的满足需求，那么是可以使用context的；并且其实在react-redux中，会使用到一个Provider组件，这个组件就是一个被封装的组件，这个组件就是将状态从store中取出，然后将整个状态通过context的方式传递给子组件，子组件又通过connent来进行高阶包裹，来通过contextType来获取，store中的状态，所以其实在很多第三方库中都用了context封装

[tuihou123321]

1、Context目前还处于实验阶段，可能会在后面的发行版本中有很大的变化，事实上这种情况已经发生了，所以为了避免给今后升级带来大的影响和麻烦，不建议在app中使用context。
2、尽管不建议在app中使用context，但是独有组件而言，由于影响范围小于app，如果可以做到高内聚，不破坏组件树之间的依赖关系，可以考虑使用context
3、对于组件之间的数据通信或者状态管理，有效使用props或者state解决，然后再考虑使用第三方的成熟库进行解决，以上的方法都不是最佳的方案的时候，在考虑context。
4、context的更新需要通过setState()触发，但是这并不是很可靠的，Context支持跨组件的访问，但是如果中间的子组件通过一些方法不影响更新，比如 shouldComponentUpdate() 返回false 那么不能保证Context的更新一定可以使用Context的子组件，因此，Context的可靠性需要关注。

组件根据自身情况，在shouldCompoentUpdate返回了false,本来就是逻辑需求，不能算缺点呀