该系统本身很容易理解，但实施起来却很棘手。此外，安全原因让我思考如何做到这一点。

我正在考虑让该功能在前端 Firebase 脚本中工作，只需执行所有操作即可检查该用户是否已经发布了喜欢/不喜欢的内容，并在用户单击时删除/添加/切换。问题在于此方法的安全性：用户不能创建一个不检查是否发布了类似内容的新函数吗？

如果可能的话，这个系统应该如何运作？现在我的逻辑是：

Clicked like:
    locally activate/deactivate like button and remove dislike active class if on
    check docs for this user/doc like
        `1`? -> remove this doc from collection
        `0`? -> switch to `1`, because `0` is dislike
        `undefined`? -> create doc with `vote: 1`
            change (+1/-1 or +2/-2) the value of post votes fields

不喜欢也一样。但对于这么小的功能来说，这听起来确实很复杂。也许可以在不失去安全级别的情况下通过用户/投票进行额外的收集？或者使用 http-triggers 可能会以某种方式帮助解决这个问题？这个功能在一些类似 PHP 的语言上会容易得多，所以我现在很害怕。

这是我的假设。

1. 您有一个具有唯一 ID 的帖子，我们称之为post_id
2. 您有一个具有唯一 ID 的用户，我们称其为user_id
3. 有 3 种有效状态：（未定义）、（喜欢）、（不喜欢）

基本流程如下

为了存储喜欢/不喜欢的内容，您创建一个名为的集合feelings它使用post_id+':'+user_id因为它是文档 ID（这使得查找起来很容易）。

文件位于feelings有一个名为state那个商店-1因为不喜欢，1对于喜欢。

正如您所提到的，您可以简单地将此值设置或覆盖为用户想要的任何值。如果他们决定消除他们的“感觉”并且既不喜欢也不不喜欢，请发出删除命令（这比执行写入将状态设置为 0 更便宜）。

使用云函数收听feelings根据此状态如何变化（或创建/删除）收集和更新帖子文档的喜欢/不喜欢计数。

安全规则只能执行允许的状态-1 and 1，如果您使用 Firebase Auth，您可以简单地强制只允许用户匹配user_id能够改变状态。

你现在有什么？

您现在拥有一个具有以下属性的系统：

• 用户可以喜欢和不喜欢帖子
• 用户可以删除和/或更改他们的喜欢/不喜欢
• 用户只能喜欢或不喜欢一个帖子一次 - 他们不能多次这样做
• 只有有效的状态（喜欢、不喜欢）才能写入数据库
• 只有用户可以更新他们的喜欢/不喜欢
• 可扩展：无论是 10 个帖子，还是数百万个帖子，该系统都可以工作

奖金积分

使用您注册来更新计数的同一 Cloud Functions 事件，您还可以使用它在喜欢和不喜欢数组中的用户 ID 列表中添加或删除。这将允许您列出喜欢或不喜欢某个帖子的用户，而无需查询该帖子中的每个单独文档。feelings收藏

另请记住，Cloud Functions 对于单个事件触发多次的可能性很小。如果您希望保证计数准确，请使代码幂等，或者仅手动触发“重新计数”过程，如果您或用户检测到计数似乎相差一，则可以触发该过程。