Running LiveView inside a web component with shadow DOM

jfpedroza

Hi.

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)
  view.setHref(window.liveSocket.getHref())
  view.join()
  if(rootEl.hasAttribute("data-phx-main")){ this.main = view }
});
window.liveSocket.bindTopLevelEvents()
window.liveSocket.socket.connect()

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.

14 comments

/phoenix #liveview #web-components

3 2063 14

2024-01-12 12:22:12 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

kokolegorille

Hello and welcome,

I have used web components with Phoenix socket and channels

It is simple because there is a npm phoenix package

https://www.npmjs.com/package/phoenix

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

Post #1

jfpedroza

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.

Post #2

johnknott

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

Post #3

jfpedroza

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.

Post #4

adw632

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?

Post #5

jfpedroza

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.

Post #6

adw632

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.

Post #7

bob

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 — https://youtu.be/DA32q8kd9pA?feature=shared

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.

Post #8

jfpedroza

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.

Post #9