💡 react-router (v6.4+) loader API with react-query

[cliffordfajardo]

🌕 The loader API for react-router is in pre-release state as this time

Hey RQ community!
I created this thread so folks can share solutions / ideas / questions when adopting react-router v6.4+ (the one with loaders API).
V6.4 may be particularly interesting update to all users of react-router, since it brings concepts from Remix (full React framework) to our client side rendered React apps.

Potentially this means, if you start adopting the newer react-router API's, it could significantly help you transition to adopting Remix, as Remix uses the v6.4 react-router APIs already.

Why this might be important to react-query users?

1. Most of us using react-query are also using `react-router
2. Some folks may have an interest in adopting Remix in the near future, which uses the same loader API
3. Even if you don't adopt Remix, the loaders API can help you avoid request waterfall chains, since its able to initiate in parallel all the API requests in app. (For more context see the video link below)

With that said, there isn't too much information about usingreact-query and the new react-router API together (pros/cons/best practices etc), hence the creation of this thread to bring awareness / spark conversations / get people cross linking and sharing resources.

New react-router loader API Summary

The new react-router loader API allows you define a "loader" function to provide data to the route element before it renders.

// https://beta.reactrouter.com/en/remixing/route/loader
// 🚧 This feature only works if using `DataBrowserRouter`
<DataBrowserRouter>
  <Route
    element={<Teams />}
    path="teams"
    loader={async () => {
      return fakeDb.from("teams").select("*");
    }}
  >
    <Route
      element={<Team />}
      path=":teamId"
      loader={async ({ params }) => {
        return fetch(`/api/teams/${params.teamId}.json`);
      }}
    />
  </Route>
</DataBrowserRouter>

Example create-react-app
I created a simple create-react-app showing the loader API.
Im going to continue playing around with new loader API more and reporting back here.

• https://github.com/cliffordfajardo/react-query-with-react-router-loader
  

References

• Example create-react-app using react-query with new loader API
• Remixing React Router blog post
• YouTube - Ryan Florence talking about react-router loader API
• Beta React Router docs
• Twitter Discussion thread that sparked this Github Discussion

Tangential Aside: My teammates & I we are ecstatic about Remix for a few reason(s):

• Working in a fullstack typescript based React stack for our web UI
  • no context switching between languages
  • use the web platform / APIs for both the UI and frontend web server
• If you're using react-router the same react-router API is used in Remix
• Remix allows us to SSR our app easily
• Remix as a framework has lots of good conventions, which result in out of the box "gaurd rails" on the developer experience, performance and user experience side

[ryanflorence]

I'll edit this answer more later, don't have much time, but wanted to quickly communicate my thoughts. I've had RQ in mind the whole time while we did this work. Admittedly, I've never used RQ in earnest, so I don't know the intricacies of it's behavior like background fetching, etc.

For React Router, the general abstraction is about three things: initiating, mutating, and reading. It maps to React Router like so:

loader -> initiate
action -> mutate
component -> read

React Router's behavior is pretty simple to explain (though pretty intricate in the implementation)

• Location changes
• New/changing loaders for the next location are called and awaited before changing screens
• Once all loaders are done, the page changes over to the new location

Next, when an action is called from a form or imperative submission:

• the leaf route action is called and awaited
• the loaders on the page will be revalidated and awaited
• the screen updates once all of them are done

Along the way, Remix keeps track of loading and error states.

For React Query (with my limited experience with it) I think it looks like this:

loader -> fetchQuery (need to await it)
action -> invalidateQueries
component -> useQuery

I don't know if fetchQuery throws on errors or catches and returns. If it returns the error, you'll want to throw it in the loader.

There is nothing magic about useLoaderData, it doesn't do anything, it simply provides what was returned from the loader. In this case it's irrelevant because what you want is inside of RQ's cache not React Router's state.

That's pretty much it!

[cliffordfajardo]

Thanks @ryanflorence

For React Query (with my limited experience with it) I think it looks like this:
loader -> fetchQuery (need to await it)
action -> invalidateQueries
component -> useQuery

Yeah, this looks like it works 🙌

---

I noticed in the loader function examples from the docs, we are not using await keyword; is this because the loader is fetch API aware and does the unwrapping of the data for us?

// https://beta.reactrouter.com/en/remixing/route/loader
// 🚧 This feature only works if using `DataBrowserRouter`
<DataBrowserRouter>
  <Route
    element={<Teams />}
    path="teams"
    loader={async () => {
      //❓ no await here, so will react-router call just check if the promise's state is resolved?
      return fakeDb.from("teams").select("*");
    }}
  >
    <Route
      element={<Team />}
      path=":teamId"
      loader={async ({ params }) => {
        // ❓under the hood is the loader,  `fetch` API-aware to unwrap the `.json` data?
        return fetch(`/api/teams/${params.teamId}.json`);
      }}
    />
  </Route>
</DataBrowserRouter>

CC @TkDodo @aaronksaunders @Temzasse - thought you might be curious too 😄

[ryanflorence]

Just have to return a promise, that's all. React Router is aware of web fetch Response objects, so yes, you can simply return a fetch and it'll unwrap it, or just return whatever you want.

// aware of responses, will unwrap with .json()
return new Response("hey!");

// fetch returns one of those, so it's kinda slick
return fetch("...");

// but really just return whatever you want
return { whatever: "you want" };

// it should be a promise that doesn't resolve until your data resolves:
return fetchQuery(...);
// not
return prefetchQuery(...);

[TkDodo]

As Ryan mentioned in his talk, if you're already using react-query, the loader api from react-router gives you a great place to start prefetching. Off the top of my head, there are two things I would keep an eye on:

• queryClient.fetchQuery returns a Promise with data and throws errors,queryClient.prefetchQuery also returns a Promise, but it doesn't contain data (Promise<void>) and it doesn't throw errors. Otherwise, they are the same (prefetchQuery calls fetchQuery internally). So if you want to use useLoaderData to read data for some reason over useQuery, you would need fetchQuery. If the loader expects an error to be thrown for error handling - also fetchQuery.
• I would strongly consider passing a staleTime to fetchQuery / prefetchQuery in the loader to avoid unnecessary calls to the queryFn if the data is still considered fresh. An underused tool is also queryClient.setQueryDefaults(['todos'], { staleTime: 10000 }), because it will set the default for this key (fuzzily) for wherever it is used.

[cliffordfajardo]

TK Dodo published some "work in progress" example code here using react-router 6.4+ with react-query ✨

• WIP Code: Feature/rr example #4058
• Tweet: https://twitter.com/TkDodo/status/1560971584642420736

[TkDodo]

I've merged the example and written a blogpost about it:

• https://tkdodo.eu/blog/react-query-meets-react-router
• https://tanstack.com/query/v4/docs/examples/react/react-router

[TkDodo]

I'm not sure what you mean exactly. Please show a reproduction of your problem.

[frassinier]

My question was mainly about "Are these changes to use loader/action mandatory or convenient reasons only?".

I can't reproduce except on specific env but I can see sometimes the Axios query being processed and when I output data in useInfiniteQuery select() or onSuccess(), the value comes from the cache and differs from what Axios got, so I was wondering if it can be related to ReactRouter v6 and the way it's recommended to use loader and action.

[TkDodo]

"Are these changes to use loader/action mandatory or convenient reasons only?

loaders are an optional feature that was added in React Router 6.4. You don't "have to" use it.

[kevinpruett-prime]

@TkDodo I'm not sure if this question is appropriate here, but I am curious about the techniques you've outlined above. Specifically, why do you prefer to use useQuery in the component as opposed to useLoaderData?

Perhaps I'm misunderstanding react router's loaders/useLoaderData but could you explain the reason for opting for useQuery instead of useLoaderData when the loader could pass the data through and could be consumed with the userLoaderData hook?

Also, do you recommend a good pattern for error handling throughout this lifecycle? (e.g. If a query fails within the loader definition, what should you return? should you throw immediately in the loader or somehow pass this through to your component?)

Thanks

[TkDodo]

why do you prefer to use useQuery in the component as opposed to useLoaderData?

because it will give you data synchronization and background refetches instead of just getting data from the loader once: https://tkdodo.eu/blog/react-query-meets-react-router