7 Patterns to launch Polymer dialogs

All patterns we used so far to launch dialogs with Polymer. Winner: Use mixins to reuse dialog business logic and instances.

Ronny Roeller
NEXT Engineering
4 min readDec 17, 2018

--

Pattern #1: Declarative dialogs

Many Polymer starter examples declare dialogs in the element’s template:

The downside is that the dialog template gets always stamped on startup, independently if the user ever opens the dialog or not.

Pattern #2: Dynamic dialog creation

Creating the dialog when the user clicks the button avoids this issue:

Explanation: We add the dialog to the document body instead of the current element to prevent layering issues (seeing your dialog underneath your app). Be aware that the launching element won’t receive any events fired by the dialog because the dialog isn’t a child of it any longer.

The main issue with this approach is that we create now a new dialog whenever the user clicks the button.

Pattern #3: Lazy created singleton

We can avoid the multiple instances by lazily creating a singleton:

Explanation: We encapsulate the lazy creation in an asynchronize method to get an easy-to-use Promise-based API.

This is our favorite pattern if we want to launch a dialog from exactly one element. Things get more tricky if you have to launch the dialog from multiple elements because you would have to copy & paste the above lines over and over.

Pattern #4: Share launching code via mixins

Mixins are a great way to share the launching code:

Each element can now easily launch dialogs via the mixin method:

Important: Ensure to include the name of the dialog in the openXXX() and in getXXXInstance() method. This avoids name clashes when adding multiple dialog mixins to an element.

Pattern #5: Move business logic into the mixin

We found the mixins the perfect place for all business logic related to the dialog: prepare data for the dialog, save data from the dialog, etc.

Pattern #6: Event consumption via mixins

As mentioned above, adding the dialog to the document.body prevents the launching element from receiving events fired by the dialog. Mixins allow us to bring this back as well:

Now you can consume these events from the launching element, e.g.:

Before using this, you need to carefully think through what’s going to happen when the event is fired: Our dialog is a singleton. This means that the event listener will be called independently of which element launched the dialog. Sometimes this is what you want. Often it isn’t.

Pattern #7: Callbacks for launcher specific events

To avoid this, just pass the callback to the open method in the mixin:

Explanation: We leverage the fact that the dialog can only be once on the screen (otherwise we couldn’t use a singleton for the dialog element itself).

Now, the launching element can provide a callback that is called only when the dialog was opened by the element itself:

Happy coding!

--

--

Ronny Roeller
NEXT Engineering

CTO at nextapp.co # Product discovery platform for high performing teams that bring their customers into every decision