Running LiveView inside a web component with shadow DOM


We are considering offering web components to our customers so they can embed parts of our application in their website. I’m exploring using LiveView for that and have found some challenges. I’m aware of LiveState and have tested it, but I want to rule out LiveView first.

I managed to embed a LiveView in another page in a web component without shadow DOM and have it connect to the socket, everything works.

Using web components without shadow DOM has the issue of component styles interfering with the global style and vice versa. So I want to make it work with shadow DOM.

The problem is that then the shadow root is not visible in the JavaScript side of LiveView since it looks up everything
starting from document. I managed to connect the socket and detected the live view by simulating what
liveSocket.connect() does.

component.shadowRoot.querySelectorAll('[data-phx-session]:not([data-phx-parent-id])').forEach(rootEl => {
  let view = window.liveSocket.newRootView(rootEl)
  if(rootEl.hasAttribute("data-phx-main")){ this.main = view }

With that, I get the log that says phx-some-id mount: but then it fails in attachTrueDocEl because it tries to find
that ID in document. So, I think explicit support in LiveView is necessary to do this. Maybe keeping in each view
which root to use for lookup, whether document or some shadow root set during the “join” phase.

What do you think? Is that something that could be supported by LiveView? Or maybe there are other technical challenges that complicate things.


Hello and welcome,

I have used web components with Phoenix socket and channels

It is simple because there is a npm phoenix package

It’s probably simpler than using Liveview socket, and can be used with shadow dom


Yeah, LiveState is based on that. I wanted to try to make Live View work since it allows the HTML to be handled by Live View templates and using the Phoenix components you already have. LiveState is basically LiveView without the rendering part.

I know you’ve seen live_state, just making sure you didn’t miss live_elements too by the same author.

I saw it, thanks. LiveElements is the opposite of what we want, though. LiveElements is for using web components inside a LiveView. We want a LiveView inside a web component.

I think you will need to fork the liveview package and patch it to work with a specified root. I don’t believe it would be a lot of work because essentially you are using shadowRoot instead of document.

You will need to consider how the websocket is managed, if you have multiple custom elements are they liveviews or live components? Perhaps you may need to model the liveview as a container custom element (which manages the socket) and within that you can use multiple live components also exposed as custom elements. Maybe you come up with a different abstraction.

You probably don’t want multiple websocket connections back to the same server for each custom element, especially if your custom elements can be modelled as live components within a LiveView on the Phoenix side.

The part I’m not convinced about is the double render that liveview requires to mount and render the initial html before the websocket is established and then the second mount and render occurs with the web socket. If your component is embedded in another web application how will the initial html be fetched and rendered?

1 Like

What I did during my tests was expose an endpoint like you normally would for a LiveView and have the component use fetch on that endpoint and replace the HTML with the body of the response.

I guess you can do it that way, although it means the page load requires some more round trips before it can display content.

I do think there is a valid use case for this, Phoenix should be able to do SSR for custom elements using the draft Declarative Shadow DOM. I think conditionally rendering in the Heex templates within a template element in the initial render would support hydration of custom elements as per the spec.

I honestly don’t think there is much of a gap to build web components in Elixir with the initial render being regular LiveView and the component is delivered with some elixir transpilation to JS like what Hologram does and this could completely eliminate any need to run node to support server side Javascript rendering and provide a rich UI all in Elixir.


So, I usually just lurk here, but I think I was one of the first to figure out how to build and launch cross-domain LiveView widgets >3 years ago in a production application (fintech space).

The approach I took was a custom element that defined a shadow, and its contents were an iframe. Load your LiveView URL into the iframe. It’s as easy as that. If you need to also have client-side (from the embedding side) interactions, you’ll be using postMessage. Phoenix hooks between your LiveView and your server just work like normal. No hacking LiveView required (but it did lead to a coworker submitting a patch to Phoenix to fix up an issue with private browsing sessions that’s now included).

The CTO even gave a talk showing off my work at ElixirConf —

If I’m understanding what you’re looking for, I would be happy to chat with you more about it if you would like (email/zoom). There’s a number of little things to get right with CSP and whatnot to make the experience smooth and easy for those consuming your widgets/components. I can be reached at my username at my domain.


What you say about SSR, I’m not sure applies here, since the components would be embedded in third party pages. We don’t control where in the page the component will be.

I didn’t know about Hologram. Interesting project.

I agree that using iframe would remove all these issues since it provides an entirely different document.

I will watch that talk, thank you.

Happy to help. Full disclaimer: what was shown off at ElixirConf was a first working prototype (so I’m obviously completely embarrassed about a number of make-it-work decisions in the code shown that I later refactored into a much more elegant and dynamic system :grimacing:). Feel free to email/message me if questions arise—I’d be happy to talk about things learned and improved along the journey.

Hi, author of LiveState here. Fun fact, LiveState only exists because I was unsuccessful doing what you are trying to do :slight_smile: I ended up diving deep into the bowels of live_view both client and server. It’s been a couple years so I no longer have all the details in my memory banks, but I ended up having to make significant hacks to both. At the point where I ended up needing my own type of templates (heex was doing something I couldn’t get around as I recall) I gave up.

OTOH, I and several others have done projects to build web components for customers with LiveState, this is what’s it’s designed for. If you go this route and need any help (or not!) we’d love to hear about it. Good luck!

Hey @bob would you mind sharing what changes you needed to do to make CSP work in our case?

I’m also trying to run a liveview page inside an iframe as you did for Payitoff, but I’m having problems to make it work well when injecting the iframe in another domain.

Also, another question, did you manage to make your solution work with Safari? Safari will block third party cookies inside an iframe, so to make it work you normally will need to totally remove the session cookie from liveview (you will need to remove the :fetch_session and :protect_from_forgery plugs for example) making it insecure.

Yes it would certainly be primarily for regular site use cases as the initial render is important for SSO.

However I can also see use cases that would allow the component author to ship a tiny shim component and dynamically load the content and the full component code on the first render. This would be a nice way to handle seamless server based upgrades.