Push notifications for pings within cv2 are empty
Description
Receiving pings as notifications has regressed in utility when invoked from within cv2, due to the loss of message content.
Steps to Reproduce
Mention a user or role within a component, with someone on the receiving end getting a push notification for it.
Expected Behavior
When I posted bout this in DDevs showcase thread, advaith said would you just like the text displays concatenated together like we do for Copy Text in the client?, and while I personally don't know what the most correct solution would be, that suggestion is probably the most obvious way about it.
Current Behavior
Empty content, notification only says where the ping came from, as opposed to including any content, or what was @mentioned.
Screenshots/Videos
Client and System Information
Any with a push notification system.
When I posted bout this in DDevs showcase thread, advaith said
would you just like the text displays concatenated together like we do for Copy Text in the client?, and while I personally don't know what the most correct solution would be, that suggestion is probably the most obvious way about it.
Speaking only for my use case here, but I'd prefer this to be more along the lines of "only the first text display in a message is used for the notification content" (or anything to that effect, really), so that I have more control over what the notifications say, as opposed to concatenating everything together, which could lead to undesired content from a later text display being included.
Speaking only for my use case here, but I'd prefer this to be more along the lines of "only the first text display in a message is used for the notification content" (or anything to that effect, really), so that I have more control over what the notifications say, as opposed to concatenating everything together, which could lead to undesired content from a later text display being included.
Part of me is wondering if we could have a component which doesn't render and is ONLY used for the notification? My use case is having markdown headers in the first text display, and wanting to still provide a useful notification.
I have a suggested behavior here that I think is very elegant, and would resolve the ambiguity around what to show nicely.
I would suggest Discord does the same thing that Slack does when using their rich "Blocks" concept (akin to Discord's COMPONENTS_V2). Slack has a top-level field called text which is ordinarily used for message contents in non-rich messages. However, if you are using Blocks, that value is used as the text for the notification (or for any other surfaces where the rich contents cannot be shown).
Here's the documentation for that behavior:
The usage of the
textfield changes depending on whether you're usingblocks. If you're usingblocks, this is used as a fallback string to display in notifications. If you aren't, this is the main body text of the message. It can be formatted as plain text, or withmrkdwn.
So the proposal for Discord is that if you are using COMPONENTS_V2, you can optionally specify the content field with a plain-text fallback for things like notifications. This is similar to @onerandomusername's idea, just a little more intuitive imho.
I like this approach because it gives developers control over what should be shown. Components can be vastly complex, so attempting to systematically infer what a meaningful notification string should be isn't really possible. This leaves the control in developers' hands, where it belongs.
What does everyone think? I would personally love to see this addressed 🥲
Still no update or workaround? This stops for me to fully migrate from embed to cv2