是否有必要把所有的state放redux管理？

Question

相信大家都有这个疑问，所有的state都放redux里面管理吗？

官方给出redux解决的问题有两个：1、复杂组件之间的传值问题。2、数据缓存能实现回溯操作（时间旅行）。

1、reudcer的问题：那这里就存在一个问题，如果state既没有进行组件传值，业务上又没进行回溯，那把state加到redux进行管理，如果是异步数据，那么还要在高阶函数中跑一圈，缓存到内存，也要单独建立一个reducer,假如一个应用这种独立的state有几百个，那么就要对应几百个reducer,redux给每个reducer取了个别名，通过switch来遍历别名进行管理，那么多则要做几百次case操作，那么用redux管理是不是很没有必要？

2、state数据缓存问题：虽然回溯操作很方便，也存在一个问题，如果服务器返回的数据比较多，进行缓存是不是对内存的开销比较大？回溯的带来的方便的代价就是内存的开销。我们该如何取舍？

基于这两个问题，希望各位大神畅谈下自己的方案，或者见解。

Answer 1

知乎关于这个问题的讨论，看没人回答，就扯几句，就我个人的经验来看并不是state都需要交给redux，尤其是在不复杂的组件及应用中，把state都放到redux只是种累赘，具体的最佳实践个人也在摸索中，建议多看写github上的例子。阿里有个关于redux最佳实践的东西，react redux最佳实践可以参考下！

Answer 2

没有，有的state仅仅是局部的。就没有必要。只放置需要与外部组件通信的component的state在store中。

Answer 3

redux改变的是思考问题的方式。 数据改变 + 视图更新 二者分开，能做的很好，但混到一起，就变得一团糟。 redux保证数据流向的正确， 组件只考虑一件事，就一件事，接受props然后展示。 redux 也完全只用关心数据的正确性，由于不考虑组件， 数据层可以写测试用例来保证。 而且 应用随着应用的不断增大，reducer可以复用的逻辑一般也越来越多。 开发的时候也方便，大家提前定义好store的结构。 推荐看一个框架deku, 一个没有state的框架