Using Webcomponents in LiveView - Pros and Cons

I have no experience using web components with LiveView, but there was a good talk about it at ElixirConf 2021: https://www.youtube.com/watch?v=xXWyOy9XdA8

I use custom components for small jobs in combination with live view. It worked very well so far.
When I want to give the full control of the tag content to the custom component, I put an phx-update=“ignore“ attributed at it. To pass data to the component via live view I use attributes and their change callbacks.

I would post example code here, but I am on vacation and my laptop had to stay at home.

I am investigating using shoelace with liveview currently.

The plan is to use Chris Nelsons live_elements with Shoelace web components.

Reason for this selection:

• Lack of a comprehensive and professional phoenix component library. No, petal components doesn’t cut it.
• Web components don’t require buying into a JavaScript framework ecosystem
• Shoelace is framework agnostic so I can use it everywhere, that means static sites, dead views, liveview, react, vue, svelte etc.
• Shoelace has excellent design tokens making it easy to broadly theme an app, and also specifically target parts within web-components (which use a shadow DOM) and to do so in a way that is not subject to churn within the component. Components can basically remain a black box and still have their sub elements styled without fragility.
• very approachable styling and design tokens in Shoelace using CSS variables, nothing complicated about it.
• live_elements makes working with web components much easier, in particular passing data and receiving events in your liveview.
• I can wrap anything I need in a web component and use it like any other html element without buying into a complicated javascript framework.
• Not reliant on live view hooks for fancy stuff, anything sophisticated becomes a web component
• With web components I can get imrooved reactivity in my liveview apps

I am also aware that tailwind is not aligned with web components as it doesn’t support styling shadow DOM using parts of a web component (as there is no tag to hang a class on).

So your back to using CSS with @apply:

/* parts can be targeted using @apply */
sl-button::part(base) {
  @apply py-2 px-4 bg-blue-500 text-white font-semibold rounded-lg shadow-md hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-400 focus:ring-opacity-75;
}

At this point I feel one may as well embrace the shoelace approach to CSS which in a way is better. Tailwind is the antithesis of broad app wide theming and I hate baking theme decisions in my code. I believe tailwind is at least one reason there isn’t a a compelling UI component library for Phoenix as they have little choice but to bake theme into the component markup and then it’s a pain to use them.

Maybe with Tailwindcss 3.4, and the planned Oxide engine, things will change? I feel the reason for lack of a good UI component library is due to the absence of a library like Framer.
One thing is for sure - there are many takers for a good quality UI component library in LiveView. It is necessary for good Developer Experience. Let us see, from how and where we get it.

I think the first step IMO is a headless UI. The great thing about a headless UI is it provides a uniform contract and robust accessibility. Styling and theming are completely separate concerns.

Imagine if we could build liveview apps with headless component contracts. The ecosystem would have something to anchor to, tools, generators UI kits and CSS themes would emerge for Phoenix and Phoenix itself would be inherently CSS agnostic, anchoring to headless components.

Currently all we have are the core components stop gap for generators and they bake in tailwind styles. The current situation is kind of a mess.

I was also really keen on using shadcn-svelte with live-view but ran into some issues with live-svelte.

shadcn-svelte is basically a theming wrapper of bits-ui (a headless set of compnents) which is in turn composed using melt UI which is a headless component builder.

My reservation with webcomponents is SSR (server side rendering) as that is a requirement for many sites. For a SaaS app it’s less important as you’re not concerned with web crawlers and SEO.

I will see how the experiment goes with shoelace and report my experience with it back here.

I’m currently experimenting with lit and it’s going very well so far.

I was about to give up on LiveView because that extra layer of UI polish was almost impossible with just hooks. But lit has opened it back up again.

I didn’t want to bring in a framework, things don’t always play nicely with esbuild. But I don’t need any fancy stuff just import lit!

And it’s possible to not use the shadow dom at all by doing createRenderRoot() { return this } so I can keep using tailwind easily.

Yes this is the last chance for liveview for me too. If I don’t get a good outcome I’ll be moving forward with SvelteKit and shadcn-svelte. If I go this route I will also look at live-state by Chris Nelson as an alternative to liveview and graphql.

Yes that’s correct if you’re wrapping your own components you can use the light DOM to expose the internals rather than the internals being private and selectively defining a contract for styling using the part:: selector.

Shoelace can still use tailwind for styling if you choose to but specific overrides to internal component parts require use of @apply to target the parts.

I believe use of @appply is still required for light DOM web components as you still can’t put classes on those internal web component elements in your markup when using the component, but all the internals are exposed for styling with CSS via @apply. I much prefer the parts approach than having the fragile dirty internals of a web component reflected in my styling.

I have a few form related components which have hidden inputs so I turn off the shadow dom for those.

I’m still using hooks as a first resort where possible, but if it’s too complicated for a hook. I’ve (so far) found a nice escape hatch with lit.

Do you mind sharing a link to lit? This is the first I’ve heard of it.