caching - Flux 应用程序中的缓存逻辑应该放在哪里？

Question

在 a previous question我问谁负责在 Flux 应用程序中向服务器发送更新。人们告诉我，Actions 应该这样做。所以我假设从服务器获取数据也是如此；您有一个 FetchData 操作，它获取数据并分派(dispatch)数据以供商店保留。但在这种情况下，缓存逻辑将如何工作？

我想我必须存储上次请求列表的时间，并且 StreamsStore 中的列表 TTL 和 fetchStreams 操作将检索 TTL 和上次获取时间以确定是否需要咨询服务器。

这是正确的方法吗？在商店和 Action 之间传播缓存逻辑对我来说似乎很奇怪，但我想不出更好的方法来做到这一点。

Answer 1

这是一个很好的问题，我以前也遇到过。

请记住，Flux 最重要的一点是数据始终以一种方式流动。你已经知道这一点——我提出它是因为这句话有很大的澄清力，并且几乎可以回答你可能对 Flux 提出的任何问题。

操作将数据发送到商店，因此，如果您将逻辑添加到检查商店中某物的值(value)的操作中，那么您将向错误的方向发送数据，与流程相反。

那么 Flux 应用程序的哪个部分从商店接收数据？观点。这就是你的答案。

你的 View 持有缓存逻辑的想法可能会让人觉得很奇怪，但想想缓存是什么:

我需要一些数据。

我已经有这些数据了吗？如果没有...

去实现它(梦想);去得到它(东西。

View 句柄 #1。这很简单。而#3 显然是由你的行为来处理的。但事实证明#2，至少在 Flux 应用程序中，也是应该在你的 View 中处理的——或者更具体地说，你的 Controller View 。 Controller View 是 Flux 中经常被忽视的部分，可能是因为 Controller 的概念与 MVC 密切相关。但是 Flux 也有它们!从通量网站:

Controllers do exist in a Flux application, but they are controller-views — views often found at the top of the hierarchy that retrieve data from the stores and pass this data down to their children.

假设您使用的是 React，这个想法听起来应该很熟悉。较高级别的 React 组件是 Controller ，而较低级别的组件更“纯”。

另一种思考方式是注意 Action 只是调度程序助手。 (如果我没记错的话，当 Facebook 第一次引入 Flux 时，他们甚至没有提到 Action 。)当你调用一个 Action 时，你已经做出了调度的决定:唯一的问题是什么，而不是如果。

读回来，我意识到这似乎都是没有区别的区别，但主要的收获是，不， Action 不能检查商店的状态。他们只能通过调度程序与他们通信。您可能会找到一种使其在实践中发挥作用的方法(不应该打折!)，但这不是惯用的 Flux。

我希望这是有道理的!