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.

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