共享的数据

前面提到应用的数据类型有三种：领域数据，应用状态，UI状态。

其中，UI状态看上去更多是存放在React组件里面。

那是不是领域数据和应用状态都应该归Redux管理呢？不一定，为什么呢？我是从这角度思考的：

Redux本身存储的是一个全局数据，即被共享的数据。那么，我们就会问，不会被共享的数据应该存在哪呢？

存储在Redux里面

首先，你当然仍然可以存储在Redux里面，那么当前情况会是，数据被存放在Redux state树形结构的某一片区域中，被某一个路由下的某一个组件所使用。你一定会问，这样做有什么好处？

1.单一的数据源，你很放心的将数据存在那里，打开Redux Debug Tool就能看到（心里长叹一口气，数据还在还在）

2.将同类型（比如：领域数据）的数据统一类聚在一起，方便你统一管理，让你拥有绝对的上帝视角

3.某一天，设计师说，在一个离原组件很遥远的位置加一个按钮，当点击时，要改变这个数据，此时你可以很轻松的发送一个action并写一个reducer的case操作它，就完成了（数据操作和组件的关系是低耦合的）

等等其他我没有想到的好处

存储在Component里面

如果我不存放在Redux中，应该放哪里？可以是组件里面。那么同样的问题，放在组件里面有什么好处？

1.Redux中存放的都是被共享的数据，相比存放所有的数据，redux的state结构会小一些

2.组件的数据和状态是自管理的，无论你把我放在哪，我都能坚强的活着

3.某一天，我被页面的多个位置用到，你不需要在Redux里面配多个数据空间和action以供我的分身使用，我自带装备，我为自己“带盐”

4.我还能配合高阶组件（用高阶函数做数据加载部分），让你的代码看上更加装逼

等等其他我没有想到的好处

如果博客里面可以发表情，此时我特别想发一个拍脑袋的表情，请问，看完这一段，我胡乱分析的结果，是不是感觉有些不知所措？我到底应该放在哪呢？

官文FAQ的经验法则

正如官方文档里面FAQ的结果

问：必须将所有state都维护在Redux中吗？ 可以用React的setState()方法吗？

答：没有 “标准”。作为一名开发者，应该决定使用何种 state 来组装你的应用，每个 state 的生存范围是什么。在两者之间做好平衡，然后就去做吧。

所以说，看情况（It depends）永远是正确的答案。

当然官方文档也给了一些将怎样的数据放入Redux的经验法则：

1.应用的其他部分是否关心这个数据？
2.是否需要根据需要在原始数据的基础上创建衍生数据？
3.相同的数据是否被用作驱动多个组件？
4.能否将状态恢复到特定时间点（在时光旅行调试的时候）？
5.是否要缓存数据（比如：数据存在的情况下直接去使用它而不是重复去请求他）？

我个人感觉这些经验法则是有些道理的，和我们前面讲解和分析的套路差不多，可以作为参考。

总结

首先，我个人认为一定不是将所有的数据都放在Redux里面，但是至于什么样的数据该放在哪里，那就需要看是什么样的使用场景？你需要询问自己几个问题（如上面说问），分析它的好处和坏处，是否满足你的需求，然后做出判断。

我们下一节，来看redux state的组织结构（shape），以及action，reducer如何配合state的更新。