blog/react-query-as-a-state-manager

[utterances-bot]

React Query as a State Manager | TkDodo's blog

Everything you need to know to make React Query your single source of truth state manager for your async state

https://tkdodo.eu/blog/react-query-as-a-state-manager?utterances=59bd06b8dcfe487234bd5af58Q2m%2FkVpN9YKFH7h897nXK%2BW8vHzTHreZP59PuTGhgu7MlpG0XPLh49z6unbM5sEtiuOUwg5k2iaVTHKP9HPsN7Kh07WRKuGCCueuMOp0S4%2FS5PIdbpoUW2kaQE%3D

[tannerlinsley]

This article is fantastic. A job extremely well done.👏

[rajivchaulagain]

Loved you work also sir , creating many open source website and maintaining them wow , in short way you are a life savour for me. I used all your library like react-query for async state management , react-table for managing table.

[nikoskleidis]

Great article!
In some cases I have used staleTime: Infinity on a query in order to indicate that it stays the same until I manually invalidate it.

[TkDodo]

Thanks 🙏 . Yes, I do that too sometimes @nikoskleidis, but not very often ;)

[rodrigofariow]

High quality article as usual!
I always prevented myself from setting staleTime globally to something other than 0 because I knew that one time or another a use case would show up that would cause me to overwrite something that I felt shouldn't be overwritten.
Now that I think about it really depends on the refetch "aggressiveness" our users are used to and how much "real time" do we want our app to be.
I've had several situations where something like ~5sec state time would be perfect to prevent over fetching but never got to change it globally 🤔
Maybe I will reconsider!
Cheers!

[rjgux]

Amazing article, straight in to my bookmarks! Thank you

[fram7]

Excellent article. I usually disable on tab change refreshing, but with you explanations get total sense to use it.

[idanaim]

Thanks!

[luisadame]

Brilliant article.

Found two typos:

- which means that evey time you e.g. mount a new
+ which means that every time you e.g. mount a new

- passing Query Keys to setQueyDefaults follows the standard
+ passing Query Keys to setQueryDefaults follows the standard

It seems that your R key might have some dust in it 😛

Agree with the defaults being generally fine, specially the refetchOnWindowFocus which I personally like a lot. I found quite useful setting query defaults for "namespaced" query keys for data we know when would it might be staled. I really like that approach.

Thank you for your work!

[TiagoPortfolio]

This article is a must-read to everyone starting to use React Query!
In here we have pretty much all core concepts explained which I struggled a little to understand when I started using React Query.
Great stuff TkDodo!

[OriAmir]

Thanks for the great articles , I really enjoy and learn a lot from that.
It's give me a really good ideas what and how to use react-query properly.

[larolldev]

Another great article in the series.
I wonder how state management aspect of React Query works together with React Context in production? Could you give me some hints?
Thanks.

[TkDodo]

@larolldev react-query uses context under the hood only to distribute the QueryClient (with useQueryClient) - the actual cache lives outside of react, very similar to how redux does it. Or am I misunderstanding the question 😅?

[larolldev]

@TkDodo thanks for your hint. With react-query's "async state management" in mind, I go further to use it to manage some states which needs to be stored in localStorage. It works well. The point is react-query cares only the Promise but doesn't care what was the data source.
For example:

// To read a draft cart stored in localStorage
export const useDraftCart = () => {
  return useQuery('draftCart', async () => Promise.resolve('draftCart')
      .then(key => {
        const draft = localStorage.getItem(key)
        return draft ? JSON.parse(draft) : undefined
      }),
    { staleTime: Infinity }
  )
}

// To update the draft cart
export const useDraftCartMutation = () => {
  const queryClient = useQueryClient()

  const setDraft = newDraft => {
    return Promise.resolve('draftCart')
      .then(key => localStorage.setItem(key, JSON.stringify(newDraft)))
      .then(_ => newDraft)
  }
  return useMutation(setDraft, {
    onSuccess: () => {
      queryClient.invalidateQueries(orderKeys.draftCart)
    }
  })
}

[larolldev]

I also tried to use react-query to manage the authentication state:

