Nice one, aside from that and the live element hook for event ergonomics that is all the hooks one ever needs to do anything with custom elements/web components.
I am also looking at some other interesting ideas from @superchris, in particular his live_state solution for delivering state to custom elements over web sockets / phoenix channels as a total replacement for liveview.
My research suggests we can deliver state from our Phoenix backed to the front end in about the most streamlined fashion possible with live_state, and then on the front end we can deliver that state into web components using lit-state for full reactivity on the front end with whatever web components / custom elements we choose to use.
In fact I am also looking at going full PWA for my front end using create-lit-pwa and live_state (which also delivers events into our phoenix backend just like LiveView but it’s not LiveView) with no need for graphql whilst keeping my phoenix backend the same and just interacting with my contexts via live_state rather than LiveView.
The goal is web standards based UI, high adherence to web acccessibility with established web components and zero javascript framework nonsense, avoiding web API layers, and with a total overhead of just 5kb for my client app shell with PWA support.
If you think about it, all a front end needs is state delivered from the backend to render and the ability to send events to the backend and receive updated state to re-render. We don’t need complex API layers and bloated client side web frameworks with the available web standards already supported in all the browsers.
I feel every day that I’m getting closer to my utopia for web development and it’s likely LiveView will not be in that future but the similar idea applied to sharing state to the front end via live-state might certainly be.
In any event I will be publishing my learnings with some documented starter projects based on my explorations for others to follow.
