redux、vuex状态管理，state是否应该尽量放在store中？

Question

redux

之前写react比较多，习惯将state都放在store中。不管container组件还是UI组件，基本上都没有自己的state。UI组件纯渲染，container组件通过mapStateToProps和mapDispatchToProps控制输入。似乎也是redux的三大原则之一：

整个应用的 state 被储存在一棵 object tree 中，并且这个 object tree 只存在于唯一一个 store 中。

个人感觉：

1. store有点太庞大了（其实这也没啥问题）
2. 有点麻烦，container组件的state太多（或者说80%+都是私有状态），每次都要到reducers中写一把，然后再到container组件中通过mapStateToProps导入props

const reducers = combineReducers({
    a,
    b,
    c,
})

const mapStateToProps = state => ({
    myC: state.c,
});

vuex

最近在看vuex，似乎vuex中只规定应用层级的状态需要放在store中，并说明组件可以拥有自己的state。
但是这样的话，组件数据流似乎又比较难控制，比如this.$emit直接调用父组件的回调。

不知道我有没有理解错的地方？大家是如何看待store.state和组件私有状态的？

Answer 1

这个问题, redux 的文档里也有提到.

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

没有 “标准”。有些用户选择将所有数据都在 Redux 中维护，那么在任何时刻，应用都是完全有序及可控的。也有人将类似于“下拉菜单是否打开”的非关键或者 UI 状态，在组件内部维护。适合自己的才是最好的。

使用局部组件状态是更好的。作为一名开发者，应该决定使用何种 state 来组装你的应用，每个 state 的生存范围 是什么。在两者之间做好平衡，然后就去做吧。

这里有一些将怎样的数据放入 Redux 的经验法则：

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

http://cn.redux.js.org/docs/f...

我 redux 是只存需要全局共享, 需要持久化的状态.
其他的都让组件自己内部维护.

Answer 2

就我的使用经历而言，将state分成两种，需要共享的和组件私有的。前者放到store中，后者不用。

后者需要特别说明一下，是仅对组件本身起作用，不影响其他组件的state。

当然，我觉得这仅仅是个度的问题，将全部state放到store中统一管理自然是很好，但是对于开发就不太友好了。而且将一些私有的state也放到store中，带来的收益几乎没有，却对开发效率有很大影响。

Answer 3

我个人使用vue、react，都是将共享状态存入store，组件内部状态放到组件内部state中，这样开发效率更高，结构也更清晰。

Answer 4

嗯,共享状态就放在 vuex 中,不是共享的就不要全局,放在自己单独的组件中就好了!

Answer 5

封装组件时它的大部分状态肯定是自己管理的