blog/react-query-meets-react-router

[giscus[bot]]

blog/react-query-meets-react-router

React Query and React Router are a match made in heaven.

https://tkdodo.eu/blog/react-query-meets-react-router

[geraldodev]

From this article can I suppose that the specific features you showed about react router are not going to be implemented on react location ?

[TkDodo]

react-location also has loaders, I think the same concepts would apply there.

[tannerlinsley]

React Location works exactly the same way today when it comes to loaders, but RL doesn't have actions yet, so you have to invalidate your queries wherever you are doing your mutations. React Location will soon become TanStack Router and get some hefty upgrades. It will at the very least have some kind of "actions" API so the same concepts will apply there as they do here.

[jmamadeu]

Great article, love your blog and work.

[charliematters]

As always, I love your work and it's much neater than my solution to the problem. One thing I ran into (and I don't see addressed here) is the errorComponent prop in react router. If the loader fails (or anything else in the route I think) then it displays the error component. In your example it looks like we'd need almost-duplicated code for the standard react-query error case in the component and then the react-router error component. Is there some clean way round that?

[TkDodo]

if you set useErrorBoundary: true, react-query will throw errors to the nearest error boundary, which would be the errorComponent from the router. That way, you can avoid having to handle errors in the components, so if a background refetch errors, you would also get the error boundary shown. Or, you can use the global cache callbacks to show an error toast for example. I'm going into some examples here: https://tkdodo.eu/blog/react-query-error-handling

[charliematters]

useErrorBoundary is exactly what I need - I thought I was going to have to use suspense or some extra error component. Thanks very much!

[luzat]

@TkDodo I guess one can then use useQueryErrorResetBoundary() within the errorElement?

I am not really sure how one would implement a "retry loading this route" if the error might happen within either the loader or within the component's useQuery. I am thinking of something like this within errorElement:

const navigate = useNavigate()
const reset = useQueryErrorResetBoundary()
const retryHandler = () => {
reset()
navigate(0)
}

return <button onClick={retryHandler}>Try reloading</button>

[TkDodo]

not sure how route error handlers are setup, but yes, if the error boundary is rendered by react-router, you'd need to reset the boundary first, and then re-trigger the loader.

[pmioduszewski]

I love the content on your blog

[OlegLustenko]

What do I like about this approach in general, that we dropped hard dependency on React and mixing separation of concers like: hooks + API + Render phase

[EfstathiadisD]

I am wondering, with this kind of setup, would you recommend using the route as the QueryKey? I think v3 supported that. Does v4 do that as well?

[EfstathiadisD]

To add a couple more points. I think it would be amazing, if we could somehow extract the routes object that Remix has. (Think it's possible, but not sure, need to look), then create an Array, which would also be typed. Since, we can do something like:

type AppRoutes = typeof Routes[number];

const Routes = ["/dashboard", "dashboard/page1", "dashboard/page2"] as const;

The a simple function, that overrides the QueryKey with a custom query-key.d.ts definition file localised in each module would allow us to extract that information to something like:

const fetchPage1 = () => ({
  queryKey: makeQueryKey("dashboard", "page1"), <-- This could be inference either with a complicated type or function overloading. and would produce ["dashboard", "page1"].
  queryFn: getPage1,
})

I would like to know what do you think about it. In general, this comes from the big issue I see everywhere with QueryKeys. It's complicated, it's convoluted and it always results in apps breaking due to wrong keys.

[TkDodo]

you can of course create the query key by reading the current route from the url :)

[alexo382]

Great article! How would this work with Apollo, for example? Tricky to wrap my head around it 😅

[TkDodo]

I don't know because I don't know apollo very well 😅

[tienlx97]

react router beta also have suspense and skeleton. Should I use of react-router or still implement by using react query

[TkDodo]

can you show or link to an example?

[tienlx97]

This is react-router-beta with suspense. They said:

Use defer data so the UI flips over to the next screen with placeholder UI immediately while the data loads.

[reintroducing]