• use react-query (query) for calling login API to remote server
• use react-query (query and mutation) to store and read tokens to/from localStorage

So with react-query, now I can apply in my current project for 3 following use cases:

• networking: remote API
• localStorage
• login (persisted, with freshToken) process

I'm going to integrate react-query with pusher for live updating.

I think with above use cases I can solve my React state management easily in the cleanest way.
The key points are:

• organize the Query KEYS
• write the query and mutation hooks

I removed all old redux codes, and feel like I got freedom again. :-)

[TkDodo]

@larolldev while it's true that react-query only cares about promises, I wouldn't use it for synchronous stuff - and reading from localStorage is synchronous. I've gone a bit into details on why that is in this github discussion: TanStack/query#489 (comment)

[TkDodo]

@AlcantaraRW sure, that's totally possible. Usually, I would advise to have filters done on the backend. So only active users would be part of the query key, then the backend would do the filtering.

If you want to do frontend filtering, there are basically two ways:

1. Just filter the data from the query:

const [onlyActiveUsers, setOnlyActiveUsers] = React.useState(false)
const { data } = useQuery(key, fn)
const filteredData = onlyActiveUsers ? data?.filter(x => x.active) : data

2. You can use the select option to directly filter on the query data:

const [onlyActiveUsers, setOnlyActiveUsers] = React.useState(false)
const { data } = useQuery(key, fn, { select: data => onlyActiveUsers ? data.filter(x => x.active) : data })

[AlcantaraRW]

@TkDodo I fetch all unfiltered data when my page mounts, then when I click on my Filter component, inside the page, I would like to grab the data that React Query already cached to execute a filter on top of it and update the table.
So I think the issue here is that component A makes the query but I click on component B to update data that is already being displayed on component A. If component B had only to invalidate the cache it would be easy, but I actually need to invalidade and make the query again filtering it (with some different fetch logic).
And the filter would have to persist because when a refetch is made, the original unfiltered query is done again.

[TkDodo]

@AlcantaraRW I don't quite follow. is the filtering now happening on the client side only, or is it happening on the server (you mentioned different fetch logic)?

I think a codesandbox reproduction would be helpful to understand the situation better :)

[thegauravthakur]

Really helpful article

[kimsagro1]

Great article @TkDodo. If you set staleTime to 20 seconds, what would you set cacheTime to. I'm thinking cacheTime needs to be greater than staleTime correct?

[TkDodo]

I'm thinking cacheTime needs to be greater than staleTime correct?

No, that's not correct, because cacheTime only affects inactive queries. cacheTime is just for garbage collection (maybe we should name it gcTime instead 🤔). As long as queries are active, the cacheTime timer is not running. Only once a query becomes unused (because you e.g. navigate away from the page where you show the ['todos'] query), the timer starts and will remove the data from the cache after cacheTime has elapsed. Have a look at the caching example in the docs.

[jmamadeu]

Awesome article, this is the first time I see your blog, it's 100% well done.

[TkDodo]

thank you for the kind words 🙏

[jmarbutt]

What is the best practice when you have nested components in routes? Is it still do stale time longer?

[TkDodo]

You mean nested components that read the same query?

[jmarbutt]

Yes, For example, my nesting looks something like this:

<Route path=":id" element={<ContactViewLayout />} >
    <Route path="" element={<Navigate to={`activity`} />} />
    <Route path="activity" element={<ActivityList />} />
    <Route path="details" element={<EntityDetails />} />
</Route>

Where the Contact View will get the contact information but the details and activity list also need it when it is navigated to those.

[TkDodo]

I was hoping that this is exactly the point I covered in the blog post here: https://tkdodo.eu/blog/react-query-as-a-state-manager#letting-react-query-do-its-magic

so yes, in a nutshell, call useQuery wherever you need data and set staleTime.

[jmarbutt]

Yep, that is what I thought you were saying but was making sure for sure. Thanks for the info

[ah584d]

Hi , I have a [stupid ?] question.
Today in my project I use a state manager ( easy-peasy, it is ugly I know, this is legacy code !) and react query.
Is there a way to throw away my state manager and use only react query to manage also non async data?

