在上一个问题中,我询问谁负责在Flux应用程序中向服务器发送更新.人们告诉我,行动应该这样做.所以我假设从服务器获取数据也是如此; 您有一个FetchData操作,它获取数据并调度要保留的商店的数据.但在这种情况下,缓存逻辑将如何工作？
我想我必须存储最后一次请求列表,并且StreamsStore中的列表的TTL和fetchStreams操作将检索TTL和上次获取时间以确定是否需要查询服务器.
这是正确的方法吗？在商店和动作之间传播缓存逻辑对我来说似乎很奇怪,但我想不出更好的方法.
这是一个很好的问题,也是我之前遇到的问题.
请记住,关于Flux最重要的事情是数据总是以一种方式流动.你已经知道了 - 我提出这个问题是因为一个声明有很多澄清的力量,并且几乎可以解答你对Flux的任何疑问.
操作会将数据发送到商店,因此,如果您为检查商店中某些内容的值的操作添加逻辑,则会针对流向错误的方向发送数据.
那么Flux应用程序的哪一部分从商店接收数据？该意见.有你的答案.
你持有缓存逻辑的观点的想法可能会让人觉得奇怪,但想想缓存是什么:
视图处理#1.这非常简单.#3显然是由你的行为来处理的.但事实证明#2,至少在一个Flux应用程序中,也应该在你的视图中处理 - 或者更具体地说,你的控制器视图.控制器视图是Flux中经常被忽视的部分,可能是因为控制器的概念与MVC密切相关.但是Flux也拥有它们!来自Flux网站:
控制器确实存在于Flux应用程序中,但它们是控制器视图 - 通常位于层次结构顶部的视图,用于从存储中检索数据并将此数据传递给其子级.
假设你正在使用React,这个想法应该听起来很熟悉.更高级别的React组件是controller-y,而更低级别的组件更"纯粹".
另一种思考方式是注意到行动仅仅是调度员帮助者.(如果我没记错的话,当Facebook首次引入Flux时,他们甚至没有提及行动.)当你召集一个动作时,你已经做出了调度的决定:唯一的问题是什么,而不是如果.
读回来,我意识到这可能看起来像是区别而没有差异,但主要的不同之处在于,不,行动无法检查商店的状态.他们只能通过调度员与他们沟通.你可能会找到一种方法让它在实践中起作用(不应该打折!),但它不是惯用的Flux.
我希望这是有道理的!