javascript - 避免 Firebase 中添加子项/更改子项的无限循环

Question

我正在尝试创建一个工作进程来监听 Firebase 对特定集合的添加/更改。在任何一种情况下，都应该运行一个进程，最终根据它在集合中找到的内容将一些额外的数据写回集合。我遇到的问题是这会导致无限循环，因为 child_changed 会再次触发回调，因为我正在改变它正在监听的同一棵树中的模型。此外，还有一个初始重复工作，第一次通过 child_added 触发 child_changed。

我想出的唯一解决方案是以某种方式将数据放入 Firebase，指示不应发生更新(is_dirty: false，或类似的东西)。我对该解决方案不是特别满意，因为这要求客户端在添加/更改应触发服务器处理的内容时参与翻转标志或其他操作。我希望他们不要那么耦合。我当然喜欢维护某种缓存集合以比较更改的想法，因为这会复制大量数据。

我还考虑在更新之前以某种方式使用 off(之后将其重新打开)，但我担心这会导致我错过那个时间窗口内可能出现的更改。也许这是交易的情况？

此处的最佳做法是什么？目前，我的代码如下所示:

collectionRef.on('child_added', processModel);
collectionRef.on('child_changed', processModel);

var processModel = function (modelSnapshot) {
  // do some stuff that updates model
}

Answer 1

您的主进程和工作进程(默认情况下)非常松散地绑定(bind) - 仅通过一个修改数据而另一个被告知数据已更改的事实链接。

添加队列或信号量是一种更紧密地绑定(bind)它们的方法。

但是，我的首选模型通常是将它们绑定(bind)得更松一些......

与其考虑事件，不如考虑数据的状态。

设计您的工作进程以处理脏数据库并使其干净。然后将“更新时”调用视为优化 - 有效地为您的工作进程提供关于数据库的哪一部分可能需要清理的“线索”。

使用此模式意味着不会出现“无限更新”问题，因为一旦清理完毕，就不会执行额外的更新，而且它的可扩展性很强——您可以让多个工作进程处理数据库的不同部分，或者以不同的方式清理不同的元素。

缺点是数据必须结构化以在“状态”下工作，并且使用数据的程序必须设计为它们读取的数据可能是脏的。虽然如果这很重要，我会让客户端读取数据以检查它是否脏并在继续之前触发清理...