Please clarify (again) the future of Remix and React Router and how they will interact

[benjamindulau]

First of all, well done for the fantastic work on both Remix and React Router. The data loading and mutating features are a breeze and very liberating.

But that being said, we are desperate to get some clarification about the future of all that. The teasing is killing us 🙃

Let me add some context so maybe some can identify....

Early this year we decided to rethink entirely how we develop and organise our frontend applications with two major objectives in mind: rock the socks of core web vitals and offer the best UX possible while drastically improving developer experience so we keep our developers happy and proud of their work and productivity.

While working on this we stumbled upon the awesome Dan's post about the future of SSR and Progressive Enhancement with Server Component and data streaming. That's the one reactwg/react-18#37

That blew our mind and we thought "We want that! How can we anticipate this in our new approach so we can easily and gradually adopt it?"

Then some time later we watched Ryan's talk at
React Hackathon "When to fetch...Remixing React Router" and we thought "That's it, that's our way in! React Router".

For now we strategically decided to take one page of the website, a big one, full-featured, and use it as a sandbox to validate all this new stuff client-side only, so with our new architecture and React Router >= 6.4 with loaders, actions and all the new exciting features. So far so good, we're really happy with it.

So next subject for the first trimester of 2023: SSR. And that's where all gets blurry 😵‍💫

We think that the best UX we can offer is by moving all the complexity we can server side because performances will be way better and way more consistent.

So our goals are:

1. First render from server with "awaited" data feature
2. Then stream remaining data progressively to the client thanks to "suspensed" components.
3. Then all further user interactions in the rendered "page" that need loaders or actions are handled client-side by React Router
4. If the users navigate outside of the page, back to 1.

That means:

1. We need a full featured backend with stateful session management, a security layer, routing, rendering react components, etc which will be deployed somewhere. That's Remix right?
2. We need React Router client side after hydration so it can handle all subsequent interactions inside the rendered page.

But! How will Remix and React Router interact there? Wouldn't some loaders overlap? How to generate routes that navigate client side and routes that call the server?

Say we have modals on our page. To feel natural in terms of navigation, these modals have their own routes and loaders (and possibly mutations).

So 2 possible scenarios here:

1. The user visits the main page (no modals open). The server initiates fetches and renders the page. React hydrates on the client side. Suspense components wait for data streamed by the server. Then the user clicks somewhere that opens a modal. React Router navigates (client-side) to the modal route, initiates load by calling the route loader, modal renders, user is happy.
2. The user visits directly the modal's URL. What we would except is that in that case the server initiates the fetches by calling both page (parent route) and modal (child route) loaders in parallel. Then it renders the page as soon as the awaited fetches are resolved with the modal open which has a Suspense component waiting for data from the server for its own loader.

So the modal loader is shared between the server and the client. Won't the loaders overlap in scenario 2? As soon as the server renders the page with the modal component, won't React Router initiates a new fetch since a loader is configured for the modal's route even though it already has been called by the server? Which would be counter-productive.

Will the client hydration be that smart so this scenario will be handled intelligently and seamlessly?

Or maybe that's what Server Components are all about? So it's not just the first render that is streamed to the client so nothing is done client-side, and the client router just asks the server to do some more fetches and renders and all is streamed to the client without reloading the browser?

More generally, I think the frontier between client & SSR is becoming so thin that it's hard to understand how server and client will interact. And we really are trying to understand where you're going with Remix and React Router so we can anticipate.

We know that's all of this is WIP and we need to be patient. But as early adopters, to mitigate the risk for our business and our team, we need to have a plan so we can anticipate what's coming next.

Can you please clarify (again, sorry) more precisely what you have in mind for the future of Remix and React Router?

We read all the blog posts, a lot of discussions, but we still are not sure what you have in mind exactly. Sometimes we understand that you move things back and forth to finally merge everything into one ring to rule them all (Remix?). But sometimes we are not sure anymore...and we feel that maybe React Router and Remix will continue to live separately but intimately...

What's the truth? Are the kind of use cases I've described above something you have in mind? (I think I know the answer to that)