GabrielWilliamson
Hi, after experimenting a bit, I wrote a short article and did a mini-demo of an approach I find interesting: a combination of tools like React and Phoenix. I’d like to know your opinion on this approach. Thanks.
https://gabrielwilliamson.com/posts/using-react-components-in-phoenix-live-view
Trending in Blog Posts
The code in this post is Erlang, but it all applies to Elixir binaries just the same: how appends, match contexts and sub-binaries behave...
New
eMudhra’s leaked CA keys reached my Phoenix app through 2 trust stores, and my first redeploy patched neither. How I fixed the OS bundle ...
New
A deploy killed my OTP processes but not the containers running my AI agents. That mismatch kept a kanban card “executing” for eighteen h...
New
My first real blog post is up! Got five minutes? Come break some stuff. I put five demos in it, and they’re meant to be played with. Kill...
New
Following up on Making `dns_erlang` fast: binary tricks for the BEAM, there’s our second post in our series on making erldns, an authorit...
New
A small quality-of-life improvement to my blog that makes it easier to keep technical posts up to date with a revision history.
https://...
New
Wrote a post about how I set up HTML email templates in Phoenix using the template renderer with Gettext and verified routes, CSS inlinin...
New
Other Trending Topics
Hey there,
I haven’t seen a list of useful Elixir specific skills for the popular AI tools yet so I’m starting one here with my first.
...
New
Hi everyone :waving_hand:
I wanted to share something I’ve been building — NowBlind, a random chat app designed to help people discover ...
New
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
(I just needed to vent somewhere and LinkedIn is full of hope, or hype, I’m not sure which exactly)
AI dream has many faces, but general...
New
Localize is the next generation localisation library for Elixir. Think of it as ex_cldr version 3.0. The first version will be released ...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #elixirconf-us
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #performance










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
krasenyp
Good exploration but a better approach, in my opinion, is using a web component. It can be integrated with LiveView better and also forms and so on. Nowadays there’s a myriad of browser APIs which are easy to use from a web component.
DaAnalyst
Absolutely! Web components + Lit (+ a couple of extra directives) and there’s nothing you can’t do.
We’ve just started switching from Alpine to web components and it’s a bliss!
krasenyp
Wouldn’t call it a bliss but it’s good enough. I say it as a veteran front-ender.
DaAnalyst
It’s a bliss compared to Alpine (and its integration with LiveView)
kokolegorille
I have written web component, with React…
I am not sure they address the same problem, and they are not mutually exclusive.
State management is something I miss with web components.
DaAnalyst
What exactly do you mean by this? We’re primarily using web components because they can manage their state.
kokolegorille
I meant communication inter web components… sorry, not state management, but components communications
DaAnalyst
I see.
As a general pattern they promote parent → child communication via properties and child to parent via custom events. However, the former is only applicable when the composition is done within the web components themselves.
In our case (LiveView, where composition is achieved with LiveComponents) my take is the communication between web components need to be designed differently. First, if LiveView is the source of ultimate/eventual truth for the state that is also present server-side, for that part the rendering (or push_event) should have the last say at all levels of nesting. As for a pure client-side state and the communication thereof, the pattern is more like this:
The principal difference is in the underlying intent. Generally, web components are meant to be reusable, universal and isolated which is why they promote loose coupling. In our case with LiveView, where we use web components within a predetermined DOM hierarchy within which they role is to implement the client-side state and behavior, we only need resort to events so we can benefit from their mechanics and no longer to promote a loose coupling (unless, of course, a particular web component is truly generic).
kokolegorille
At the time the recommended solution was to use an event bus.
But my use case was a rich video player…
Liveview manage props, but all the rest is client side.
I wrote a web component for portability, hiding a react interface. That is why I wanted to say it’s not exclusive.
The bonus, it’s also standalone and can use Phoenix channels, it does not need to be hosted on a Phoenix server.
DaAnalyst
The “event bus” is merely a wrapper for dispatching custom events. If performance is a concern and you only need to notify or fetch data from a single specific web component it’s almost always better to do it directly, especially if there’s no need for loose coupling (e.g. when a child knows upfront what class/web component is its target parent). But you can do it whatever way it best suits your needs.