logo标签列表

为什么在React中需要使用Redux？

javascriptreactjsredux
15

我已经使用ReactJS完成了一个小型Web应用程序。它很容易维护和理解。现在我学会了Redux并计划在其中实现。 需要一些额外的东西（例如创建store、Reducers等）。我个人认为，没有Redux也可以使用React来轻松理解和维护状态。那么为什么我们还需要额外的东西（Redux）呢？

5
Redux的创建者本人也同意你的看法，并写了一篇名为“你可能不需要Redux”的博客文章来解释原因。在React中使用Redux并非必需。在采用Redux之前，请确保它对你而言是有价值的，而不是带来痛苦。 - Ross Allen
1
只要您的应用程序变得越来越复杂，您就需要它。顺便说一下，您不需要在redux上控制所有组件状态，只需选择所需状态即可。 - jerry_p
7个回答
16

Redux的使用原因：

同一部分应用程序状态需要映射到多个容器组件中。

一个很好的例子是会话状态。当应用程序首次加载时，通常需要与标题栏和每个页面中的各种组件共享关于用户的信息。这些组件可能没有直接联系，因此Redux提供了一种方便的方式来共享状态。

全局强大的文本组件可在任何地方访问。

通常有一些组件是应用程序的生命周期（对于单页应用程序，这是每次重新加载入口点时）存在的，它们会执行一些操作，例如显示通知、snackbar、工具提示、模态框、交互式教程等。使用Redux，您可以创建动作以向这些组件发送命令，因此，例如，如果代码向后端发出异步请求并且请求失败，则可以分派一个显示snackbar的动作。 如果没有使用Redux，则需要其他事件系统或每次使用时都必须实例化snackbar组件。

通过多个层次的组件传递太多props。

如果一个高级组件提供了十几个props，但只使用了其中的两个，并将其余的传递给低级组件，则考虑使用Redux进行重构。这种情况在仅提供布局样式但不需要大量数据或配置的包装器组件中经常发生。在这种情况下，直接将Redux侧链到低级组件中更加实用。
使用setState进行状态管理会使组件变得臃肿，这有点主观。超过几百行代码的组件开始变得难以理解和维护。将状态管理分离成一个reducer可以分解代码并使其更易读。
缓存页面状态。当用户对页面进行了一些操作，然后转到另一页并返回时，通常期望页面保持相同的状态。保存页面状态并在页面加载时重新调用它可以解决其中一些问题。但是，搜索输入值和展开/收起手风琴等事情通常没有必要在后端存储。由于reducers通常初始化并在整个会话期间保持活动状态，因此它们可以缓存页面状态，以便事物保持不变。
4
管理状态可能很复杂。虽然React提供了state属性，但是当应用程序增长时，从组件A传递状态到组件B可能会非常复杂。这里有一个简单的例子，展示了为什么我们需要Redux。
考虑一个具有两个功能“用户”和“产品”的应用程序。enter image description here 用户已经实现了身份验证，他们可以注册和登录，并且只有在验证后才能查看仪表板。 另一个功能“产品”也需要用户身份验证信息，因为当用户通过验证/登录时，“购物车”操作将可访问。要在此部分获取用户身份验证信息，需要从“用户”组件传递大量状态/道具到应用程序的不同部分“产品”。 这就是Redux发挥作用的时候，它提供了一个中央存储（存储整个应用程序状态），然后可用于整个应用程序。
2
TL;DR: 因为你已经完成了“一个小型的Web应用程序”。并不是所有的Web应用程序都是小型的。
最简单的例子是，有时不相关的组件需要共享状态。有时状态需要被除组件以外的其他东西更新。
它总是必要的吗？绝对不是。但是，在非小型Web应用程序或复杂交互中，分解状态处理可能会带来优势。
如果您只有一些简单的组件层次结构，并且这个层次结构中很低的东西从未需要修改高级组件需要的状态，那么它会带来可能不必要的复杂性。
（即使在这些情况下，它也可能会有所帮助；像往常一样，“这取决于情况”。）
2
如果你在建造一座房子，即使你学会了使用它，你可能也不需要电锤。
如果你的应用程序状态易于管理，那么你不需要Redux。 （了解详情）
1
如redux动机页面中所述：
随着JavaScript单页应用程序需求变得越来越复杂，我们的代码必须管理比以往更多的状态。这些状态可以包括服务器响应和缓存数据，以及尚未持久化到服务器的本地创建数据。UI状态也越来越复杂，因为我们需要管理活动路由、选定标签、旋转器、分页控件等等。
管理这种不断变化的状态很难。如果一个模型可以更新另一个模型，那么一个视图就可以更新一个模型，然后更新另一个模型，这反过来可能会导致另一个视图更新。在某些时候，你已经失去了对应用程序发生的事情的理解，因为你已经失去了对其状态的何时、为什么和如何的控制。当系统是不透明和非确定性的时候，很难重现错误或添加新功能。
如果这还不够糟糕，考虑一下前端产品开发中越来越普遍的新要求。作为开发人员，我们需要处理乐观更新、服务器端渲染、在执行路由转换之前获取数据等等。我们发现自己试图管理一种我们以前从未处理过的复杂性，不可避免地会问一个问题：是时候放弃了吗？答案是否

