我认为这是一个非常常见的情况......我正在构建一个由某些数据源驱动的组件仪表板。在视图的顶部将是一系列过滤器(例如日期范围)。更新日期范围时,屏幕上的组件需要根据所选范围更新其数据。这反过来会强制该选择器的从属组件需要根据新选择的范围获取新数据(异步操作/ XHR)。
屏幕上可能有许多组件,用户可能希望添加/删除可用的显示,因此它并不像为所有组件刷新数据那么简单,因为它们可能存在也可能不存在。
我认为处理此问题的一种方法是在选择新日期范围时调度的操作是确定屏幕上的哪些组件(从Store中派生)并调度异步操作以获取这些组件的数据。这似乎很多工作将进入DATE_CHANGED操作。
另一种替代方法可能是检测来自每个组件的store.subscribe()回调中的日期范围更改。这似乎解耦了从导致这种情况发生的操作中获取数据的逻辑。但是,我认为在调度时调度是不好的做法(甚至是错误)。当然我可以将它包装在一个setTimeout中,但这也是错误的。
我想到的第三件事就是直接在组件的store.subscribe()中执行fetch调用,并在返回时调度,但我认为这会破坏连接模型。
这似乎是一种基于状态变化获取的常见模式,但我不知道最好放哪些。关于上述问题的任何好的文档/示例?
答案 0 :(得分:1)
请勿使用store.subscribe
。当DATE_CHANGED
到达减速器时,只需更改应用程序状态(我假设日期范围是商店的一部分)。所以你有state.rangeStart
和state.rangeEnd
。
您没有提到您正在使用的视图渲染库,因此我只能描述通常使用React完成此操作:
state.rangeStart
或 state.rangeEnd
已更改的方法。componentWillReceiveProps
或getDerivedStateFromProps
)。在此处理程序中,您将调度异步redux操作以获取组件所需的数据。您的视图库可能会有类似的东西。DATE_CHANGED
操作的reducer中使存储中的数据无效/清除。例如,如果state.listOfThings
(数组)完全取决于日期范围,则会在日期更改后立即将其设置为空数组:return { ...state, listOfThings: [] }
。这会导致组件显示正在再次获取数据。REQUEST
- > SUCCESS
/ FAILURE
周期并且已经使用数据填充了商店,连接的组件将自动呈现它。这是它自己的章节,如果您需要更多信息,请查看redux async actions
。state.listOfThings
,则不希望两次获取此数据。因此,需要有一种方法来检测1)数据范围已经改变,但2)获取listOfThings
的请求已经在路上。这通常使用状态为state.isFetchingListOfThings
的布尔标志来完成。获取此数据的异步操作会导致reducer将此标志设置为true。您的组件需要了解这一点并有条件地发送操作:if (props.rangeStart !== nextProps.rangeStart && !nextProps.isFetchingListOfThings) { props.fetchListOfThings(); }
。