Great article. Heads up that the link to the tutorial in the first paragraph is a 404. It should link to https://beta.reactrouter.com/en/dev/start/tutorial instead.

[TkDodo]

Thanks, seems like it was moved. Do you want to open a PR?

[reintroducing]

Thanks, seems like it was moved. Do you want to open a PR?

I certainly can, I'm just not quite sure where the code lives to open the PR against.

[TkDodo]

i have updated it already :)

[TkDodo]

for the future, code is open source here:
https://github.com/TkDodo/blog

[reintroducing]

@TkDodo Ah, gotcha, thank you!

[tienlx97]

Suppose in contactLoader the function take too slow, how do I show loading spinner in the route

[tienlx97]

@TkDodo I thinkl useNavigation is used for the root route, not for each route. Ex: In contact page I want spinner, edit page I want skeleton.

[charliematters]

This sounds like it might be what you need? https://reactrouter.com/en/main/guides/deferred

[tienlx97]

@charliematters yah, I use deferred too, but the problem is I can not use it with useQuery.
Ex:

const blogQuery = (slug?: string) => ({
  queryKey: blogKeys.detail(slug),
  queryFn: async () => fetchBlogBy(slug)
})

type DeferBlogLoader = {
  blog: Promise<BlogQuery | undefined>
}

// return type is Promise<DeferedData>
const loader = (queryClient: QueryClient) => async ({ params }: LoaderFunctionArgs) => {
  const query = blogQuery(params.slug)
  // ⬇️ return data or fetch it
  const data = (queryClient.getQueryData<BlogQuery>(query.queryKey)
    ? Promise.resolve(queryClient.getQueryData<BlogQuery>(query.queryKey))
    : (queryClient.fetchQuery(query))
  )
  return defer({
    blog: data
  })
}

In react component:

const { blog: blogInfo } = useLoaderData() as DeferBlogLoader;

/* What I want is: 
const initialData = useLoaderData() as Awaited<ReturnType<ReturnType<typeof blogLoader>>>;
const { data: blogInfo } = useQuery({
  ...blogQuery(slug),
  initialData,
});
*/

return (
    <React.Suspense fallback={<BlogHeaderSkeleton />}>
      <Await resolve={blogInfo} children={blg => <BlogHeader blog={blg} />} />
    </React.Suspense>
  );

If only use queryClient.fetchQuery without using useQuery. It will not create observer so when change data in cache(prefetch), it will not change data in react comp

[charliematters]