但是有很多情况下你不需要使用redux，重要的是要理解它的作用以及为什么需要它。

1

在过去的几年里，我个人没有在任何项目中使用Redux。未来也不打算使用。原因如下：

2015年Redux出现时是一次革命性的事件。它为React带来了两个重要的概念：

  • 它将Flux的基于Action的模型与Reducer的概念相结合（这也体现在它的名称中："Red" "ux" = "Red"ucer + Fl"ux"）。这种Action-Reducer模式立即在React程序员中获得了广泛的认可。
  • 它解决了应用程序范围内的状态问题。假设我们有某些数据想要在整个应用程序中使用。在Redux之前，唯一可靠的方法是通过props将该数据传递给子组件...然后再传递给它们的子组件，以此类推。Redux改变了这一点。它允许数据片段超越应用程序的整个组件层次结构，而无需将数据从一个组件传递到另一个组件。它还提供了一种方便的方式来访问和操作应用程序状态。

Redux在底层使用了context API，但当时它只是为React内部使用而设计的，使用起来很麻烦。

快进到2019年，很多事情都发生了变化。我们现在有了hooks和稳定的公共context API，已经准备好投入使用了。通过useReducer hook，现在可以轻松地使用action-reducer模式。我们不再需要Redux了。

现代的React context API比以前更简单、更高效，并且支持hooks。在大多数情况下，将应用程序状态包装在上下文中就足以让你在应用程序的任何地方访问它。

那么Redux呢？

在我看来，在绝大多数情况下，您不再需要Redux。Contexts和hooks在大多数情况下都能胜任。如果您仍然认为contexts不太友好，可以看一下unstated-next库，它只是一个基于context API的薄包装器。整个库只有200字节！

但是，如果：

那么将Redux插入到您的项目中可能是有必要的。

在这种情况下，请确保您知道自己在做什么。Redux的魔力是有代价的。

Redux是一个复杂的东西。它会给您的应用程序带来很多复杂性。其中一些复杂性是显而易见的，而许多其他不明显的陷阱则是隐藏的并等待着你去发现。如果您想处理这个问题，请三思而后行。即使如此，也值得检查其他选择，例如MobX或react-sweet-state。

来源：您可能不需要redux

0

React 自带所有功能，可以处理您的状态，无需单独添加任何库。大多数应用程序状态都不应该是全局的，因为它们可以在组件旁边的 useState 或 useReducer 或自定义 hook 中很好地存活。

所以在你深入了解高级状态管理（例如 Redux）之前，请考虑使用 React 开箱即用的工具。

如果您有兴趣了解更多信息，我建议阅读 Andy Fernandez 的这篇文章：https://www.scalablepath.com/react/context-api-vs-redux

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接