Progressively migrating to LiveView from a React SPA

I recently came off a project with Ember, React, and LiveView all working simultaneously. Part of my job was to help the effort to finish converting the Ember stuff into LiveView so Ember could be dropped entirely. We did it like you said, in small chunks.

It is doable. I did not configure the parallel setup, so hard to give any firm recommendations. I recall we configured the React router to be the first opportunity to match a URL request/path, and then if none could be found we would then let the Phoenix router attempt to handle it.

One other idea/note is: you might want to (at least at first) build your LiveView to use the same GraphQL endpoint as the React experience used to make sure to maintain the domain/data layer as close as possible. In time you might replace that internal use with more traditional Phoenix business domain contexts.

Good luck.

Can’t help, but I’d love to do the same to an Angular app. And have no idea how to tackle this.

Interesting idea I hadn’t considered, thanks!

You can also go the other way round with GitHub - poteto/terraform: A simple plug for incrementally transforming an API into Phoenix. Check out the blog post: · GitHub

This tries to match a route in phoenix and otherwise falls back to a separate router, which you can use to call into whatever else you need.

I am in the middle of doing this. First step is to get your spa off of your hosting service and be served from Phoenix itself. You’ll also migrate all of your auth in the process. We are using auth0 and let me just say non-spa auth0 is way, way saner than spa auth0. (As an aside, especially for this, I recommend not using auth frameworks e.g. ueberauth – do it yourself with plugs so that you have a comprehensive understanding of what’s up)

For us this is a dashboard and there was a concerted effort to move to webcomponents a few months ago that was backburnered, so lv is an excuse to deploy that technology, and we’ll be hosting the lv at a /beta route that will present the same information as / and one day we just flip it over

@bismark I can ask how this ended up turning out for you, and whether you’ve got any advice to share?

I occasionally become interested in switching my side project app frontend from Vue to LiveView. However, the lack of open source front-end component libraries is what is stopping me. I currently use Vuetify and it is essentially unparalleled in terms of both variety and robustness of components (both stateless and stateful) as well as the sheer amount of dev effort that goes into it every single day. Attempting to create something similar by myself using LV components is unthinkable. I couldn’t even dream of doing it even if my side project was my full time job.

We actually use LV at my current job and having to create (and maintain/update) our own UI components is a huge hassle. It slows us down a lot, and I bet that holds true for many other dev teams as well (whether they realize it or not).

We migrated from angular to fully liveview by building specialized liveviews and mounting them using iframes since it was the same domain. Once we got to the point of having two liveview iframes on the same page, we usually just rewrote the page.

More recently there is live_state which could be an option for migrating your data layer while kicking the can on some of your more complex react components.

Comboboxes and multi-select drop-downs are the largest missing component of both html itself and the ecosystem for liveview right now. There are plenty of dropdown libraries that work perfectly fine, but they have subtle gotchas, not unlike react, but because your state is on the server by default, when writing livecomponents, it tends to make things more difficult.

I have not spent much time with web components, but it sounds like people have found great promise with shoelace, carbon and Adobe spectrum 2