Firebase 的喜欢/不喜欢功能
Posted
技术标签:
【中文标题】Firebase 的喜欢/不喜欢功能【英文标题】:Like/Dislike function for Firebase 【发布时间】:2018-06-26 06:29:41 【问题描述】:系统本身很容易理解,但实施起来很棘手。此外,安全原因让我思考如何做到这一点。
我正在考虑使该功能在前端 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
您有一个具有唯一 ID 的用户,我们称其为 user_id
有 3 种有效状态:(未定义)、(喜欢)、(不喜欢)
基本流程如下
要存储喜欢/不喜欢的内容,您可以创建一个名为 feelings
的集合,该集合使用 post_id
+':'+user_id
作为文档 ID(这样便于查找)。
feelings
中的文档有一个名为 state
的字段,该字段存储 -1
表示不喜欢,1
表示喜欢。
正如您所提到的,您可以简单地将此值设置或覆盖为用户想要的任何值。如果他们决定删除他们的“感觉”并且既不喜欢也不不喜欢,发出删除命令(这比写入将状态设置为 0 更便宜)。
使用 Cloud Functions 监听 feelings
集合并根据此状态的变化(或创建/删除)的方式更新发布文档的喜欢/不喜欢计数。
安全规则只能强制允许 -1
和 1
的状态,如果您使用 Firebase 身份验证,您可以简单地强制只允许匹配 user_id
的用户更改状态。
你现在有什么?
您现在拥有一个具有以下属性的系统:
用户可以喜欢和不喜欢帖子 用户可以删除和/或更改他们喜欢/不喜欢的内容 用户只能喜欢或不喜欢帖子一次 - 他们不能多次喜欢或不喜欢帖子 只能将有效状态(喜欢、不喜欢)写入数据库 只有用户可以更新他们的好恶 可扩展:无论是 10 个帖子还是数百万个帖子,此系统都可以正常工作赠金
使用您注册的相同 Cloud Functions 事件来更新计数,您还可以使用它在喜欢和不喜欢数组中的用户 ID 列表中添加或删除。这将允许您列出喜欢或不喜欢帖子的用户,而无需查询 feelings
集合中的每个单独文档
另外请记住,Cloud Functions 很少有机会为单个事件多次触发。如果您希望确保计数准确无误,可以使代码具有幂等性,或者只需手动触发“重新计数”过程,如果您或用户检测到计数似乎偏离了 1,您就可以触发。
【讨论】:
从来没有想过我可以将选票的值限制在 -1 和 1 之间,我喜欢那个。但是您所说的“用户只能喜欢或不喜欢帖子一次 - 他们不能多次这样做”是什么意思?通常,用户可以随心所欲地更改投票,我如何跟踪用户是否可以在此处更改投票? 多次,我的意思是用户不能向 Firestore 发送请求(绕过您的 UI),这会导致它为单个用户添加 2 个或更多喜欢/不喜欢。在 Cloud Function 中,您可以使用之前的值检查新值,因此如果用户已经“喜欢”了该帖子,您将忽略任何新的“喜欢”更新。您始终可以选择不允许人们在设置后更改其状态,只允许在安全规则中创建但不允许更新。 哦..这就是你的意思。我认为用户应该能够放置喜欢/不喜欢,然后如果他愿意,可以将其取回。所以第二次点击喜欢会删除喜欢。 很抱歉再次触发这个话题,但如果您不难回答,我还有一个问题。你建议如何查看帖子的投票数?总结feelings
的所有投票?对于每页 15 个帖子实时更新它们的功能来说,这不是太多了吗?我觉得听众应该听关于喜欢/不喜欢的帖子的价值,而它会听feelings
创建这个混乱的链结构的喜欢和不喜欢的数量。
@vemund 好吧,不是真的。每次有人添加投票时,我都会添加 +1 或 -1 以在其自己的文档中发布计数器(此外,用户喜欢登录感受)。所以每次我需要计算他们已经设置的选票。我认为这不是一个好的解决方案,但当时对我有用。【参考方案2】:
如果有人想了解实时数据库!
var ref = firebase.database().ref(selectchapter + questionId + user_id);
ref.once("value", function (snapshot)
var exists = snapshot.val() !== null;
if (!exists)
firebase
.database()
.ref(
selectchapter +
questionId + user_id
)
.set(
status: 1
).then(function ()
firebase.database().ref(q +
questionId + "likes").transaction(function (likes)
return (likes || 0) + 1
);
);
);
【讨论】:
以上是关于Firebase 的喜欢/不喜欢功能的主要内容,如果未能解决你的问题,请参考以下文章
约会应用程序 - 我需要在 Firebase Firestore 中使用哪种数据库结构来查询除不喜欢我的用户之外的所有用户?