If I had this problem (i.e. I couldn't speed up the slow thing), I'd probably start with something like const [ blog, hasTimedOut ] = await Promise.race([fetchBlogBy(slug), sleep(1000)]) and then handle the timed out case myself? Not sure that's the best advice though - I've never had to handle this sort of case I'm afraid!

[TkDodo]

If only use queryClient.fetchQuery without using useQuery. It will not create observer so when change data in cache(prefetch), it will not change data in react comp

In the BlogHeader component, you would then want to call useQuery and potentially pass the blg prop as initialData as shown in the TypeScript tip section of the article. This will create the subscription and also give you the prefetched data from the route.

[arthtyagi]

Hey, I seem to be getting a TypeError with this approach. Any thoughts on how I might work around that?
I've detailed it more with code over here - remix-run/react-router#9268

[arthtyagi]

Oops, nevermind. I fixed it by returning the () => Promise<{} | null> type.

[liaoliao666]

Recently I wrote a library called react-query-kit that aims to create the query in a typesafe way and be simple to use.

import { createQuery } from 'react-query-kit'
import { getContact } from '../contacts'

type Contact = { ... }
type Id = number
// ⬇️ define your query
const useContactDetailQuery = createQuery<Contact, Id>({
  primaryKey: 'contacts-detail',
  queryFn: async ({ queryKey: [_primaryKey, id] }) => getContact(id),
})

// ⬇️ needs access to queryClient
export const loader =
  (queryClient) =>
  async ({ params }) => {
    const queryKey = useContactDetailQuery.getKey(params.contactId)
    // ⬇️ return data or fetch it
    return (
      queryClient.getQueryData(queryKey) ??
      (await queryClient.fetchQuery(queryKey, useContactDetailQuery.queryFn))
    )
  }

export default function Contact() {
  const params = useParams()
  // ⬇️ useQuery as per usual
  const { data: contact } = useContactDetailQuery({ variables: params.contactId })
  // render some jsx
}

// invalidateQueries examples
queryClient.invalidateQueries(useContactDetailQuery.getKey())

[tienlx97]

Suppose I have data saved in context api. So how can I get data context api in loader function.
i.e: After login I saved data in context. I must get user id to do something.

[TkDodo]

reading from context is synchronous so there is on need to do that in a loader 🤔

[tienlx97]

@TkDodo here is may example . I can not call context api in loader function

[TkDodo]

Yes because loader is not a hook. You'd need to read the value in the component, then pass it to the loader as a prop, similar to how I'm doing it with the queryClient.

[chentselee]

I follow the above example and are seeing two fetch requests for the initial page load (subsequent request only fired once).

Do you have any insight on how could this be solved? Thanks for the guide

[TkDodo]

you don't have a staleTime set like in the example :)

[chentselee]

Oh! Could have swear i did that at times and it did not work..weird.😅 Now i can start migrating our code to use this pattern. Thanks!

[chentselee]

Did some further testing. The double fetches problems starts to occur when the staleTime is set to be below 15. I was setting that to 10. For people who are stuck on this twicking around the staleTime might help.

[TkDodo]

this likely indicates that in your situation, it takes more than 10 milliseconds from when the entry is added to the cache to when the component is rendered and useQuery picks it up.

That is quite reasonable. If you set a staleTime, do something in the "seconds" range, not millis 😅

[chentselee]

Good to know. Thanks for the explanation!

[ChazAshley]

Hello, I wonder what would await updateContact(params.contactId, updates) do inside its body?
The route actions are supposed to be called when we want to mutate the data, so I assume we should use the useMutation hook, but it doesn't seem that we can use hooks inside an action.

[charliematters]

The action is called when the form is submitted. No use of useMutation. This might be helpful? https://reactrouter.com/en/main/route/action

[mykolamo]

Yep, but if we already have react-query used in the project, aren't we supposed to use useMutation when we want to mutate some data?
Or maybe in this case, we should simply replace usage of useMutation with actions of the route, and only use queries part of the react-query lib?
Route's actions and useMutation of react-query seem to be connected to the same thing, but they do it in different ways and in different places, useMutation inside of the component and actions outside of the component. So should we use only 1 feature when we want to mutate some data, or we can use both approaches?

[charliematters]

I'm with you - I guess you can choose how much react-router you use vs react-router. The only thing that's worth making sure is that you call revalidate from useRevalidator in your useMutation methods just to keep react-router in sync with your changes

[john-smilga]

Just wondering.
If I run the query only in the loader, the data seems to be cached "forever", regardless of the staleTime value.
Is the only fix setting up the useQuery() in the component?

Thank you in advance.

App.jsx

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 1000 * 5,
    },
  },
});

Landing.jsx

const featuredProductsQuery = {
  queryKey: ['featuredProducts'],
  queryFn: () => customFetch(url),
};

export const loader = (queryClient) => async () => {
  const response = await queryClient.ensureQueryData(featuredProductsQuery);

  const products = response.data.data;
  return { products };
};

[TkDodo]

If I run the query only in the loader, the data seems to be cached "forever", regardless of the staleTime value.

if you only fetch in the loader but don't have an observer with useQuery, data will be cached for cacheTime time - so 5 minutes per default.

[john-smilga]

Thank you!

[igortas]

How this pattern can work with React for pages/routes that needs some fetching ahead of time or some dispatch actions, so u can eliminate at least some useEffect's?

I've tried refactoring some useEffect's and put the fetching code into routes loaders with queryClient.ensureQueryData.

