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

查看:75
本文介绍了在Redux中使用getState是一种反模式吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在jQuery应用程序中第一次使用Redux,并且我创建了一个小的可观察实现。 observable正在响应状态对象的多个属性的更改,在状态本身发生更改时对DOM进行更改。如果我的可观察回调需要2个属性值来完成它的任务,我将观察这两个值,然后使用这些值来更新UI。可观察者根本不接触国家。它们只是在回调中将它呈现给observable,因此它可以用来更新状态的UI。



我正在研究的项目是一个重构,所以我事后加入Redux。有时,我意识到我需要一段代码中的特定状态属性,我可能没有时间正确地重构为一个可观察的。在这些情况下,我在商店中调用 getState 来获取我需要的内容并继续使用它。我不禁觉得这种做法有点瑕疵。



使用 store.getState 我需要将它视为反模式吗?当使用 store.getState

解决方案

如果过于宽松地使用 store.getState(),最终会将全局状态传递给随机组件。您可能会在组件和状态的某些部分之间引入彼此无关的耦合,这是反模式的。您应该只调用 getState ,原因有两个:获取应用的初始状态,以及商店的更新逻辑 - 在商店内.subscribe()回调。



就你的观察者来说,在一个典型的基于组件的视图层,如React,你唯一的事情真的需要在redux应用程序中观察整个应用程序状态作为一个整体,而不是单个部分。对整个州的更改将从顶级组件订阅并逐渐减少。



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


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


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


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.

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.

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?

解决方案

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.

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.

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.

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.

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