我应该构建本地数据层/应用程序状态来维护 React Native/Firestore 应用程序中的状态吗？

Question

Firestore 的一个主要卖点是能够将其用作在线/离线事实来源。我现在正在以这种方式使用它：直接在操作上更新 Firestore 文档，然后侦听 Firestore DB 更改并将其映射回本地状态。然而，依靠这种延迟补偿和映射回本地状态不足以实现快速更新（即使文档大小很小，也可以点击、切换）。例如，切换将“抖动”，因为 RN 切换可能会在点击时移动，并且本地状态在返回之前不会更新，请参阅视频示例。在 Android 上情况似乎更糟，而且问题并不严格限于基本切换。

1. 文档大小或查询结果大小对延迟补偿的影响更大吗？目前我们的文档大小非常小，最坏情况下大约有 1000 个查询结果集。我们可以将文档放大 1000 倍 (100kb)，并拥有大小为 1 的查询结果集。更新：此处的测试似乎不一致，延迟补偿在这两种情况下都不理想

2. 以下哪些其他因素可能会影响延迟补偿？

   • 使用带有自定义索引的查询。注意：我们当前没有从缓存中读取，我们使用的是 JS SDK
   • 多次写入。对同一个文档进行多次写入会使情况变得更糟（4 次快速写入与 2 次快速写入）。更新：不清楚这有很大的不同。
   • 使用原生与 JS 模块。我们目前正在将 Firestore Web SDK 与 Expo 应用结合使用。更新：通过React-Native Firestore切换到本机模块没有明显的性能提升。

3. 人们是否经常使用 React Native / Firestore 应用程序构建本地数据填充层 / 本地应用程序状态来帮助提高本地性能速度？有没有推荐的库？

在应用程序加载时，安装侦听器，并将结果导出到上下文以通过应用程序使用

const [user, setUser] = useState();

firebase.firestore().collection(`users/${user.uid}`).onSnapshot(qs => setUser(oldState => {
    const newState = {};
    qs.docChanges().forEach(change => {
      if (change.type === "added" || change.type === "modified") {
        newState[change.doc.id] = {
          docid: change.doc.id,
          ...change.doc.data(),
        };
      } else if (change.type === "removed") {
        delete oldState[change.doc.id];
      }
    });

    return {
      ...oldState,
      ...newState,
    };
  }))

用于切换通知的示例组件和函数：（开关不稳定）

const toggleNotifications = (user, value) => {
  firebase.firestore().doc(`users/${user.uid}`).update({
    wantNotifications: value,
  });
};

const TestComponent = () => {
  //gets from context, set in listener mounted on app load
  const { user } = useUserContext();
  return (
    <Switch
      value={user.wantNotifications}
      onValueChange={value => toggleNotifications(user, value)}
    />
  );
};

Answer 1

这不是一个答案，只是一个长评论:)

@learningAngular 例如，toggleNotifications只需要调用异步操作创建者，而不必担心将任何逻辑放入反应组件中。

相反，Redux 模式提供了执行某些逻辑的空间，在这种情况下，因为用户最后一刻的决定是事实的来源，所以调度函数总是会在开始更新 firestore 之前设置一个本地的tempState，updatingStatus然后在 firestore 承诺解决或拒绝后，将一个操作调度到减速器重置updatingStatus。然后选择器将检查是否updatingStatus仅依赖本地tempState，否则依赖侦听的 Firestore 状态。最后，反应组件使用选择器结果作为当前有效状态。

我不回答这个问题，因为我没有那么多经验。我也很好奇是否有一个好的解决方案，但这就是我认为目前的解决方案。