superchris
Supporting Web Components in LiveView
Hello! After seeing a couple of posts from Chris and Jose about supporting web components in LiveView, I thought it would be great to initiate a conversation about what this means and how to do it. This is a subject that is near and dear to my heart, and one I’ve tried to approach with a library called LiveElements: GitHub - launchscout/live_elements: A library to make custom elements and LiveView so happy together · GitHub. In a nutshell, LiveElements facilitates custom elements integrating with LiveView by declaratively creating LiveView functional component wrappers for custom elements. To a developer this makes custom elements “quack” like any other LV functional component. If any of this library is interesting a starting point, I’d be more than happy to work on whatever integration strategy makes sense. If starting over from scratch makes more sense, I’d be happy to help with that too.
First tho, it probably makes sense to talk about what supporting web components might mean. Here are some thoughts based on experience. To best support web components (custom elements specifically) it’s been helpful to:
- Handle custom events dispatched from custom elements in
handle_eventcallbacks in LiveView - Pass more complex data types into custom elements from LiveView
- create functional component wrappers to handle the above
LiveElements handles all this, so might be useful as a starting point if these features are desired. But I’d love to hear more about if these are the right features, or if not, what is! Very excited the LiveView team is moving forward on this topic ![]()
Most Liked
felix-starman
Regarding having a reliable interface, it would seem that having an “ideal” collaborative web component library in mind would be helpful.
From some of the comments I’ve seen on repos for those libraries, they were not interested in considering SSR (which is fair, LV is unique) , and you had to know how it worked before you could effectively wrap it reliably.
I’ve read up and really like zag-js’ approach of modeling the web component as a state machine and providing consistent, declarative ways to interface with it, where integrating with a lot of other libraries had felt very imperative and broke as soon as you needed to rebuild the web component to some state that the author only expected a user could get it into.
Popular in Proposals: Ideas
Other popular topics
Latest Phoenix Threads
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #hex
- #security









