Describe the bug
On show method you have appendTo settings:
https://www.telerik.com/kendo-angular-ui/components/notification/api/NotificationSettings/#toc-appendto
Actually, due to the internal implementation, service is stateful and store notificationContainer from just first call.
We would like to have a singleton that takes care correctly of appendTo settings to every show call.
To Reproduce
Steps to reproduce the behavior:
https://stackblitz.com/edit/angular-fsvkcu
Expected behavior
If we need to provide an individual instance of NotificationService per hostViewElement i guess you have to think to delete appendTo property on show method (i really don't like that approach but it will be really clear to users that we need to provide different instances),
Otherwise, NotificationService has to be fixed.
As a customer, i have access to source code and the main problem i see it is about id generation that it is related only to positions. What about i would like to append on different NotificationContainer with same positions? I also don't like to use dom ID attribute but as already did by Material Dialog team:
https://material.angular.io/components/dialog/api#MatDialogConfig could be really useful to add ID to settings and use it as NotificationContainerComponent finder method.
What do you think?
As workeraround, we still provide an instance for every component has to host notifications independently.
The fix is available in the latest dev version of the package.
Hi @elena-gancheva we will be able to test it when the notification package will be released as stable version.
Any eta about release date?
Thanks.
Hi @meriturva, as soon as the package is released I will update the status of the issue.
Shipped with v2.0.0