在a previous question 中，我询问了谁负责在 Flux 应用程序中向服务器发送更新。人们告诉我，Actions 应该这样做。所以我假设从服务器获取数据也是如此；您有一个 FetchData 操作，它获取数据并分派数据以供商店保留。但是在这种情况下，缓存逻辑是如何工作的呢？
我想我必须存储上次请求列表的时间，并且 StreamsStore 中的列表 TTL 和 fetchStreams 操作将检索 TTL 和上次获取时间以确定是否需要咨询服务器。
这是正确的方法吗？在 store 和 action 之间传播缓存逻辑对我来说似乎很奇怪，但我想不出更好的方法。
【问题讨论】：
这是一个很好的问题，我以前也遇到过。
请记住，Flux 最重要的一点是数据始终以一种方式流动。你已经知道了——我提出来是因为这句话有很大的澄清力，几乎可以回答你对 Flux 的任何疑问。
操作将数据发送到商店，因此，如果您将逻辑添加到检查商店中某物价值的操作中，那么您将按照错误的方向发送数据，违反流程。
那么 Flux 应用的哪个部分从商店接收数据？ 视图。这就是你的答案。
你的视图持有缓存逻辑的想法可能感觉很奇怪，但想想缓存是什么：
视图句柄 #1。这很简单。而#3 显然是由你的行为来处理的。但事实证明#2，至少在 Flux 应用程序中，也是应该在你的视图中处理的——或者更具体地说，你的 controller-views。控制器视图是 Flux 中经常被忽视的部分，可能是因为控制器的概念与 MVC 密切相关。但是 Flux 也有它们！来自 Flux 网站：
控制器确实存在于 Flux 应用程序中，但它们是控制器视图——通常位于层次结构顶部的视图，它们从存储中检索数据并将这些数据向下传递给它们的子级。
假设您使用的是 React，这个想法听起来应该很熟悉。较高级别的 React 组件是控制器，而较低级别的组件更“纯”。
另一种思考方式是注意动作只是调度程序的助手。 （如果我没记错的话，当 Facebook 第一次引入 Flux 时，他们甚至没有提到动作。）当你调用一个动作时，你已经做出了调度的决定：唯一的问题是 what，而不是 如果。
读回来，我意识到这似乎都是没有区别的区别，但主要的收获是，不，动作不能检查商店的状态。他们只能通过调度程序与他们通信。您可能会找到一种方法让它在实践中发挥作用（这不应该被忽视！），但它不是惯用的 Flux。
我希望这是有道理的！
【讨论】：