在 Redux 中使用 getState 是一种反模式吗? [英] Is using getState in Redux an anti-pattern?

问题描述

我第一次在 jQuery 应用程序中使用 Redux，我已经创建了小的可观察实现.可观察对象响应状态对象的多个属性的变化，在状态本身发生变化时对 DOM 进行更改.如果我的可观察回调需要 2 个属性值来完成其任务，我将观察这两个值，然后使用这些值来更新 UI.可观察对象根本不接触状态.他们只是在回调中将其呈现给 observable，以便它可以用于使用状态更新 UI.

I'm using Redux for the first time in a jQuery application and I have created small observable implementation. The observables are responding to changes on multiple properties of the state object, making changes to the DOM when state itself changes. If my observable callback needs 2 property values to accomplish its task, I will observe both values and then use those values to update the UI. The observables don't touch the state at all. They just present it to the observable in a callback so it can be used to update the UI with the state.

我正在进行的项目是一个重构，所以我在事后添加了 Redux.有时，我意识到我需要一段代码中的特定状态属性，我可能没有时间正确重构为可观察的.在这些情况下，我会在 store 上调用 getState 来获取我需要的东西并继续使用它.我不禁觉得这种方法有点缺陷.

The project I'm working on is a refactor so I'm adding Redux after the fact. At times, I realize I need a specific state property in a piece of code that I may not have the time to properly refactor into an observable. In those instances, I call getState on the store to get what I need and move on with it. I can't help feeling like this approach is a little flawed.

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

Is using store.getState where ever I need it considered an anti-pattern? Are their explicit use-cases that I should avoid when using store.getState?

推荐答案

当您过度使用 store.getState() 时，您最终会将全局状态传递给随机组件.你冒着在组件和状态的部分之间引入耦合的风险，这就是反模式.您应该仅出于两个原因调用 getState:获取应用程序的初始状态，以及在您商店的更新逻辑中 - 即在您的 store.subscribe() 回调中.

When you use store.getState() too liberally, you end up passing around the global state to random components. You run the risk of introducing coupling between components and parts of your state that have nothing to do with one another, which is anti-pattern. You should only call getState for two reasons: to fetch the initial state of the app, and in the update logic for your store -i.e inside your store.subscribe() callback.

就您的可观察对象而言，在典型的基于组件的视图层(例如 React)中，您在 redux 应用程序中唯一真正需要观察的是整个应用程序状态作为一个整体，而不是它的各个部分.整个状态的变化都被订阅并从顶级组件滴入.

As far as your observables go, in a typical component based view layer such as React, the only thing you really need to observe in a redux app is the entire application state as a whole, not individual pieces of it. Changes to the state as a whole are subscribed to and trickle down from the top level component.

但是，由于您正在重构 Jquery 应用程序，我认为您使用 observables 是可以接受的.有一个名为 reselect 的库，如果您不想自己动手，可以将其用于此目的.它可以帮助您从全局状态的任意部分计算状态，并提供高效的记忆功能，因此不会重新计算相同的输入.

However since you are refactoring a Jquery application I think your use of observables is acceptable. There is a library called reselect that you can use for this purpose if you don't feel like rolling your own. It helps you to compute state from arbitrary parts of the global state and provides efficient memoization so same inputs don't get recomputed.

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

At times, I realize I need a specific state property in a piece of code that I may not have the time to properly refactor into an observable. In those instances, I call getState on the store to get what I need and move on with it. I can't help feeling like this approach is a little flawed.

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

One easy drop-in solution you could implement in cases like this is to use event emitters in your reducers to propagate pieces of the global state to the specific Jquery components that need them. This will keep you from having to pass around global state, preserving component isolation.

这篇关于在 Redux 中使用 getState 是一种反模式吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！