大型 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 大家庭