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.

enter image description here

This image shows the same error, but this time in the unacknowledged errors side panel.

enter image description here

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?

1

There are 1 answers

1
brunnerh On BEST ANSWER

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.