Open Zecat opened 8 years ago
Hi @Zecat, I like this approach because it delegates the definition & rendering of all the toasts to one element, which allows to properly handle the correct rendering of toasts on top of anything else, and overcome stacking context related issues. cc @cdata
It sounds relevant to the discussion. We have https://github.com/PolymerElements/iron-fit-behavior/issues/33 right now, but I think we might want to open an issue for building a better overlay system. @valdrinkoshi WDYT?
I needed an toast that stays onscreen if i switch the view, so i build something like @valdrinkoshi descriped.
Since i don't need actions yet for my usecase, they are missing. But it can be responsive as descriped in the MD specs, and queues multiple calls (same toast opened if it's still open closes and reopens it, the user can see it was triggered a second time)
https://www.webcomponents.org/element/IswPolymerElements/isw-snackbar
I found out that paper-toast works great with iron-signals. For a complex application, instead of having a hundred <paper-toast> instances, we could just fire iron-signals transmited to global toasts. It was the idea of paper-toast-patterns. This element allows to open predefined toasts identified by a 'type' attribute so for example, every signals sent with type='warning' will open the warning toast pattern. What do you think of this approach ?