Similar, for some routes that needed some simple actions for the store, I've put that code in the loaders too...

The end result was a bit problematic, with rerendering on first load (leaving some components not to be rerendered more than once, which some logic was left not executed, because queryClient.getQueryData was returning undefined on first render).

Even I've fixed somehow the first load and rerendering, later optimization with lazy loading components and navigating between routes, bring new problem, where loaders prevent me from opening some routes on button click , once again problem with rerendering...

I really like to know more what is the best practice to leverage this pattern.

[ak274]

I want to use loaders to fetch data from server before component renders and each API call has Bearer token attached to it, I'm using axios interceptors to intercept each call and attach token with request heeders.. But when the call is initiated by a loader the token is not getting attached to it. it seems like loader get call much early even before the interceptors invoked.

[TkDodo]

can't really say much about that, this seems react-router specific. I guess it would behave exactly the same if you just did a raw axios request inside a loader...

[ahmed-saber]

@ak274 It's working fine with me, that means your interceptors are running after the loaders

[ak274]

Can you share an example of how you have arranged your routes and how interceptors are set up?

[ahmed-saber]

It will be just an example but the implementation will be different based on your project

axios.interceptors.request.use(
  config => {
    config.headers['Authorization'] = `Bearer ${localStorage.getItem('access_token')}`;
        return config;
    },
    error => {
        return Promise.reject(error);
    }
);

[Arcades2]

Awesome article as always !

In your example of how you use initial data to get rid of the union "Contact | undefined" type for "data", I am wondering how you do that if you have a custom hook "useContact" ? Do we need to write an overload for this hook to have the same result as using "useQuery" directly ?

[Arcades2]

I have not tested but I think you are right. It should work as expected if using useLoaderData inside custom hook 👍 I was more thinking about this situation : https://codesandbox.io/s/prod-framework-9njsrq?file=/src/App.tsx . Here, data is still a union of Data | undefined even if I pass initialData as option. To make it work, i had to create overloads for the case where initialData is set.

I already saw some of your responses about how to implement the option select for custom hook in order the have the good type for data but I did not find similar questions about initialData. Is there a way to handle this case ? or maybe I am doing something against how I should normally use react-query ?

[TkDodo]

no, you'd need overloads for that. in v5, I'd recommend sharing queryOptions and passing them to useQuery directly: https://codesandbox.io/p/sandbox/objective-star-g35t8p?file=/src/App.tsx:41,1

[Arcades2]

Yeah I also found that strategy but I wanted to try to find a solution where I could use custom hooks. Would you recommend that way of doing things globally (exporting queryOptions and use useQuery every time) or custom hooks have still some advantages ?

Thanks in any case 👍

[TkDodo]

custom hooks still have the advantage if you want to couple them with other hooks, like useParams or useMemo. If you don't use other hooks, abstracting with queryOptions can be enough.

[Arcades2]

I see, I see. Thank you for the clarification.

[gboycdw]

It's a very good technology. I'm using it well. However, this time, I encountered a problem.

export const myLoader = (queryClient: QueryClient) => {
  async({request: {url}} : ReqType) => {
    return await queryClient.ensureQueryData(queryKey, queryFn(url))
  }
}

I'm trying to use the loader of React Router DOM on a specific page, and I want to dynamically construct a queryFunction based on the page URL when accessing that page.

However, even though I'm changing the query string using a button and updating the URL, if I don't perform a direct refresh or if I click outside of the page, and then return, the queryFn that depends on the URL doesn't work as expected.

I tried using invalidateQueries, resetQueries and refetchQueries to solve this issue, but it didn't resolve the problem.

I've confirmed that the query string is changing and the component is re-rendering. I've also verified through console logs that it's accessing the loader accordingly. Additionally, the updated query string is being recognized within the loader function.

However, the queryFunction doesn't seem to respond to the updated URL (API calls are not triggered).
What am I overlooking here?

[charliematters]

A couple of points here: firstly, the issue doesn't mention anything to do with this discussion, so taken on its own, a screenshot is not very helpful.

