React/Redux - 你什么时候应该从 API 获取新数据来更新你的商店？

Question

我正在尝试了解使用 API 中的数据更新/刷新 Redux 状态时的最佳做法。

想想这个场景：

您有一个待办事项应用程序，其中许多用户可能会在任何给定时间点更新与您相同的待办事项。显然，您希望您的本地 Redux 存储最终反映其他用户的这些更改。

你愿意：

• 获取路线更改时更新的待办事项集？
• 当/如果用户更改待办事项或与之交互时，获取该待办事项的更新版本？
• 两者都有？
• 从不 - 一旦获取状态，您就将状态保存在存储中，它会成为该会话的真实来源（显然不理想）
• 还有别的吗？

我现在对向客户端推送更改或轮询 API 不感兴趣（啊！）。我只是想就大多数开发人员何时刷新存储在 Redux 状态中的 API 派生数据达成某种共识。

Answer 1

这是我从你的问题中得到的

1. 应用中的相同空间由多个用户更新。
2. 应用上的任何用户都必须让其他用户完成更改。
3. 您想知道何时获取数据或刷新商店。

我现在对将更改推送给客户不感兴趣，也不 轮询 API（啊！）。

我不明白这是为了什么。您可能不会更新应用程序，但要查看您的应用程序应该由一个或另一个更新的更改。

除此之外，我还告诉您订阅获取数据的任何位置。我不知道您对订阅的理解是什么，据我所知，订阅是继续定期获取以获取更新。订阅本质上是异步的。

我给出一个实现订阅的简单例子。

console.log("Started");
let subscription = false;
const getData = () => {
  // call your database and fetch the data and once
  // fetching done call the getData again

 // Think setTimeout as database call.
 // upon resolving the data I called it again
 // It neither stops other call back from running run
  setTimeout(() => {
    console.log("Fetching");
    if(subscription) {
      console.log("shuting");
      return;
    }
    getData();
  }, 1000);
}

getData();

setTimeout(() => {
  console.log("hello");
}, 5000);

setTimeout(() => {
  subscription = true;
}, 8000);

Answer 2

如果您不想推送或轮询，请在用户请求时获取数据。从不获取可能非常适合边缘案例应用程序，但绝对不是常见用例。