4 张动图解释为什么(什么时候)使用 Redux

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

本文讨论地址:github.com/dev-reading…

阅读时间大概 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

如果你想参与讨论,请点击这里

关注下面的标签,发现更多相似文章
评论
说说你的看法