🗺 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 coming soon!). Therefore we'll have a few experimental and prereleases covering different aspects of the decision doc.

Progress

• [x] RFC n/a
• [ ] Prerelease
  • [x] Server Data Loading - v0.0.0-experimental-96f235c51
  • [ ] Server Rendering + Client Hydration
• [ ] Enabled on dev branch

Issues/PRs

#4245 #4359

Testing Notes

Warning

PLEASE READ THIS IF YOU INTEND TO TEST THIS EXPERIMENTAL RELEASE

This release is for our own testing to ensure that the old and new code flows work exactly the same. Therefore, this experimental release will run both the current remix flow and the new @remix-run/router-based flow and assert the responses against one another. This means your loader/action functions will execute twice for a given request. Please keep that in mind and don't go running this experimental release against any important production data sources (mostly referring to duplicate mutations here).

There are 2 things to keep an eye out for when running your application on this experimental release:

1. Keep an eye on your server log for messages like Returning Remix Router Document Request Response and Returning Remix Router Data Request Response - that means you're actually receiving responses generated by the new flow 👍
2. Keep an eye on any server logs of the format Headers did not match! or JSON response body did not match! or Non-JSON response body did not match! etc. Those mean that the current Remix flow and the new flow resulted in different Response objects so we'll want to dig into what was different. If you run into these, any information or a simplified reproduction would be super useful.

Note

If during your testing you need to know which request is from the old and which is from the new flow, we're temporarily setting an X-Remix-Router-Request: yes header on the request sent to your loader/action in the new flow. You can use this to avoid duplicating DB mutations if needed - but you will need to ensure that both actions return the same exact response otherwise the built-in assertions will fail.

[jaschaio]

Pretty sad about this as it basically means remix won't support useBlocker and usePrompt any longer. This is a very controversial discussion over here: https://github.com/remix-run/react-router/issues/8139#issuecomment-1262630360

[ryanflorence]

Doesn’t mean that at all (and it never supported those APIs, it’s been on router v6 the whole time), but let’s keep that discussion over there :)

[laurencefass]

With streaming soon to be a feature can you include guidelines on when and how to use client side fetching vs server side fetching/streaming. With Next JS team promoting server side fetch/stream in their latest apps folder beta release it will be interesting to read the Remix take on this.

[laurencefass]

Please can you clarify Remixes relationship with React Router. Ive read a few articles about merging Remix and Router and was expecting Remix to be using a version of react router, but according to latest package.json Remix is not dependent upon any version of react router. https://github.com/remix-run/remix/blob/main/package.json. Is remix currently using its own bespoke router?

[machour]

@laurencefass Remix is currently being rewritten on top of react-router 6.4. That work is not released yet.

[laurencefass]

Just to confirm: Remix is (gradually) moving from a bespoke router to ^react-router-6 with server side fetch support? Is that a reasonable summary?

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

[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 https://github.com/remix-run/remix/blob/8f7100b2d5c40d5b2f0856958898cab70ef9d407/packages/remix-react/package.json#L20

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