introduce notificationCollapseKey function to reaction message spec. For this method, I returned the joined result of the type, threadID, creatorID, and targetMessageID fields. By using these fields, a notification will be collapsed and won't alert the user if someone is quickly liking and then unliking the same message. I felt that this was reasonable, but can also see that we might want to remove targetMessageID from the joined results to make it less "spammy" if a user likes a bunch of messages in the same thread.
Details
Details
Please watch the demo video to see the changes I made
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
For me it makes sense to keep targetMessageID. One alternative might be to have a notification telling that a user liked x messages in thread ..., but I don't think it will be too useful. Yet another option might be to have a setting which allows users disabling reaction notifications. @ashoat what do you think?
Comment Actions
I think this is a good approach for now, and we can revisit later if we find that it's spammy. Another approach would be to only deliver notifs to the author of the message, which is the same thing we do for threads (but only because the author of the target message is auto-added to the thread).
For reactions, I think limiting notifs to only deliver to the author of the message is blocked on extending generatesNotifs to be more sophisticated, which is related to this discussion.