Isnt notifications updatable?

I found the only way to upadte notifs is to construct a custom transactionId and then delete that one to insert a new one with that transactionId, this is not pretty handy at all. Another thing i found is that if transactionId notif is deleted, we cant create another one with the same transactionId as they are supposed to be once forever... EVEN if i deleted it. Why I cant find another way to fit my usecase using novu? our usecase is updating our users from large processes for example processing editing uploading ready / error And this wont be a good approach to use different notifications for each one as it wont be good UX. Any clues on how to tackle this status following into notifications? thanks in advance
13 Replies
Dima Grossman
Dima Grossman4w ago
Hi, let me check with the team if someone have an idea to achieve this usecase Do you currently use the novu/react package? or the older novu/notification-center
iStun4Fun
iStun4FunOP4w ago
headless / node / api in a combination
Dima Grossman
Dima Grossman4w ago
Another potential solution I can think of, is to render dynamic notification content when building your headless implementation. For example in the payload pass the "document_id" and when rendering hydrate the document based on the id to render the lateast status. Will something like that work for you?
iStun4Fun
iStun4FunOP4w ago
Where can i reference that in documentation?
Novu_Bot
Novu_Bot4w ago
@iStun4Fun, you just advanced to level 4!
Pawan Jain
Pawan Jain4w ago
@iStun4Fun notications.list method returns data.notifications Here notifications is an array of Notification type object Each notification has data field. This field can be used for custom data like document_id
Pawan Jain
Pawan Jain4w ago
No description
iStun4Fun
iStun4FunOP4w ago
Great! So we can make all of them like this for inApp, i will try and come back to see if it fits our usecase For others channel i dont see it practical to do it like this, we will use other steps / workflow for other channels as well maybe doing a digest for them, that sounds ok?
Pawan Jain
Pawan Jain4w ago
@iStun4Fun I am not sure if it is possible to update email/push/sms message in general after it is sent
iStun4Fun
iStun4FunOP4w ago
thats why i told u this
For others channel i dont see it practical to do it like this, we will use other steps / workflow for other channels as well maybe doing a digest for them, that sounds ok?
For others channel i dont see it practical to do it like this, we will use other steps / workflow for other channels as well maybe doing a digest for them, that sounds ok?
Pawan Jain
Pawan Jain4w ago
Yeah sure. Digest is perfect for summary notification usecase
iStun4Fun
iStun4FunOP2w ago
I need to solve this, while we already are doing a custom render, when we delete the notificaiton we cant use that document Id again, so if the user constantly makes changes to the same document it will cease to see them because in the db they persist even if we delete them. Why the scope of transactionIds is to make them perdurable forever, even after delete? To explain myself better: I create the transcationId artist_title type contract.queued, and once is queued the first notification is out there. Once the contract is made i delete that first transactionId named artist_title and send another one with the contract.done... But when i create the same combination like artist_title, that third meaning to be Queued is never out there because that transactionId is already in the db somehow archived or idk how. Is that somehow understandable, i mean our use case and the problems we are facing?
Want results from more Discord servers?
Add your server