I would love a Phoenix-powered React Server Components implementation, which would also be “live” as in LiveViews-live.

I experimented with something like that, by putting a Next.js server behind a Phoenix reverse-proxy. So basically a web request hits Phoenix, I use Ecto to load up the data, then use POST to send that data to Next.js handler, and stream the Next.js-generated response back to the client browser connected to Phoenix. This works and is pretty simple, in fact I was surprised how simple it is. But this is still running a Next.js server with all it’s bugs and issues it has, eventually I decided against actually pushing this forward in any way.

There’s a tiny library which I was going to try, but never did, that integrates LiveView with React: GitHub - fidr/phoenix_live_react: Render React.js components in Phoenix LiveView views · GitHub

As far as I understand, it doesn’t have any server-side rendering of React components, but you can somewhat build React Server Components-like behavior but also somewhat better with it using LiveViews.

The comopnents you mount this way will receive updated props from LiveView when it updates, and can send back events to LiveView.

What would be super cool is that these components could be pre-rendered, possibly using Bun or Node or some other JavaScript implementation and then hydrated. I believe that’s doable with something like you are suggesting.

I guess there are quite a few people around here using it in a similar way.

In our case, we use elixir / phoenix to provide a websocket based api for machines, as well as a basic web based UI for various native apps on a RaspberryPi. As long as you can control another process via a proper API, elixirs supervision trees are pretty awesome to manage and control all those dependencies.

Also, note that the LIveView state management and change tracking differs significantly in in principles from what React is doing. There are reasons for that, obviously, as avoiding re-rendering everything is somewhat more imporatant when the code sits on the server.

But another thing to try, would be to build something LiveView-like that is, however, using more React-style state management, for conceptual consistency if nothing else. Even if the code would be written in Elixir instead of JavaScript, having similar concepts of Hooks (as in useState) rather than implicit change tracking would be helpful and reduce the learning curve a lot.

Anyway, a lot of ideas, very little time to try them out.