Feature request: specify toastId when creating toaster

[sherlock1982]

When I call pop like this toastId will be rewritten inside library:

    const toast = this.toasterService.pop({
        type: 'chat',
        toastId: '100',
        body: ChatToastAdapterComponent,
        data: message
    });

I know I can change toastId in returned value but that will break timeouts logic.
If I want to remove toaster identified by '100' and add a new one also identified by '100'. Currently I will need to track a map of toastId's to my internal Id's.

I will take care: toastId's will be unique but they will make sense inside my application.
Basically the same logic implemented in WebNotifications with tag.
I can make a PR if you want.

[Stabzs]

Is there a reason you can't map the returned toastId to your internal id once the toast is popped?

Allowing for manually created toastIds tends to cause a number of issues for multiple container use cases. I'd prefer not to expand the API in this way unless absolutely necessary.

[sherlock1982]

There's no reason I can't map. But to map I will need to write additional code which is simply avoidable if I can provide toastId.
Another option will be a function to close toaster by predicate. For example close a toaster which data satisfies some condition.

Just to give you an idea:
For example I receive a chat message from 'John'. Now I receive a second message and I want to replace previous toaster marked as 'John'. Currently I need to make additional map for it while there's already a map inside the lib.

Maybe make a user provided 'tag' and than function to close by tag.
This is how WebNotifications work and I suppose toaster has somehow similar use cases.

[sherlock1982]

Looks like I found another way.
There's hide and show callback.
So I can remove from internal map on hide callback and add to map on show callback.
It's a way to organize map easier.

[Stabzs]

I'm glad you found a workaround. I'm still considering merging in your PR and making it a first class citizen of the API but I need to review duplicate toast checks first to make sure the behavior will remain consistent.

[Stabzs]

This has been released in version 5.1.0.