GabrielWilliamson

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

Showing Posts 1 to 10

krasenyp

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

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

krasenyp

Wouldn’t call it a bliss but it’s good enough. I say it as a veteran front-ender.

DaAnalyst

DaAnalyst

It’s a bliss compared to Alpine (and its integration with LiveView)

kokolegorille

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

DaAnalyst

What exactly do you mean by this? We’re primarily using web components because they can manage their state.

kokolegorille

kokolegorille

I meant communication inter web components… sorry, not state management, but components communications

DaAnalyst

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:

  • parent → children: custom event on window with the children listening
  • child → parent: el.closest( ‘my-parent-web-component’).gimmeWhatIWant() // way faster than custom events

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

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

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.

— All posts loaded —

Where Next? Top

Trending in Blog Posts Top

pckrishnadas88
Hey everyone! :waving_hand: I’ve published Part 7 of the Building Distributed Systems in Elixir series, where we build core distributed ...
New
mudasobwa
So, instead of wasting my afternoon arguing with anonymous handles on X, I turned to my trusty, soulless assistant and said: “Listen, ple...
New
abreujp
New article: Elixir Project Structure — From mix new to a Growing Codebase I’ve published a new article in my Elixir learning series on d...
New
zorn
An educational side project in Elixir, Phoenix, and Tauri. I share what I learned while wiring Automerge into the BEAM, including how I s...
New
jola
Wrote about how to safely run a globally unique process in an Elixir cluster, and a scary story from the past! Learn about :global for r...
New
jola
The way Phoenix is set up adding a CDN sub-domain for serving static assets, without worrying about the main dynamic content, is incredib...
New
UlfAnger
What happens when an AI agent reaches its limit because the required tool isn’t in its catalog? Normally, you get a polite refusal. I wa...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews