Question

我一直试图找到一种基于标签，已读/未读和保存来对帖子进行排序的方法，同时还显示了实时赞。我经历了几次体系结构迭代，但还没有遇到任何可行的方法。

这将显示在移动设备上的无限滚动列表视图中（快速滚动，长列表，仅呈现屏幕上的内容）。

第一次尝试

posts <-- onAdd
  {id}
    title: string
    body: string
    tags
      {tag}: bool
    likes: int <-- onValue

users
  {uid}
    read <-- onAdd
      {id}: bool
    saved <-- onAdd/Remove
      {id}: bool

之所以失败，是因为我的帖子在列表中有1万个或更多，并且在移动视图中，它在快速滚动期间每秒将onValue的赞值设置和删除20到40次，并且引入了大量UI垃圾。另外，如果您向下滚动然后再向上备份，则您读取的前两个数据是我所知的两倍。

然后我尝试监听对posts的添加/删除/更改，这是不可接受的，因为任何时候有人喜欢某个帖子，它都会发送大量无关的数据。

在没有下载所有帖子并手动忽略user/{uid}/read中的每个ID的情况下，我也找不到任何未读帖子排序的方法

第二次尝试

posts <-- onAdd
  {id}
    title: string
    body: string
    tags
      {tag}: bool

users
  {uid}
    read <-- onAdd
      {id}: bool
    saved <-- onAdd/Remove
      {id}: bool

likes <-- onAdd/Change
  {pid}: int

在此示例中，我正在下载所有内容并将其网格化为一种多路复用器。这实际上效果很好，我能够有效地聆听，并将所有这些流合并为具有这样结构的东西

post
  title
  body
  tags
  read
  saved
  likes

这是最有前途的，但是我低估了Firebase缓存数据的时间。而且由于我的清单太长，任何时候有人打开应用程序，他们都会得到一堆数据（1mb或更多），这将使应用程序变慢直到完成，并可能消耗大量数据。

我真的很费劲，想出一种便宜且可排序的方法，可以很好地处理无限滚动列表。

我不确定分页有很多事情。

1）将onValue设置为整个列表，将onValue添加/删除/更改为整个列表，或者将onValue设置为可见列表项并允许用户滚动设置和删除侦听器是否便宜？

2）如果您正在监听第1-100个条目的列表，然后将监听器从1-200更改，那么您在重新初始化监听器时会重新下载1-100吗？

3）如果您从1-100开始收听，向上滚动并触发重新收听到101-200，然后向下滚动回到1-100，您是否会两次下载1-100数据？

4）订阅帖子1-100或设置100个听众是否更昂贵？（想象一下，只尝试收藏夹并下载所有ID，然后使用它们来设置所有侦听器）

所有这些事情在此应用的体系结构中带来了许多不确定性，我很难找到答案。

我有信心可以构建任何解决方案，但我认为我对Firebase的了解不足以构建一个解决方案。

据我所知，您希望进行浅层查询，并尽可能少地设置侦听器，并且在可以手动进行onAdd / Remove / Change组合时永远不要使用onValue

感谢您的帮助

Answer 1

如果您不依赖于实时数据库，则可以尝试将体系结构应用于Firestore（Firebase的更新/其他数据库产品）。 Firestore包括显式分页（limit/order-by）和隐式分页（Snapshot listeners）。

您应该研究两个平台之间在结构和计费方面的差异，但是听起来Firestore可能更适合您所介绍的项目。

您将如何在实时数据库中实现已读回执和未读排序？

1 个答案: