为什么我们需要redux反应

Question

我使用ReactJS完成了一个小型Web应用程序。易于维护和理解。现在，我学习了Redux并计划在其上实施。 它需要更多的东西和额外的工作（创建商店，Reducers等）。我个人认为，不用redux，反应很好，并且易于理解和维护状态。那为什么我们需要额外的东西（Redux）？

Answer 1

使用Redux的原因：

  

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

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

  

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

具有在应用程序的生命周期内有效的组件（对于单页应用程序，这是每次重新加载入口点时都存在）是很常见的，它们会执行诸如显示通知，小吃栏，工具提示，模式，交互式教程等操作使用Redux，您可以创建将命令调度到这些组件的操作，例如，如果代码向后端发出异步请求，则在请求失败时，它可以调度show快餐栏操作。如果没有Redux，您将需要其他事件系统，或者必须在每次使用小吃栏组件时实例化它。

  

过多的道具正在通过多个层次   组件。

如果上级组件提供了十二个道具，并且仅使用其中两个，其余的则传递给下级组件，则可以考虑使用Redux进行重构。包装组件只提供布局样式，而不需要大量数据或配置，这种情况经常发生。在这种情况下，将Redux直接侧链到较低级别的组件中更为实用。

  

使用setState进行状态管理会使组件膨胀。

这是非常主观的，但是超过几百行代码的组件开始变得难以推理和维护。将状态管理分离为简化器可以使代码分解并使代码更具可读性。

  

缓存页面状态。

当用户在页面上做一些事情，然后转到另一个页面并返回时，通常期望页面处于相同状态。通过将页面状态保存在后端并在页面加载时调用它，可以解决其中的一些问题。但是，诸如搜索输入值和扩展/折叠的手风琴之类的东西通常在后端存储时实在是太过分了。由于reducer通常会在整个会话中进行初始化和运行，因此它们可以缓存页面状态，从而保持不变。

Answer 2

管理状态可能很复杂。尽管react为我们提供了state属性，但是当应用程序增长时，将状态从组件A传递到组件B可能会非常复杂。这是一个简单的示例，显示了我们为什么需要redux。

请考虑具有“用户”和“产品”两个功能的应用程序。

用户已实现身份验证，可以在其中注册和登录，并且只有在通过身份验证后，用户才能查看仪表板。 其他功能“产品”也需要用户身份验证信息，因为在对用户进行身份验证/登录后，便可以访问“购物车”操作。要在此部分获得用户身份验证信息，将需要大量状态/属性，这些状态/属性将从“用户”组件传递到应用程序“产品”的其他部分。 这是Redux出现的时候，它提供了一个中央存储（存储整个应用程序状态），然后可供整个应用程序使用。

Answer 3

TL; DR：因为您已经完成了“一个小型Web应用程序”。并非所有的Web应用程序都很小。

为什么可能需要它的最简单的例子包括：

• 有时不相关的组件需要共享状态。
• 有时状态需要由组件以外的其他事物来更新。

是否总是有必要？绝对不。但是，中断状态处理可能会为非小型Web应用程序或复杂的交互提供优势。

如果您所拥有的只是一个简单的组件层次结构，而该层次结构中非常低的事物永远不需要修改高级组件所需的状态，那么它将带来不必要的复杂性。

（尽管即使在这种情况下，它也会有所帮助；一如既往，“取决于”。）

Answer 4

如redux motivation page中所述：

  

由于JavaScript单页应用程序的要求   变得越来越复杂，我们的代码必须管理比   以前。此状态可以包括服务器响应和缓存的数据，   以及尚未持久保存到本地的本地创建的数据   服务器。 UI状态的复杂性也在增加，因为我们需要   管理活动路线，选定的标签，微调器，分页控件，   等等。

     

管理这种不断变化的状态非常困难。模型是否可以更新   另一个模型，则视图可以更新一个模型，该模型可以更新另一个模型   模型，进而可能导致另一个视图更新。在一些   点，您将不再像以前那样了解应用程序中发生的情况   无法控制其状态的时间，原因和方式。当系统   是不透明且不确定的，很难重现错误或添加错误   新功能。

     

如果这还不够糟糕，请考虑将新要求变成   在前端产品开发中很常见。作为开发人员，我们   预期将处理乐观更新，服务器端渲染，获取   进行路线转换之前先输入数据，依此类推。我们发现自己   试图处理我们从未必须解决的复杂性   之前，我们不可避免地问一个问题：是时候放弃了吗？的   答案是否定的。

     

这种复杂性很难处理，因为我们要混合两个概念   人类的大脑很难推理：突变和   异步性。我称他们为Mentos和可乐。两者都可以很棒   分离，但它们一起造成混乱。像React这样的库   尝试通过同时删除视图层和视图层来解决此问题   异步和直接DOM操作。但是，管理状态   您的数据由您自己决定。这是Redux进入的地方。

     

按照Flux，CQRS和事件源，Redux的步骤进行操作   试图通过施加一定的影响使状态突变可预测   限制如何以及何时进行更新。这些限制反映在Redux的三项原则中。

但是在很多情况下，您不需要redux，了解它的作用以及为什么需要它很重要。

Answer 5

如果您要盖房子，即使您已经学会了如何使用它，也可能不需要手提凿岩机。

You don't need Redux，如果没有它，您的应用程序状态很容易管理。

Answer 6

在过去两年左右的时间里，我个人没有在任何项目中使用Redux。我也不希望将来使用它。这就是为什么。

Redux于2015年问世时是革命性的。它为React带来了两个重要想法：

• 它将Flux的基于动作的模型与Reducer的概念结合在一起（其名称为：“ Red” “ ux” = “ Red “ ucer + Fl ” ux“ ）。这种 Action-Reducer 模式立即在React程序员中引起关注。
• 它解决了应用范围内的状态。假设我们要在整个应用程序中提供某些数据。在Redux之前，唯一可靠的方法是将数据通过prop传递到子组件……然后再传递到其子组件，依此类推。 Redux改变了这一点。它允许数据片段超越应用程序的整个组件层次结构，而无需通过道具将数据从一个组件传递到另一个组件。它还提供了一种方便的方法，可以从应用程序中的任何位置访问和操纵该应用程序状态。

Redux在引擎盖下使用了context API，当时它只打算供React内部使用，而且使用起来很麻烦。

快进到2019年。发生了很多变化。现在，我们有了钩子和稳定的公共context API，可以在黄金时间使用。现在可以通过useReducer hook使用动作-减速器模式。我们不再需要Redux。

现代的React context API比以前更简单，更高效，并随附hooks support。在大多数情况下，只需wrapping your application state in a context即可在应用程序中的任何位置访问它。

那Redux呢？

我的观点是，在大多数情况下，您不再需要Redux。上下文和挂钩可以在大多数时间完成工作。如果您仍然认为上下文不是很友好，可以看看unstated-next库，它只是上下文API之上的一个薄包装。整个库只有200个字节！

但是，如果满足以下条件，则可以保证将Redux插入项目中：

• 您想利用Redux middlewares之类的redux-thunk
• 或者您喜欢Redux developer tools和他们的time-travelling ability。

在这种情况下，请确保您知道自己在做什么。 Redux魔术附带价格。

Redux是复杂的野兽。这将给您的应用带来很多复杂性。其中一些复杂性是obvious，而其他许多显而易见的陷阱则是hidden and waiting for you to trip on it。如果您想解决这个问题，请三思。即便如此，还是值得检查诸如MobX或react-sweet-state之类的替代方案。

来源：You may not need redux