在Redux中使用getState是一种反模式

Is using getState in Redux an anti-pattern?

本文关键字：一种模式 Redux getState 更新时间：2023-09-26

我第一次在jQuery应用程序中使用Redux，并创建了小型可观察实现。可观察性响应状态对象的多个属性的更改，在状态本身更改时对DOM进行更改。如果我的可观察回调需要2个属性值来完成它的任务，我将观察这两个值，然后使用这些值来更新UI。可观察性根本不涉及状态。他们只是在回调中向可观察对象显示它，这样它就可以用来用状态更新UI。

我正在做的项目是一个重构，所以我在事后添加了Redux。有时，我意识到我在一段代码中需要一个特定的状态属性，而我可能没有时间将其正确地重构为可观察的。在这种情况下，我在商店里调用getState来获得我需要的东西并继续使用。我不禁觉得这种方法有点缺陷。

在我需要的地方使用store.getState是否被视为反模式？在使用store.getState时，我应该避免它们的明确用例吗？

如果过多地使用store.getState()，最终会将全局状态传递给随机组件。您面临着在组件和状态的部分之间引入耦合的风险，这些组件和部分彼此无关，这是反模式的。您应该只调用getState有两个原因：获取应用程序的初始状态，以及在商店的更新逻辑中，即在store.subscribe()回调中。

就您的可观察性而言，在React等典型的基于组件的视图层中，在redux应用程序中，您真正需要观察的是整个应用程序状态，而不是它的单个部分。对整个状态的更改是从顶级组件订阅并滴流下来的。

然而，由于您正在重构Jquery应用程序，我认为您对可观察性的使用是可以接受的。有一个名为reselect的库，如果你不想自己滚动，你可以使用它。它可以帮助您从全局状态的任意部分计算状态，并提供有效的记忆，这样就不会重新计算相同的输入。

有时，我意识到我在一段代码中需要一个特定的状态属性，而我可能没有时间将其正确地重构为可观察的。在这种情况下，我在商店里调用getState来获得我需要的东西并继续使用。我不禁觉得这种方法有点缺陷。

在这种情况下，您可以实现的一个简单的插入式解决方案是在减速器中使用事件发射器，将全局状态的片段传播到需要它们的特定Jquery组件。这将使您不必绕过全局状态，从而保持组件隔离。