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

Posted 2023-02-22

【中文标题】Flux 应用程序中的缓存逻辑应该放在哪里？

【英文标题】：Where should caching logic go in a flux app?

【发布时间】：2015-02-13 17:20:31

【问题描述】：

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

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

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

【参考方案1】：

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

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

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

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

你的视图持有缓存逻辑的想法可能感觉很奇怪，但想想缓存是什么：

我需要一些数据。 我是否已经拥有该数据？如果没有... 去拿吧。

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

控制器确实存在于 Flux 应用程序中，但它们是控制器视图——通常位于层次结构顶部的视图，它们从存储中检索数据并将这些数据向下传递给它们的子级。

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

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

读回来，我意识到这似乎都是没有区别的区别，但主要的收获是，不，动作不能检查商店的状态。他们只能通过调度程序与他们通信。您可能会找到一种方法让它在实践中发挥作用（这不应该被忽视！），但它不是惯用的 Flux。

我希望这是有道理的！

【讨论】：

这在高层次上似乎是有道理的，但是如果您有许多共享一个公共存储的组件怎么办？您是否建议在每个组件中复制这种缓存类型逻辑？这对我来说似乎也没有意义。

如果您的所有组件都在执行相同的缓存逻辑，您可能需要重新设计您的组件。可能有一个基础组件，该组件具有此逻辑，所有其他依赖此商店的组件都对其进行了扩展。