Secondly, perhaps I'm missing something, but your loader looks like this:

export const MyLoader =
  (queryClient: QueryClient) =>
  async ({ request: { url } }: any) => {
  ...
    const oid = "1"; 
    if (url.split("?")[1]) {
     ...
      const data = await queryClient.ensureQueryData(
        QueryTesterApi(oid, url.split("?")[1]),
      );
   ...
      return data;
    }
...   
  return await queryClient.ensureQueryData(QueryTesterApi(oid));
  };

You're specifically setting your argument as "1" each time, and that's the only variable in your queryKey, so it will always fetch "1". What is it you are expecting to see?

[gboycdw]

The reason is that the current oid is a value unrelated to this issue. The reason it is not currently applied is because it is a dynamically fetched URL.

In the screenshot provided, the issue is not with the oid being 1, but rather with the fact that there is a query parameter, yet it continues to show 'no query.'

[charliematters]

and that's the only variable in your queryKey

If your query depends on the search params, then they need to be included in the queryKey
https://tanstack.com/query/v4/docs/react/guides/query-keys#if-your-query-function-depends-on-a-variable-include-it-in-your-query-key

[gboycdw]

const QueryTesterApi = (oid: string, queryString?: string) => ({
  queryKey: ["test", oid],
  queryFn: async () => {
    let url = `http://localhost:8080/api/${oid}`;
    if (queryString) url += `?${queryString}`;

    console.log(url);
    return await axios.get(url);
  },
});

My queryKey is Here!

The issue is simply that the query parameters, specifically "name=1" and "name=2," are not being reflected in the API call.

[gboycdw]

This issue has been resolved. Thank you for your response. It turns out that the dependency array of queryKey did not include queryString, which is why it wasn't being patched.

[EnesAbdulla]

If they are indeed "a match made in heaven", is it fair to expect there to be a sort of official collaboration through which we would have react-router coming with the benefits of react-query out-of-the-box?

Maybe, an API where you don't have to explicitly pass a QueryClient to the loader? Also, some other improvements in terms of abstraction could be possible. For example, in my opinion, having to use useQuery() for accessing the data in the component is bad abstraction; being able to access through useLoaderData() makes more semantic sense.

[TkDodo]

a match made in heaven

this is just a blogpost. I choose those words

sort of official collaboration through which we would have react-router coming with the benefits of react-query out-of-the-box?

Don't think so. Quoting Ryan again:

React Router is about when, data caching libs are about what.

TanStack Router will have a light-weight caching option built in, but it won't be the same as Query.

having to use useQuery() for accessing the data in the component is bad abstraction; being able to access through useLoaderData() makes more semantic sense.

useQuery is what creates the observer, which is what gives you all the data synchronization. Not possible without useQuery.

[EnesAbdulla]

Thank you for the response!

I mean if they go well together, which from the way you explained, it seems that they do, shouldn't there be an easier way to use them together? Right now, there is too much boilerplate.

Not possible without useQuery.

I only mentioned this provided the possibility of having a new API.

this is just a blogpost. I choose those words

I don't get why you said this. Helpful post and great choice of words throughout!

[nik-webdevelop]

@TkDodo thanks for this great guidelines. I have a question regarding types for queries with initialData:

Is this example

const initialData = useLoaderData() as Awaited<
    ReturnType<ReturnType<typeof loader>>
  >
  const params = useParams()
  const { data: contact } = useQuery({
    ...contactDetailQuery(params.contactId),
    initialData,
  })

basically equals to this?

  const params = useParams()
  const { data: contact } = useQuery({
    ...contactDetailQuery(params.contactId),
  }) as DefinedUseQueryResult<Contact>

And if so, then maybe it is worth to write some custom typings to infer query data as defined?

const { data } = useContactQuery();            // data: Contact | undefined
const { data ) = useContactQuery<'defined'>() // data: Contact

