大型 React 项目的所有数据源都需要用 Redux 管理吗

这叫 redux 原教旨主义, 有一些对于组件的 local state 就存组件内部吧, 比如 active tab 一类的. 全丢 redux 也有好处, 就去 redux 找就行了. 但是会导致组件没了 redux 就凉了, 不能灵活切换其他方案.

开发界始终在做的一件事就是强调“隐藏”的重要性。我内部的数据我自己管理，你不该知道的别知道。

同意 @swirling 的说法，这叫 redux 原教旨主义，为了用它而用它，你说这不是欠吗。

redux 简直反人类，看看 mobx 吧，已经切换到 mobx，爽的一 B

@swirling
@song4 也就是多个组件共享的数据由 Redux 管理，其它的还是组件自己管理？

用人能管理的数据，就别依赖其他库
Redux 的逻辑 + 组件逻辑 + 业务逻辑，看起来比较头疼

鲁迅曾经说过：
“如果你不知道是否需要 Redux，那就是不需要它。”

@respect11 鲁迅还行。。

react 的数据更新逻辑太 2b，所以有来了个 redux，结果代码越来越乱

mobx + 1

@respect11 鲁迅说 我没说过这句话 别找我背锅

优先考虑放组件内部 然后设计到共享数据 提升层级 直接提到 redux store

是的

『如果你不知道你是否需要 Redux，那你就别使用它。』

Redux 的特点是写起来麻烦，调试起来很方便

Redux 管理“多个组件内共用的数据”这个论断绝对正确，但有一点需要注意，就是这个“多个组件”事实上不是“组件类型”，而是“组件实例”，如果一个组件的多次 mount （离开这个页面了，又回来了）也需要共享这个数据，那他也得在 redux 里

其它情况，我绝对推荐 local state 的应用

使用 redux 之后会有增加人手的需求 ，团队大了就可以做“复杂”的应用了，。

感觉最适合 redux 的是网页版 photoshop 这种工具型 web app，，，
假如只是简单树状结构页面（即便项目很大）纯 react 加一些 HOC 就够了。

个人很 naive 的理解，如果一个东西的状态多到必须用 redux 这种专门的框架解决状态管理问题，在设计、体验上肯定有挑的出来的问题
state 多在以前可以通过划分页面、向导、简化需求解决，另外页面多、功能多不代表复杂，若干个小模块互不交集只能是大
我们的一个 web 应用还在用事件
我的观点，状态机在大学的时候就是考点里的难点，这东西学起来就不易，想写出好的状态更是要功底

欢迎来 angular 大家庭

mobx+1 爽的不行不行的

复杂点还可以用 mobx state tree 确实比 redux 好用很多

。。。。其实最反人类是 flux

我觉得可以用…我是用了

理论上来说是全部都要由 redux 管理的 (elm
但是为了方便 有些组件的 内部 状态可以扔在 state 里面 也就是把组件本身看做是原子的

都可以。决定了一直贯彻就好。local state 也用 redux 的好处是调试方便，用了 dev tools 可以方便的查看状态和数据。

建议 mobx 或者严格一些的 mobx-state-tree

mobx 爽的不要不要的

刚开始我也是很尊重 redux 的一个中心 state 的原则。后来感觉真的麻烦且看不出必要性。然后就去他妈的怎么方便怎么来。

mobx +1
redux 没看懂

mobx + 1

redux 真好用。源码也没多少。函数式爽到。

store 就像一棵果树，不同枝干上面有不同的水果，想吃苹果就去摘苹果，想吃香蕉就摘香蕉。