I haven’t got to the data tables yet, however for events emitted by components that’s where live-elements comes in, and it also creates function component wrappers so it works with liveview and wires up any specified events.
On the return path for data from the server ultimately we are rendering rows into phoenix component slots which are also mapped to custom element slots by live elements. I am expecting this will just work also with the newer streams approach.
I hadn’t been aware of spectrum before this. Looks great. Is the current adobe spectrum component docs/explorer spectrum 1 or 2? It’s not clear from the adobe pages whether version 2 release is TDB or already publicly available. First class web components UI libraries with focus on a11y is great and should be able to replace usage of Hooks in many cases.
It’s v1.
An easy way to use webcomponents would be a great step forward for LV.
But: it’s not easily done. The work of Chris helps, but its still hard.
The lack of a decent component library is what is keeping us in JS-framework-land for now.
It’s currently V1. The v2 should be out soon.
Yes I agree. I think web components are the answer to competing with front end frameworks, to the point many front end frameworks are using these capable frameworks like Spectrum and Carbon which bake in a11y.
I got both the Shoelace and Spectrum stuff working but both lacked a few navigation elements and reactive things like sidenav/drawers, which I think is odd because that’s a big part of accessibility and keyboard navigation.
I then moved onto integating the Carbon Design System V11 web components into my asset pipeline which does deal with these concerns.
Another option I considered was compiling the Svelte bits-ui as a very clean set of unstyled, headless accessibility focused custom elements which has extremely minimal dependencies as it’s built on the melt-ui component builder by the same authors (which was inspired from working with Radix UI).
Bits UI is used and themed in shadcn-svelte using tailwind and is basically just a copy paste component collection built using bits-UI with some default base layer theming and a handful of color tokens.
I still might do this as an experiment to see what the snags are.
So I believe a really nice headless UI system based on custom elements is within reach. It’s more or less just a re-packaging of bits UI as custom elements using the svelte compilation flag to emit custom elements.
That could serve as the minimal headless UI foundation for Phoenix, and also align nicely with the current use of tailwind also (the bits UI component examples show the element structure and the code examples show use of tailwind classes for example styling).
I would suggest adopting a base theming layer and some design tokens very much as shadcn-svelte has done as a theme engine for Pheonix.
Then add in the custom element event helper for wiring events back to liveview and it’s getting tantilisingly close.
The next step beyond this would be a much larger step, to make custom elements a first class engine of how “LiveView V2” works as a possible future.
This would require Phoenix to render the elements into a declarative shadow dom template on first render.(sounds complex but it’s literally just adding a template tag) so that we get server side rendered custom elements without any JS/node. We could literally beat the JS frameworks on this.
The other half is to generate a custom element and transpile the render function to JS, which gets shipped to the client as a custom element. Hologram already has a nice Elixir to JS transpiler. The html should include any client side scripts and styles. A good example would be callbacks for client side reactivity, keyboard and navigation events etc.
Liveview interaction with the client would then become more like LiveState and just exchange delta state and events over a Phoenix channel, so rather than pushing html / Dom patching, it’s pushing state patches, and the custom elements emit events that are forwarded to the server and handled just like they currently are (basically what is done in LiveState).
Why do all that?
Can you expand where LiveView falls short here? webcomponents/custom elements by their nature are “just tags” so the LiveView integration story vs where you’d use a hook today works just fine. For example, here’s the LiveBeats Flash hook vs Flash web component:
// <div phx-hook="Flash"> ...
Hooks.Flash = {
mounted(){
let hide = () => liveSocket.execJS(this.el, this.el.getAttribute("phx-click"))
this.timer = setTimeout(() => hide(), 8000)
this.el.addEventListener("phx:hide-start", () => clearTimeout(this.timer))
this.el.addEventListener("mouseover", () => {
clearTimeout(this.timer)
this.timer = setTimeout(() => hide(), 8000)
})
},
destroyed(){ clearTimeout(this.timer) }
}
// vs
// <lb-flash> ...
class Flash extends HTMLElement {
connectedCallback(){
let hide = () => liveSocket.execJS(this, this.getAttribute("phx-click"))
this.timer = setTimeout(() => hide(), 8000)
this.addEventListener("phx:hide-start", () => clearTimeout(this.timer))
this.addEventListener("mouseover", () => {
clearTimeout(this.timer)
this.timer = setTimeout(() => hide(), 8000)
})
}
disconnectedCallback(){ clearTimeout(this.timer) }
}
customElements.define('lb-flash', Flash);
WC can get more complex when shadowdom comes into play, but then it’s also a nice segregation from LV DOM patching so you can get around the phx-update=ignore steps. Having this available in a LV collocated/same file way would be great, but what roadblocks exist for you where WC + LV is not “easy to use” ?
The main things I found “not easy to use” with LV/WC integration were:
All of these are certainly possible to do yourself, it just gets a bit tedious IMHO, which is my I created live_elements. It uses macros to make custom elements work just like LV functional components.
Agree. Ive been using it 
I will raise a couple of PRs for live elements when I’m back to the office which handle some edge cases.
I’m also planning to automate the CEM generation with a watcher as part of my build pipeline, which might result in a documention PR.
That’s only true for “dumb” components that get all information they need from the tag-structure. But when they have some methods or emit events it’s another story. And it’s beyond me.
@andrewh will hopefully soon share his findings, so we get a picture what really needs to be done.
This looks promising. Complete, headless, tailwind-stylable web-components with decent a11y and a painless LV-wrapper would be the perfect solution.
I’m always on the edge about this one. Imo web components would do better by working more with the dom. That should actually simplify their usage (mapping to standard html essentially), but it certainly isn’t as simple from the web component implementers pov. Though really you’d need to regularly check attributes for changes just as much as you’d need to check nested markup.
The reason why we didn’t do that much in the past is because that required shipping a compiler to runtime (see early days of vuejs, where people did that for a short time). But with web components being a standard we don’t need to treat innerHTML as useless for passing in data.