I'm building an app using Svelte and Carbon Components (for Svelte). I'm trying to build an error notifications component which runs off an error store: When an error is thrown, a ToastNotification
component is displayed across the top of the page; At the same time, there's a side panel (which the user can show/hide) which also lists all the unacknowledged errors.
Both the notifications across the top and in the side panel are obtained from the same store.
This image shows the toaster notification across the top of the page, along with its close icon.
This image shows the same error, but this time in the unacknowledged errors side panel.
What I want to do: If the user clicks x
in the corner of the toaster notification then the error is considered acknowledged and is removed from the store. However, if the toaster notification displayed across the top of the page times-out, it will be hidden, but the same error should remain visible in the side panel (until the user clicks x
on that toaster notification).
However, I can't find any way to distinguish between the toaster notification being hidden due to timing-out, and being hidden because the user has clicked x
.
If I capture the on:close
event I see the same custom event for both actions:
CustomEvent {isTrusted: false, detail: {…}, type: 'close', target: null, currentTarget: null, …}
isTrusted: false
bubbles: false
cancelBubble: false
cancelable: true
composed: false
currentTarget: null
defaultPrevented: false
detail:
timeout: true
[[Prototype]]: Object
eventPhase: 0
returnValue: true
srcElement: null
target: null
timeStamp: 12333
type: "close"
[[Prototype]]: CustomEvent
So it looks as if clicking x
actually invokes a timeout, and consequently I can't see any way to differentiate between an actual timeout and the user clicking x
.
Is there a way to differentiate between those two events?
I think you might be missing one of the events and the timeout
property should be false
for the manual interaction. Currently the component fires the close event from the timeout even if the toast has been dismissed before the timeout happens (GitHub issue).
The easiest workaround is probably to just not use the built-in mechanism and implement your own time-based close logic via setTimeout
. If you construct the component via the client-side API, you can destroy the component on close which also prevents the event from the timeout.