Firebase Firestore聊天页监听器页面重进重复下载数据优化问询

• 你对Firestore本地缓存的机制理解存在偏差：默认情况下web端Firestore的离线持久化是关闭状态，只有移动端SDK默认开启该能力。如果你没有手动开启持久化，每次重新挂载监听器都会直接从服务端拉取全部匹配的文档，每匹配1条文档就产生1次读操作，你当前集合有6条消息，进入页面4次就会产生24次读，和你反馈的25次统计结果基本吻合，差值属于后台统计的正常误差范围。
• 现有监听器没有做增量查询限制，每次初始化都会拉取最新的30条消息，没有基于本地已有数据的时间戳限定查询起点，就算开启持久化，未指定起点的全量查询也可能触发额外的读操作。
• 次要原因：如果你的路由存在页面栈缓存逻辑，页面没有真正销毁时可能出现监听器重复挂载的情况，不过你已配置清除逻辑，该问题影响很小。

• 1. 手动开启Firestore离线持久化
     如果你是web端项目，在Firebase初始化的位置新增如下配置：

  firebase.firestore().enablePersistence()
    .catch((err) => {
      if (err.code == 'failed-precondition') {
        // 多标签页同时打开时会触发该异常，按需做降级处理即可
      } else if (err.code == 'unimplemented') {
        // 浏览器不支持持久化时触发，正常走实时拉取逻辑即可
      }
    });
  

  开启持久化后，监听器会优先从本地缓存拉取数据，只有服务端数据有更新时才会拉取变更的部分，不会每次进入页面都产生全量读操作。

• 2. 改用增量查询逻辑
     不要每次都拉取全量30条消息，基于本地已加载的最新消息时间戳做增量拉取，历史消息走上拉加载的懒加载逻辑即可：

  // 示例逻辑，可结合你现有状态调整
  const lastMsgTimestamp = chatmessages.length > 0 ? Math.max(...chatmessages.map(m => parseInt(m.timestamp))) : 0;
  const loadnewmessages = firebase.firestore().collection("group_rooms").doc("group_rooms").collection(`${countryId}`)
    .orderBy("timestamp")
    .startAfter(lastMsgTimestamp)
    .limit(30)
    .onSnapshot(/* 原有处理逻辑 */)
  

  就算未开启持久化，该逻辑也能保证每次进入页面只拉取新产生的消息，不会重复读取历史数据。

• 3. 全局复用监听器和消息状态
     可以把聊天消息状态和监听器挂载逻辑提升到路由上层或者全局状态（比如你当前用的Redux），不需要每次进入页面就销毁重建监听器、清空消息状态，从根源避免重复挂载产生的读操作。
• 4. 修复删除消息的隐性问题
     你当前处理removed类型变更时只处理了第一条删除的消息，同时删除多条消息会漏处理，而且直接splice原状态数组属于引用修改，会导致React状态更新异常，建议调整为如下写法：

  setChatMessages(prev => {
    const newArr = [...prev];
    deletedmesssages.forEach(delMsg => {
      const index = newArr.findIndex(m => m.timestamp === delMsg.timestamp);
      if (index !== -1 && Date.now() - parseInt(newArr[index].timestamp) <= 300000) {
        newArr.splice(index, 1);
      }
    })
    return newArr;
  })
  

内容的提问来源于stack exchange，提问作者Kubaghetto the fresh Testobun