Hi all! I come with a proposal to create LiveViews inside the shadow DOM. At Doofinder, we have experience building embeddable LiveView apps, and we think it is a valuable addition to the ecosystem, as it allows for fast interaction widgets.

Why

The main problem with multiple LiveViews from different origins coexisting in the same DOM is duplication of events and elements. If we leverage the shadow DOM, we could bypass these limitations while also allowing for easier communication between the host page and the LiveView widgets.

Why use shadowDOM and not <iframe>

While there has already been discussion about doing this with <iframe>, We think the Shadow DOM is more adecuate for the following reasons:

• SEO. If the LiveView widget is loaded with the page, the content would count to the host page, not the origin of the LiveView as it would happen with <iframe>.
• Performance. No need to load a full DOM.
• Session cookie: Safari conflicts with <iframe> and cookies. ref
• Better comunication with host page and with other apps. No need for postMessage().

It is worth noting that I haven’t mentioned anything about WebComponents, because the goal of this is not adding support for them. The approach we present would only mean encapsulating the DOM where the LiveView lives. Here there was a related discussion, and I think some of the problems exposed there could be solved.

What would change

This feature would be a new way to use LiveView and it would not affect regular LiveViews

Doing a quick prototype I identified some areas of work:

1. Add a way to configure a LiveView to create a shadow DOM.
2. Places where document is used to find a DOM element should support using the shadowRoot.
3. Event listeners need to be added to the shadowRoot instead of window.

We volunteer to work on this and implement it.

So what are your thoughts on this? Would you benefit from this feature? Are the core maintainers open to us working on this?