这个问题其实在我的 TODO 文章里。。但是最近应该都没什么时间，就像 浅入 React16/fiber - Part 1 前期准备 里讲的，所以这里简（瞎）要（比）回答一下，仅代表个人观点！！！
先说结论：redux 未来不会发生变化（dan 早已转让也不怎么管 redux repo，而 mark 我感觉要改他也不会改 redux 本身），也没有什么致命缺陷（portal 的 store 坑在 16 也不存在了，这里说的致命缺陷我理解的比较偏激，同理我会说 jq 没有致命缺陷，因为时代和背景不同）。但基于 redux 的封装，以及数据管理本身会发生变化（react internal, rxjs, apollo, ......）。mobx, immer 这类不敢评价，因为 not a fan of them:
个人认为，原生的 redux 和浏览器 api 一样，在真实项目中，不适合直接使用，所在在讨论问题的时候，更倾向于，「封装后的 redux」还存在哪些问题。为什么不内置这种封装呢？因为，项目不同，以及不同人的看法不同。不可能内置。
目前的封装，我认为基本的思路都是，约定一些东西，来减少模板代码，提升开发效率。比如，约定 type 和 reducer 的 key 一致，约定 action 返回 promise 的处理方式，约定 action 中包含某个 key 改怎么处理（即引入处理这个 key 的中间件），约定 promise action 都以 REQUEST, FULFILLED, REJECTED 结尾，再比如，约定 action, reducer, selector, const 都在同一文件中（需要注意循环引用）。
这是一种非常常见的封装方式，即约定大于配置，能提升开发效率吗？能，而且不少。
那么，这样的封装存在什么问题呢？我认为没有什么问题（因为并没有什么错）。但是，封装得还不够。我们可以想想，在各种封装之后，我们用的时候还有什么问题?
所以，对于前两个问题，个人认为，值得探索的封装方式有两个方面：
最后，新的封装还没有做好（忙毕设，没有办法。。再给我几个月！），做好再和大家分（吹）享（比）
先说结论：redux 未来不会发生变化（dan 早已转让也不怎么管 redux repo，而 mark 我感觉要改他也不会改 redux 本身），也没有什么致命缺陷（portal 的 store 坑在 16 也不存在了，这里说的致命缺陷我理解的比较偏激，同理我会说 jq 没有致命缺陷，因为时代和背景不同）。但基于 redux 的封装，以及数据管理本身会发生变化（react internal, rxjs, apollo, ......）。mobx, immer 这类不敢评价，因为 not a fan of them:
个人认为，原生的 redux 和浏览器 api 一样，在真实项目中，不适合直接使用，所在在讨论问题的时候，更倾向于，「封装后的 redux」还存在哪些问题。为什么不内置这种封装呢？因为，项目不同，以及不同人的看法不同。不可能内置。
目前的封装，我认为基本的思路都是，约定一些东西，来减少模板代码，提升开发效率。比如，约定 type 和 reducer 的 key 一致，约定 action 返回 promise 的处理方式，约定 action 中包含某个 key 改怎么处理（即引入处理这个 key 的中间件），约定 promise action 都以 REQUEST, FULFILLED, REJECTED 结尾，再比如，约定 action, reducer, selector, const 都在同一文件中（需要注意循环引用）。
这是一种非常常见的封装方式，即约定大于配置，能提升开发效率吗？能，而且不少。
那么，这样的封装存在什么问题呢？我认为没有什么问题（因为并没有什么错）。但是，封装得还不够。我们可以想想，在各种封装之后，我们用的时候还有什么问题?
- 简单而繁琐。简单在于，copy paste 贼快，而且基本不会出问题。繁琐在于，时不时如果要自己写，容易被搞晕，特别是在你用了一大堆中间件（redux-thunk, redux-actions, redux-promise-middleware, reduce-reducers(好像是叫这个..)，再加上自己的 middleware）之后，不出意外，应该是需要清醒的整理下流程做好笔记，前期时不时拿出来看的。模板代码还是太多（是的，懒是行业进步的巨大动力，虽然我觉得模板代码挺好。。（这个问题可以单独开一篇讲了））性能：其实我觉得基本是不太可能由
redux 产生性能问题的（也可能我写得少，还没遇到过），除非你用得不对。。（特别是在今年底 async render 开放后，概率更小）。但是这点是大家讨论比较多的，主要有两个地方： ---- 一是 redux 的发布订阅很无脑，依次调用所有 listener。大家觉得，在 dispatch 的时候我就知道只有 a, b, c 三个 listener 需要调用，为啥要都调一遍，那我 listener 上百个性能得多低啊。
---- 二是明明我就需要 foo, bar，还非得从 global 里面去 select，特别是在范式化之后，还要手动聚合，关键这些 selector 或者说 mapStateToProps 是每个 listener 都有的基本，完了之后还要 shallow equal check，性能太低了（虽然有 reselect, re-reselect 这些库）。 ---- 其实我觉得，更多的人只是对这样的模式感觉烦，至于是否真的是它们造成了性能瓶颈，或者对性能的影响有多大，很少会看到相关的数据来支持（虽然理论上说得通）。我记得在最初看徐飞叔叔的文章的时候也思考过这些问题，但是后面实践的时候我发现，在
redux 的模式下，这种指哪打哪的效果并不好做，我记得的是当时分析后的结论是做不了，原因我忘了。。好像是当时想的是，不就是监听 action 对引起 state 变化的 listener 做依赖分析就行了嘛，然后发现最多只能使 reducer 不用从顶层开始，而是精细化通知，而 listener 还是没法做，不确定性太大
所以，对于前两个问题，个人认为，值得探索的封装方式有两个方面：
- 一是静态分析处理。既然约定大于配置，那么约定可不可以尽量静态实现？举个例子（主要是说明问题，不是真要这么干），注意是例子，只是例子！！！只是瞎写的例子！！！
- 二是审视 redux 的定位。意思是，区分和思考 state, new context api, .... 等各种的场景。如果 redux 对标 database，那么还有什么？索引，读写分离，主从分离，indexdb，复杂的放到 worker？（其实后面两点都行不通，我只是说说，当然也可能我错了，前面几点我也只是说说，我并不太懂后端，主要是想表达有这么一个方向而已）
最后，新的封装还没有做好（忙毕设，没有办法。。再给我几个月！），做好再和大家分（吹）享（比）
