🗺 Remix on Router v6.4

[ryanflorence]

🚧 Project Board

Updating Remix's React Router dependency to v6.4, which includes all data loading, mutations, error handling, rendering etc., but does not include streaming/deferred (that's in a different issue).

It also includes all the new APIs like useRevalidator, simplified fetcher objects, stable route shouldRevalidate, etc.

Decision Doc

https://github.com/remix-run/remix/blob/main/decisions/0007-remix-on-react-router-6-4-0.md

This is being done in a multi-step process to keep risk low and allow for incremental merged/deployments and avoid a single big-bang release (blog post here). Therefore we'll have a few experimental and prereleases covering different aspects of the decision doc.

Progress

• RFC n/a
• Prerelease
  • Server Data Loading - 0.0.0-experimental-5b4bceda6
  • Server Rendering + Client Hydration - 0.0.0-experimental-b3829ed22
• Enabled on dev branch

Issues/PRs

#4245 #4359 #4385

[kiliman]

@laurencefass Remix has always used React Router 6. They built all the data loading functionality separately. Now that they moved that functionality to RR 6.4+, they are updating Remix to use those APIs instead. So Remix will be more of a server implementation of React~~ Remix Router. Remix Router is the platform-agnostic version of React Router since routing is not intrinsically tied to React. They've already built a Vue version, etc.

[laurencefass]

Thank you. Does that mean that we will see react-router as a package json import in the future?

[sergiodxa]

@laurencefass it has always been on the package.json, you're just checking the incorrect one, here's imported

remix/packages/remix-react/package.json

Line 20 in 8f7100b

"react-router-dom": "6.3.0"

As you can see, right now is locked to v6.3.0, after the release of Remix they released Remix Router which is a framework agnostic router, and then made React Router v6.4.0 use Remix Router.

After the work on this issue is completed Remix will be using React Router v6.4

[sergiodxa]

Will this (eventually) provide Suspense boundaries for server fetched/rendered components?

If you're using React v18 you can use Suspense on SSR, but Remix doesn't support React Server Components so if you add any data-fetching inside your components that will happen in the client too.

But you can use Suspense to lazy-load components based on data you fetched on your loader.

Also, it's generally better to keep data fetching at the route level, since that will help you avoid waterfall of requests, if you used RSC and fetch on render, you should have to prefetch all the data somewhere (like at the route level 😉) anyway to prevent the waterfall.

When #4486 is added to Remix (which is tied to this issue) you'll be able to start fetching data on your loaders but send a response immediately without waiting for the data, then use Suspense to render a fallback UI until that part of data is ready.

[ryanflorence]

Just FYI, we're locking this and all roadmap issues. Our team needs to communicate with each other on these issues so we need to keep the good-but-off-topic comments out of them.

We are happy to answer questions in the discussions tab and discord!

[brophdawg11]

This is merged to dev and available in 0.0.0-experimental-b3829ed22. Should have a 1.10.0 prerelease out tomorrow