javascript – 在Redux中使用getState是一种反模式吗?

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

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

使用store.getState在哪里我需要它被认为是反模式?在使用store.getState时,我应该避免使用它们的显式用例吗?

解决方法

当你过于宽松地使用store.getState()时,你最终会将全局状态传递给随机组件.您冒着在组件和状态部分之间引入耦合的风险,这些耦合与彼此无关,这是反模式的.您应该只调用getState有两个原因:获取应用程序的初始状态,以及store.subscribe()回调中商店的更新逻辑-i.e.

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

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

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.

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

相关文章

前言 做过web项目开发的人对layer弹层组件肯定不陌生,作为l...
前言 前端表单校验是过滤无效数据、假数据、有毒数据的第一步...
前言 图片上传是web项目常见的需求,我基于之前的博客的代码...
前言 导出Excel文件这个功能,通常都是在后端实现返回前端一...
前言 众所周知,js是单线程的,从上往下,从左往右依次执行,...
前言 项目开发中,我们可能会碰到这样的需求:select标签,禁...