sbb-design-systems
[Bug]: SbbNotificationToast second call to open inconsistent
Preflight Checklist
- [x] I have read the Contributing Guidelines for this project.
- [x] I agree to follow the Code of Conduct that this project adheres to.
- [x] I have searched the issue tracker for an issue that matches the one I want to file, without success.
Bug type
Functionality
It affects the following packages
Components
Which version of Lyne Components are you using
19.0.0-beta.4
Operating system
win11
Browser / Browser version
chrome latest
Input mode
None
Additional settings
No response
What happened?
When reusing the same sbb toast instance, open/close should behave sensible.
see reproduction below.
This is especially relevant, when building a central "toast outlet" in an application - there this issue regularly surfaces.
Steps to reproduce the issue
- Add sbb-toast to template:
<sbb-toast [timeout]="5000" [dismissible]="true" position="bottom-center">
{{ (currentToast$ | async)?.message }}
</sbb-toast>
- add to component
sbbToast = viewChild.required(SbbToast); - call
this.sbbToast().open(); - after 4 seconds call again
this.sbbToast().open(); - observe that the toast closes after 1 second (not as expected after (another) 5 seconds)
When calling this.sbbToast().close(); immediately before "open", then the toast closes and does not open (again)!
Relevant log output
currently a second open() call is ignored because it's already open (we check that to not mess up the state). closing it before re-opening it would be the a solution like you tried, but the event didClose has to be awaited. I think this problem will mainly be solved with a corresponding service and for now the didClose could be awaited before calling open again (or you're setting the animation duration to 0, then it's executed synchronously, but no animation visible).
As an workaround you could handle the timeout yourself, by setting the timeout to 0 and using setTimeout in your wrapper.