saving for example some config values in react query and allowing to share them between all the components.
thanks

[TkDodo]

no, react-query is tailor made for async state. The moment you try to use it for sync state, it becomes suboptimal. I always recommend to use a different client state manager. One of my favourites is zustand

[anboch]

@TkDodo thank you for the great article.
I am inspired by using React Query as a state manager, and I am trying to do user authentication. The issue is that if I remove a query data from one component (component 2 from the example), the state (userQ) in the other component (component 1 from the example) does not change.
Please tell me why this is not happening.
Example in codesandbox

[TkDodo]

That's because removeQueries doesn't trigger a re-render of consumers. If you want that, use resetQueries.

However, please keep in mind that login requests should usually be a mutation, as you want to trigger it imperatively and it has a side-effect (it logs the user in).
After that, it's usually fine to either distribute the logged-in information via React context, or to have have a separate /me endpoint that gives you info about the logged-in user.

[lyan-ap]

still tricky when processing pagination issues.

[TkDodo]

what kind of pagination issues ?

[lyan-ap]

like searching params is complex , may it contains params(pageSize/pageIndex) , data(time/name/email...),sorter,filter etc. And the pagination UI may hard to display and maintain.

[jakebarnett-ampd]

Would another tradeoff of using useQuery in each component that uses the data (as opposed to calling it once in a parent component and pass the data as props) be that you need to handle Loading and Error states in each child component, instead of just once in the parent?

This seems especially cumbersome when you need a piece of fetched data in order to load any part of the app (like a User or a Session). I would need to handle the Loading state in every leaf component that uses the User query, but in reality no part of the app can load without the User being available and so all the loading states beneath the the application root won't get triggered.

Fantastic article btw, I'm implementing RQ for the first time in my org so I'm trying to make sure I get the patterns right.

[TkDodo]

if you mean that data can be potentially undefined then yes, that is something you need to account for. Doesn't mean that you have to handle loading / error state everywhere, especially if you invert the checks (as shown in https://tkdodo.eu/blog/status-checks-in-react-query). What we do is mostly use errorBoundaries to handle errors and handle loading of things what we absolutely need at a higher level (could also be done with suspense), so that we don't have to do it on every component. So what remains is usually:

const Component = () => {
  const query useMyQuery()
  if (query.data) {
    // render data
  }

  // this could also be a loading spinner, but it's often enough
  // if you use suspense, this is perfectly fine
  return null
}

of course you can also take the data at the top and put it in react context, which is similar to prop-drilling it. It has the drawback of not getting background updates as frequently, e.g. when mounted conditionally, and you can't use select, but it's not state syncing, as I've described here: https://twitter.com/TkDodo/status/1599360060685053952

[brettinternet]

This is a great series. I'm also glad I found the select option in your other posts, but it's very relevant here to select only the state data you need and minimize rerenders to only relevant data. Thank you!

[andygr1n1]

Thanks, great article!

[PieceOfMeat]

I wonder if it's OK to sync react-query data into a Zustand store for just the same purpose you're using Context here.

I have a rather complex page, with several queries I need to pass down the component tree, and a Zustand store, for keeping synchronous state on the page. It felt weird to use Context when I have Zustand (which is already great for avoiding props drilling), so I did something like this:

const { setData } = useActions(); // Actions from Zustand
const { data, ... } = useQuery(...)
useEffect(() => {
  if (data) setData(data);
}, [data])

Now I can easily access this data in all child components, keeping all the react-query perks at the same time, with a slight taste of guilt from syncing state this way :)

[TkDodo]

it's not ideal because there is one render cycle where data from RQ is out of sync. Also, if you ever call setData without data from RQ, it will get out of sync. Why wouldn't you just call the custom hook in the child where you need it instead ?

[PieceOfMeat]

You're right, I just added some staleTime (I hide components which use these queries behind general loading spinner, so I need it to avoid repeated fetches), and everything looks cleaner and more reliable now, thank you!

[John-Maleek]

This is a great article. I learnt a lot. Thank you!