- Notifications
You must be signed in to change notification settings - Fork 4
Support inbox messages #100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
| } | ||
| | ||
| // Update badge immediately | ||
| await updateInboxBadge(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Badge update uses stale data before deletion completes
The deleteMessage function calls updateInboxBadge() before Gist.removeInboxMessage(queueId) executes. Since updateInboxBadge reads from the local store (via Gist.getInboxMessages()), and the message hasn't been removed from the store yet, the badge displays an incorrect count that still includes the deleted message. Furthermore, after a successful deletion there's no subsequent badge update, leaving the badge permanently out of sync until the 5-second periodic refresh.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense yeah.
| // Inbox functionality | ||
| async function updateInboxBadge() { | ||
| const messages = await Gist.getInboxMessages(); | ||
| const unreadCount = messages.filter(msg => !msg.opened).length; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we offer this as a helper within the SDK? something like getInboxUnreadCount()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was going to add that on the cdp-analytics-js side, but I can add it here as well.
| } | ||
| } | ||
| | ||
| async function loadInboxMessages() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: Should we put inbox methods in their own js file? tbh the whole file could benefit from a bit of a refactor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'll clean this up.
| await loadInboxMessages(); | ||
| await updateInboxBadge(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe put these two in a finally block?
| | ||
| setKeyToLocalStore(inboxLocalStoreName, messages, expiryDate); | ||
| | ||
| Gist.events.dispatch('inboxMessages', messages); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we rename this to messageInboxUpdated? to match the rest: messageShown, messageDismissed, messageAction etc...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that makes sense. It's really only for gist-web<->cdp-analytics-js interaction, but might be clearer as messageInboxUpdated.
| export async function markInboxMessageAsOpened(queueId) { | ||
| const inboxLocalStoreName = await getInboxMessagesLocalStoreName(); | ||
| if (!inboxLocalStoreName) { | ||
| throw new Error('User token not available'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We usually handle errors gracefully since we're an SDK that "just works" by itself. In the inbox case, its a bit different since customers will be interfacing with it, so we need to give them some feedback.
But in this specific case, do you think we need to throw here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this snuck in during some refactoring, I can match the existing in-app local store behavior and just return when there isn't a name.
| } | ||
| | ||
| try { | ||
| const response = await UserNetworkInstance()(`/api/v1/messages/${queueId}`, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should live in a message-service.js under services.
| | ||
| // Update badge on load and periodically | ||
| updateInboxBadge(); | ||
| setInterval(updateInboxBadge, 5000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should hook this up to the new messageInboxUpdated event so it can update in realtime.
Note
Add inbox messages support across SDK (APIs, polling/SSE integration) with example UI and styles; bump user queue endpoint to v4.
src/managers/inbox-message-manager.jsto cache inbox messages per-user, filter by expiry/topic, dispatchinboxMessagesevents,PATCH /api/v1/messages/:queueIdto mark opened, and remove vialogUserMessageView.Gist.getInboxMessages,Gist.markInboxMessageAsOpened,Gist.removeInboxMessageinsrc/gist.js.src/managers/queue-manager.js, on polling, handleresponse.data.inAppMessagesandresponse.data.inboxMessages; add SSE handler forinbox_messagesto update local store./api/v4/usersinsrc/services/queue-service.js.examples/index.htmlwith render/mark-read/delete handlers and periodic badge refresh.examples/styles.css(e.g., fixed header, panel, message states).Written by Cursor Bugbot for commit 96df16c. This will update automatically on new commits. Configure here.