我应该建立本地数据层/应用程序状态来维护React Native/Firestore App中的状态吗? [英] Should I build a local data layer/app state to maintain state in a React Native/Firestore App?

查看:90
本文介绍了我应该建立本地数据层/应用程序状态来维护React Native/Firestore App中的状态吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Firestore的主要卖点是能够将其用作在线/离线真相来源.我现在以这种方式使用它:直接在操作上更新Firestore文档,然后侦听Firestore DB的更改并将其映射回本地状态.但是,依靠此延迟补偿和映射回本地状态不足以进行快速更新(即使在文档很小的情况下,切换,切换也是如此).例如,假定RN切换在轻击时切换,切换将抖动",并且直到其已经返回

A main selling point of Firestore is the ability to use it as a online/offline source of truth. I'm using it in this way right now: updating the Firestore document directly on an action, then listening to Firestore DB changes and mapping this back to local state. However, relying on this latency compensation and mapping back to local state is not sufficient for quick updates (taps, toggles even with a small document size). For example, toggles will "jitter" as the RN toggle presumptively shifts on tap, and the local state hasn't been updated until it already returns see video example. It appears worse on Android and the problem isn't strictly limited to basic toggles.

  1. 文档大小或查询结果大小是否对延迟补偿有较大影响?目前,我们的文档非常小,最坏的情况是〜1000个查询结果集.我们可以将文档放大1000倍(100kb),并设置一个大小为1的查询结果.更新:此处的测试似乎不一致,两种情况下的延迟补偿都不理想
  2. 以下哪些其他因素可能会影响延迟补偿?

  1. Does document size or query result size have a bigger impact on latency compensation? Our document size is very small right now with a worst case ~1000 query result set. We could make the documents 1000x bigger (100kb) and have a query result set of size 1. Update: Testing appears inconsistent here, latency compensation is not ideal in either case
  2. Which of the following other things may impact latency compensation?

  • 使用带有自定义索引的查询.注意:我们目前未从缓存中读取内容,我们使用的是JS SDK
  • 多次写入.对同一文档的多次写入会使情况变得更糟(4次快速写入与2次快速写入). 更新:不清楚这会带来很大的不同.
  • 使用本机vs. JS模块.我们目前正在将Firestore Web SDK与Expo应用程序一起使用. 更新:通过React-Native Firestore切换到本地模块并没有明显的性能改善.
  • Using queries with custom indexes. Note: we're not currently reading from cache, we're using the JS SDK
  • Multiple writes. Would multiple writes to the same document make it worse (4 quick writes vs. 2 quick writes). Update: not clear this makes a big difference.
  • Using the native vs. JS module. We're currently using the Firestore Web SDK with an Expo app. Update: switching to native module via React-Native Firestore has no apparent performance improvement.

人们通常使用React Native/Firestore应用程序构建本地数据填充程序层/本地应用程序状态以帮助提高本地性能速度吗?有建议的图书馆吗?

Is it common for people to build a local data shim layer / local app state with React Native / Firestore apps to help improve local performance speed? Are there any suggested libraries for this?

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

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)}
    />
  );
};

推荐答案

我用特定的知识更新了答案,但是经过大量测试,到目前为止,我最大的一般知识是

I updated the answer with specific learnings, but after a lot of testing, my biggest general learnings so far are

  • 即使在相同的数据和环境下,延迟补偿也可能非常不一致.就像其他问题中提到的那样,听众可能需要一些时间来热身".这里很难有一个标准的指标.
  • 文档大小确实会影响延迟补偿.到目前为止,其他所有内容尚无定论.

这篇关于我应该建立本地数据层/应用程序状态来维护React Native/Firestore App中的状态吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