4 张动图解释为何（何时）使用 Redux

dev-reading/fe 是一个阅读、导读、速读的 repo，不要依赖于 dev-reading/fe 学习知识。本 repo 只是一个快速了解文章内容的工具，并不提供全文解读和翻译。你能够经过本平台快速了解文章里面的内容，找到感兴趣的文章，而后去阅读全文。

本文讨论地址：https://github.com/dev-readin...

阅读时间大概 1 分钟

---

过早优化是万恶之源 —— Donald Knuth

本文描述了何时开始使用 Redux。做者描述了在构建一个真实 React APP 时，从没有使用 Redux 到使用 Redux 的过程以及收获。

首先，并非全部的 React 应用程序都须要使用 Redux。事实上，大多数很是简单的 React 应用程序根本不能从 Redux 中受益。

第 1 天

使用 React 本地组件状态

React 使用单向数据流，这意味着父组件把自身的状态做为属性传递给子组件。

第 5 天

随着添加更多的功能，非父子组件之间须要共享一些状态。

咱们经过提高状态来解决这个问题。

这意味着咱们将状态（和改变这个状态的函数）提高到最接近的祖先（Container Component）。咱们将这些函数绑定到容器组件，并将它们做为属性向下传递。这意味着子组件能够触发其父组件中的状态更改，这将更新树中的全部其余组件。

第 20 天

随着添加了更多的功能和组件，咱们的应用程序状态流程开始看起来像这样...

第 n 天

若是您开始遇到上述某些问题，则可能意味着您应该使用 Redux 了。

Redux

当咱们使用 Redux 后，状态变成了这样：

若是您的应用符合如下某些条件，那么我认为应该当即使用 Redux。

• UI 能够根据应用程序状态显着变化
• 并不老是以一种线性的，单向的方式流动
• 许多不相关的组件以相同的方式更新状态
• 状态树并不简单
• 状态以许多不一样的方式更新
• 您须要可以撤消之前的用户操做

---

阅读原文：When do I know I’m ready for Redux?

讨论地址：4 张动图解释为何（何时）使用 Redux #11

若是你想参与讨论，请点击这里