你可能并不需要 redux

人们常常在真正需要用到 redux 之前就选择了它。 “如果我们的应用没有使用 redux，变得不好扩展怎么办？” 后来，开发者们又都皱着眉头指头他们的代码间接地评论 redux.“为什么实现一个小功能需要更改三个文件？” 为什么一定要用 redux 呢!

大家痛苦地指责 redux, react, 函数式编程、 不变性等这些东西，我能理解他们。我们很自然地会拿 redux 和不需要‘按模板’来更新 state 的实现方式进行比较，并得出 redux 只会让事情变复杂的结论。某种程度上看，redux 是被设计成这样的。

redux 做了一个权衡，它要求你：

• 将应用的状态抽象成简单对象或数组。
• 将系统的变化抽象成简单对象。
• 将处理逻辑抽象成纯函数。

不管是不是应用在 react 应用程序上，这些限制都是必需的。事实上，这些都是很严格的约束。就算只是在你应用程序的一部分中使用，也应该认真考虑它。

有人会问，你有充分的理由解释为什么要做这些限制吗？

这些限制对我很有吸引力，因为它们让我的应用拥有以下优点：

• 将 state 存储在本地，并用它启动，开箱即用
• 在服务端预渲染 state，并随 html 发送到客户端，从它启动，开箱即用
• 序列化用户交互并触发它，以及进行状态快照，自动 bugs 上报，以便让开发者重现 errors
• 通过网络传递 action 对象，而不会对写代码的方式产生大的影响
• 保持重做历史和实现可预测的变化，而不会对写法产生剧大的影响
• 开发环境中可以随意穿梭在历史的各个状态中，并在代码更改时根据交互历史重新计算当前状态，一种 TDD 驱动
• 为开发工具提供全面的检测和控制能力，以便产品开发者为他们的 app 构建自定义开发工具
• 当复用大部分业务逻辑的同时，也提供备用 UI

如果你正在开发可扩展的 terminal, javascript 调试器, 或某些类型的 webapp, redux 可能很值得一试，或者至少借鉴它的一些思想（顺便提一下，这些并不是 新事物）。

但是，如果你只是在学习 react, 那么不要把 redux 当成你的首选。

相反，学会 思考 react, 如果你发现你真的需要它，或者你想尝试一些新东西，那就重新考虑 redux 吧。但是一定要谨慎对待它，就像对待固执已见的工具一样。

如果你对 redux 的方式感到压力。这是一个信号，可能你的队友太认真了。 它只是你工具箱里的一个工具，一个疯狂 的实验。

最后，不要忘记，你可以不用 redux,而实现 redux 的思想。

举个例子，考虑一个带有 local state 的 react 组件:

看上去很好。严格地说，它没有达到高度复用。

但是，这样使用 Local state 就很好。

权衡之下，redux 提供解耦，将“发生了什么交互”与“数据如何改变”解耦。

举个例子，可以从我们的组件中提取出一个 reducer:

注意，我们没有运行 npm install 却应用了 redux ! 哇哦！

你的状态组件是否也需要这样写呢？可能不需要。除非你有计划地从这种解耦方式中获益。有计划是我们的一种说法，这是关键。

redux 库本身只是“安装” reducer 和单个全局 store 对象的工具集。你可以只使用部分或者全部功能，这取决于你。

但，如果你付出了什么，一定要确保你有所收获。