Invoking useLoaderData wherever useQuery is used (can be many times in route's child components) seems a bit repetitive.

I ques, we can put useLoaderData inside useContactQuery, but then each query will be calling useLoaderData (can be multiple queries in component). Another drawback would be inability to use useContactQuery without initialData.

Anyway, I would appreciate any tips and suggestion how to properly organize this stuff.

[TkDodo]

if you know data is alway in the cache, you can useSuspenseQuery in v5, because data will always be defined with it.

[snax4a]

Great article.
I wonder if it would be possible to call prefetch query inside loader without awaiting so we would not delay rendering of whole route tree, and In the child components we would use useQuery as always (handle loading states and errors)?

If we had multiple nested components having own queries on one page, and if we fetched all of these in the loader (with awaiting) it could slow down (delay) the initial route rendering. My idea is to just fire multiple prefetches in the loader to minimize the query waterfall.

Will it work correctly? I mean will the nested useQuery now that there is already pending fetch for that query and it’s loading time will be shorter compared to case when it would start fetching after initial render of that child component?

[TkDodo]

sure, you can fetch in the loader without awaiting and just not use initialData. useQuery will pick up the running promise anyhow, but you might get an in between loading state if the fetch takes longer, and data will be T | undefined

[jeeknowme]

This article is very wonderful. I just have this question. What about the loading part. If we use useQuery we have isPending, where we can use like making faded background on some component. When using ensureQuery, how can we achieve that (Thinking of using state (loading)). Also, just an additional question, what's the difference of using useQuery and ensureQuery

[jaf7]

Typo here:

"Update: As of v4.18.0, you can use the built-in queryClient.ensureQuery method to achieve the same thing."

Should be queryClient.ensureQueryData.

[TkDodo]

want to file a PR ?

https://github.com/tkdodo/blog

[tanjunior]

Reading this on 2024, what a great article even though it's almost 2 years old. Wondering if there is any improvement to be done now that react-query is on V5.
Also, I am still getting type errors on my initialData even though it has already been inferred with as Awaited<ReturnType<ReturnType<typeof loader>>

Edit: seems like returning the query as an object did the trick

export function loader(queryClient: QueryClient) {
  return async ({}: LoaderFunctionArgs) => {
    return {
        initialData: await queryClient.ensureQueryData(myQuery())
    }
  }
}

export function Component() {
  let {initialData} = useLoaderData() as Awaited<ReturnType<ReturnType<typeof loader>>>
  const {data} = useSuspenseQuery({
    ...myQuery(),
    initialData
  })
  return <div></div>
}

[xxronis]

Good stuff, I would love to use the best of both worlds.
Can I use react-router's defer() & <Await> with a set up like this? I'm facing some issues, useAsyncValue and suspense: true on queries not having the outcome I'm expecting.

I would like to keep all the when to the loader and the what in RQ and in my UI to use Await and useAsyncValue.
I'm ensureQuery in my loader and defer the response. For the awaited data its fine, not for the deferred data.

Seems to work but it is like I've set defer to await always, any advice would be much appreciated, thanks.

[xxronis]

https://codesandbox.io/p/devbox/react-vite-forked-m93vm8

Please run it in a new tab, seems I got some trouble with msw running there :) looks unstable.
Collaborations is the route im talking about, thanks

[TkDodo]

sorry, the sandbox doesn't really work and it's a lot of code to look into - I'm having trouble understanding what issue you're trying to solve. Judging from this comment:

// I would love to use ONLY useLoaderData() and stuff would also work

you can't only useLoaderData- you also need useQuery because that's what sets up the subscription to the QueryCache and makes sure your component re-renders when new data comes in.

[xxronis]

I only need to make defer() work as expected when loading this page.
Wait only for the critical data and defer the rest.

Sandbox looks fine to me since yesterday :/,
anyway, the loader code in the above comment should also be kind of enough - thanks again

[xxronis]

ok let me recap a bit, so this becomes useful :).

