我第一次在jQuery应用程序中使用Redux,并创建了可观察到的小实现。可观察到的对象响应状态对象的多个属性上的更改,在状态本身发生变化时对DOM进行更改。如果我的可观察回调需要2个属性值来完成它的任务,我将观察这两个值,然后使用这些值来更新UI。可观察到的东西根本就不动国家。他们只是在回调中将其呈现给可观察的用户,这样就可以用它来更新带有状态的UI。
我正在做的项目是一个重构,所以我在后面添加了Redux。有时,我意识到我需要一段代码中的特定状态属性,而我可能没有时间正确地将其重构为可观察的代码。在这些情况下,我调用商店中的getState来获取我需要的东西,然后继续使用它。我情不自禁地觉得这个方法有一点瑕疵。
在我需要它的地方使用store.getState是一种反模式吗?是它们在使用store.getState时应该避免的显式用例吗?
发布于 2015-12-24 19:14:16
当您过于宽松地使用store.getState()时,最终会将全局状态传递给随机组件。您可能会在与彼此无关的组件和状态部分之间引入耦合,这是反模式的。您应该调用getState的原因有两个:获取应用程序的初始状态,以及在存储-i.e的更新逻辑中获取store.subscribe()回调。
就您的可观察性而言,在一个典型的基于组件的视图层(如React )中,在redux应用程序中唯一真正需要观察的是整个应用程序状态,而不是单个应用程序的各个部分。对整个状态的更改将从顶层组件中订阅并向下传输。
但是,由于您正在重构Jquery应用程序,所以我认为您使用的可观察性是可以接受的。有一个名为重选的库,如果您不想滚动自己的库,可以使用它。它帮助您从全局状态的任意部分计算状态,并提供高效的回忆录,这样就不会重新计算相同的输入。
有时,我意识到我需要一段代码中的特定状态属性,而我可能没有时间正确地将其重构为可观察的代码。在这些情况下,我调用商店中的getState来获取我需要的东西,然后继续使用它。我情不自禁地觉得这个方法有一点瑕疵。
在这种情况下可以实现的一个简单的跳入解决方案是在还原器中使用事件发射器将全局状态的部分传播到需要它们的特定Jquery组件。这将使您不必传递全局状态,从而保持组件隔离。
https://stackoverflow.com/questions/34455996
复制相似问题