I understand that for me to use defer() and <Await> as I expect, I got to useLoaderData() in my component.
I can do that and it kind of works, except I don't really have the components wired up with RQ right?, and I cannot invalidate queries in a sensible way when leaving a route :/

I made this work with initialData from the loader but having my previously "deferred" data queries performed in the respective components, so suspense works with no <Await>, like:

Loader

export const loader = (queryClient: QueryClient) => async () => {
  const collabsQuery = mySharesQuery();
  return queryClient.ensureQueryData(collabsQuery);
};

Route component

export default function Collaborations() {
  // const { collabs, sharesMenu } = useLoaderData() as any;
  const { collabs: initialCollabs } = useLoaderData() as Awaited<ReturnType<ReturnType<typeof loader>>>;

  const { data: collabs, isError } = useQuery({
    ...mySharesQuery(),
    initialData: initialCollabs,
  });

  if (isError) return <SharesError />;

  return (
    <div>
      <main>
        <div className="flex flex-row justify-between">
          <h2 className="card-title mb-6">Collaborations</h2>
          <AddNewCollabForm />
        </div>
        <div className="mb-6">
          {/* Route awaits for collabs data */}
          <Table data={collabs?.items} />
        </div>
        <div className="flex flex-row justify-between">
          <Suspense fallback={<Spinner text="Loading shares menu..." />}>
            <SharesMenu />
          </Suspense>
        </div>
        <Outlet />
      </main>
    </div>
  );
}

Now the SharesMenu performs its query and suspense works without this query blocking route rendering.

Child route component:

export default function SharesMenu() {
  const { data: menuItems } = useQuery(sharesMenuQuery());

  return (
    <div className="card bg-base-100 shadow-xl">
      {message && <div className="bg-blue-500 absolute rounded-t-xl w-full">{message}</div>}
      <div className="card-body">
        <h2 className="card-title">Some Data</h2>
        <Menu items={menuItems.items} />
      </div>
    </div>
  );
}

This is all great, BUT what I am missing from my desired design is that I don't have all my requested data for this Route in its loader and defer what I can not wait.
I have to go into the SharesMenu and perform the query from there, making it known to that component, write isError etc in there (maybe its OK!) while in the other case I could just pass deferred loader data to it, control error element with Await in the route component, making my UI component data-exchange-agnostic which sounds good to me.
Maybe I'm overthinking this..

How would your example become if you needed more than one queries in your loader and u should wait only for the fast ones?

Hope it makes some sense - any piece of advice is much appreciated, thanks!

[TkDodo]

I would useSuspenseQuery to a) always get data that isn't undefined and b) let error handling be done by error boundaries. That way, you'd integrate with suspense and error boundaries from the router.

[eriolo]

Thank you, great article! I'm not sure I follow why useLoaderData is needed; fetching by e.g. await queryClient.fetchQuery(getMyQueryOptions()) (let's say we have 5s staleTime) in a react router loader should put the response data in the react query cache, right? If I then in the presentational component in the route we read by e.g. const response = useQuery(getMyQueryOptions()), it should then read from the react query cache? If so, why is the middle step using useLoaderData to set initialData needed? :thinking

[TkDodo]

why is the middle step using useLoaderData to set initialData needed?

mainly to get data to be typed as TData rather than TData | undefined. suspense would achieve the same thing

[ghost]

So how about using dispatch inside action ?

[TkDodo]

sorry what's the context here?

[zigzter]

It works great, thanks for the post! However, I'm curious about this part:

We also want errors to be thrown to the errorElement, so fetchQuery is the best option.

Don't you lose some granular error control with this? I'm currently grabbing isError and error from my query, but since the error gets thrown to the errorElement, it just renders that, replacing my component with the error component, and those two error variables never get used.
Although maybe my issue is just my single Error component, and I'd be better off creating multiple of them instead of a catch-all one?

[TkDodo]

every route can have its own error component, and if loading in the router failed, I'd like to display the error component for that route so that I don't have to handle errors in the component where I useQuery.

[zigzter]

Ahh that makes sense, I'll give that a try, thanks!