React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

Learn the fundamentals of React Query by going through the basic API and then implementing search in an employee tracking app.

To use React Query throughout your application you'll need to import and create a new instance of [QueryClient](https://tanstack.com/query/latest/docs/reference/QueryClient#queryclient) and pass that to the [QueryClientProvider](https://tanstack.com/query/latest/docs/framework/react/reference/QueryClientProvider) component in the root of your app. 

Setup React Query and QueryClientProvider

With the [useQuery](https://tanstack.com/query/latest/docs/framework/react/reference/useQuery#usequery) hook, you can make queries directly in your components! 

To get started you just need to provide a `queryKey` and a `queryFn`. 

Fetch and display server data using React Query useQuery hook

[React Query Devtools](https://tanstack.com/query/latest/docs/framework/react/devtools#devtools) provides a component that you can use to see and perform actions on every query in your app.

Configure React Query Devtools and inspect existing queries

As long as whatever you're using to fetch data returns a Promise, you can use it in the [useQuery](https://tanstack.com/query/latest/docs/framework/react/reference/useQuery#usequery) hook.

So when fetching data, you can use native `fetch`, `axios`, `ky`, or whatever else! 

Use fetch, axios, ky, or any other promise-based library within useQuery hook

React Query will narrow the type of your query results depending on its state. 

In this lesson, you'll dig into the types under the hood, and then conditionally render various messages based on the state of the query. 

Display loading, error and successful query state using React Query Type Narrowing

There are nuances between the three loading states provided by the `useQuery` hook:

- `isPending`: there's no data and a query hasn't been made yet. 
- `isFetching`: the query is being fetched
- `isLoading`: there's no data, and there's a query currently being fetched. Notice that it's a combination of the above.

In this lesson, you'll learn where you'd want to use each of these states.

Use isPending, isLoading and isFetching flags with React Query

`useQuery` follows the rules of hooks. You can wrap it in a custom hook for convenience if you want to layer in some additional functionality.

Extract React Query useQuery into custom hooks

[queryOptions](https://tanstack.com/query/latest/docs/framework/react/reference/queryOptions#queryoptions) lets you pull the options of a query out into its own variable. This is useful because there are many cases where you'd need to reuse the options: re-fetches, running different query types, etc. 

Reuse Query Settings using the queryOptions API

React Query is smart with its caching. When you have a `useQuery` hook calling the same query in several places, React Query is going to already have the data pre-loaded for other components once the first one is rendered. 

It was also fetch data again once it becomes stale. 

Share fetched state across multiple components using React Query

By just calling the `useQuery` hook with each of your queries, you can have them all running in parallel. 

Implement Parallel Queries execution using multiple useQuery hooks within React Query

The React Query Devtools gives you several actions that you can manually trigger on your queries. 

These include:

- Refetch
- Invalidate
- Reset
- Remove
- Trigger Loading
- and Trigger Error

By using these actions you can manually test out your component's behavior with the various states of your queries.

Manipulate existing queries with React Query Devtools

In `queryOptions` you can set the `staleTime` of a query to set how long it takes for data to be considered stale and warrant a refetch. 

By default, React Query sets this value to `0`. 

But, different queries will need different times set depending on how often the data on the server is being updated.

Configure staleTime within React Query

`gcTime` stands for "garbage collection time" and it is the amount of time that must pass, when there are no components actively using a query, before the query is cleared from the cache.

It is set independently from stale time!

Configure gcTime (garbage collection) within React Query

The resulting data from your queries is simple to use in your components. You will just need to consider the fact that the data is potentially undefined and work around that. 

In this lesson, you'll see how data from a query can be filtered with client-side search. 

Implement a client-side search using React Query

In this lesson you'll see a few concepts from previous lessons come together! 

Instead of just filtering the resulting data from a query in a client-side search, you can actually make your queries dynamic and do that filtering server-side. 

Implement a server-side search using React Query

When handling your loading and error states, you don't always want to render a result in place of the entire component. 

In our server-side search component, since we are making a new query when we update our input, the entire component re-renders, including the search input itself. 

To fix this we'd move those conditional renders into a ternary inside the component render.

Use Type Narrowing without early function returns with React Query

To implement pagination you'll need to extend your search params type. 

You'll also want to set a default value for the page either on the http function level, or the query function level depending on the design of your application. 

You'll see how nice React Query's caching is when you quickly click back and forth through the pages and see the results immediately, since we set the garbage collection to take a few seconds in a previous lesson!

Implement a server-side pagination using React Query

jotai gives you a minimalistic API that you can use that separates your state management from your UI. Don't have to set up any boilerplate like actions, reducers, etc.

Manage Application State with Jotai Atoms

This is a series of videos where you'll find part interview and part screen share with experts. They focus on React, but the underlying principles are valid for UI work in general.

React State Management Expert Interviews

Accept payments & sell products powered by Stripe and the best of the JAMStack.

Create an eCommerce Store with Next.js and Stripe Checkout

Simplify State Management with React Query

https://app.egghead.io/api/v1/lessons/react-setup-react-query-and-queryclientprovider/subtitles

[00:00] Open the console and type NPM install at tamstack slash react query. After react query is installed, we need to put the react queries query client provider component. Let's put it over here, query client provider. And
[00:19] let's import it from 10stack slash react query. So it's going to wrap the entire content of the application. In our case, the content of the application is put within the React router provider over here. So query client provider accepts the client itself, so we first need to create
[00:39] it. So const query client equals new query client and this is going to be imported also from 10stack slash react query, query client over here. So this is going to be our handle that is going to process
[00:59] everything that is going to be related to React Query. Most often, we are not going to interfere with this object directly, but it just needs to be put over here. So everything up is running. Let's just take a look at the components tab of the React Dev Tools, and let's
[01:19] type query client provider. And we can see that query client provider is available at the top of our application structure.

https://app.egghead.io/api/v1/lessons/react-setup-react-query-and-queryclientprovider/transcript

https://app.egghead.io/api/v1/lessons/react-fetch-and-display-server-data-using-react-query-usequery-hook/subtitles

[00:00] Open the React component and let's make use of the use query hook. It is being imported from tanstack slash react query. Use query is the most fundamental and the most important hooks we're going to use within React Query. So it accepts a lot of different parameters though. We're going to
[00:19] define 2 of them, the 2 most important ones. So the query key. This is the identifier of the query. So it identifies what is the data that we are going to fetch from the server. So it should be an array that might include strings or objects. So in our case,
[00:39] we're going to display the data about employees. So let's put that this is the employees entity and we're going to fetch the list. So this is the identifier. And we need to specify how do we want to fetch the data. So this is the query function. So in our
[00:59] case, we're going to put the async function which is going to make use of a function that returns a promise. So let's take a look at another file, the employees API which includes the get employees function. This is the one that is relevant for
[01:19] now. So right now, we are not using the query string over here. However, we're just using the native fetch function so that we run the HTTP get request on the URL slash employees. And what we expect over here is that the response is going to
[01:39] be employee array. So let's use the get employees function over here. So what we're going to do is to import the function and run it. What is being imported is that query function is returning the get the result of get employees.
[01:59] So query function itself is inferring what is the result. So the whole use query call is also inferring what is the result of the query data. So what we can get from here is lots of different properties. We're interested in the first step and just the
[02:19] data. So there might be 2 states. 1st, the data has already been received and the data is not yet received. So we're just going to put a conditional rendering over here. So if the data has been already received, then we're just going to put the data over here.
[02:38] So we're making sure that on the TypeScript level, the data variable is not undefined anymore. And our employee listing is actually requiring the employees prop to be there, not to be undefined. So let's see how it goes right now.
[02:59] So we can see that the list has already been displayed And let's just reload the application. So we can see that there has been an employees page 1 request made. What is important is that React Query is tracking which components actually
[03:19] need the data. And obviously, if there are no components that actually require some queries, then the requests are not going to be made. So let's walk into the index tab of our application and red start the application back again. And we can see that initially,
[03:39] there are no requests being made. And when we actually walk into the employees tab, then the query is going to be needed by the first component ever. So this is the first moment when the query function is going to be executed. So let's walk into the employees tab over here and we
[03:59] can see that this request has been made again.

https://app.egghead.io/api/v1/lessons/react-fetch-and-display-server-data-using-react-query-usequery-hook/transcript

https://app.egghead.io/api/v1/lessons/react-configure-react-query-devtools-and-inspect-existing-queries/subtitles

[00:00] Open the console again and let's type npm install tanstack slash react query dev tools. Unlike many other dev tools, these are not going to be a browser extension. This is going to be an NPM package that includes a component which we are going to
[00:19] include into our application hierarchy. So let's put this component just near the main content of our application. So near the router provider. The component is called React Query Dev Tools. And it's being imported over here from 10stack slash react
[00:39] query dev tools package we have just installed. And there is one prop we might be interested in setting. This is initial is open, which accepts a boolean. So depending on what is the value, initially, the DevTools might be open or not. So after I save this file, take a look at
[00:59] the right hand bottom corner over here. We can see that there is an icon showing that the dev tools are already here. When we click, we can see that the dev tools are open. So here we will see the list of all the queries that exist within the application. So there is only one query, the one that we
[01:19] have just created, the employees list. When we click at the query, we can see what is its state. So in this case, this is a stale because the time has passed. We're going to speak about it in a while. And we can see what is the data over here, we can also trigger refreshing, we
[01:39] can trigger invalidating, resetting and many other operations that we are going to look in in a while.

https://app.egghead.io/api/v1/lessons/react-configure-react-query-devtools-and-inspect-existing-queries/transcript

https://app.egghead.io/api/v1/lessons/react-use-fetch-axios-ky-or-any-other-promise-based-library-within-usequery-hook/subtitles

[00:00] Open the function which executes the HTTP request. In our case, the use query hook is using the fetch API. However, use query requires any API or any library that is capable of returning a promise which resolves once the data is being received. Let's
[00:19] install an alternative. Let's type npm install, and we'll install Axios and Kai as just two example libraries, which are going to be replacements for fetch. Let's start with Kai. Replace fetch with Kai. Now we need to import
[00:39] the Kai object from Kai package And let's type kai dot get just to make the HTTP method explicit. And now let's open the browser dev tools and head over to the network tab. And after refreshing the page, we will see that the same request, employees page
[00:59] 1, has been requested and the data correctly displays. So there is no difference in how React Query works with whatever the API is. So let's also try Axios over here. So const response equals and now we're going to use
[01:19] Axios, and we need to import Axios from the Axios package. And we're going to execute again a get request. We'll use what the URL was. And here, we're going to slightly change what is going to be the types over here.
[01:39] So this works the same way as the assertion, however, the API is slightly different because we're explicitly passing what is going to be the generic type over here. So what we're going to return is the response dot data. So the response dot data
[02:00] is basically the type that we have put over here. And after I move the await to the first line, this one is not needed. So after saving the file and refreshing the page, we can see that now Axius is loading the data. So whatever the API is, as
[02:20] long as returns a promise including the response, this query is going to work correctly.

https://app.egghead.io/api/v1/lessons/react-use-fetch-axios-ky-or-any-other-promise-based-library-within-usequery-hook/transcript

https://app.egghead.io/api/v1/lessons/react-display-loading-error-and-successful-query-state-using-react-query-type-narrowing/subtitles

[00:00] Use the object returned by the useQuery hook. And we're going to destructure 2 more properties out of it, and these are the is loading and error. What we have for now is that the data could have been received already or not loaded yet, which is represented by undefined.
[00:20] The error could have occurred or there might be no error represented by null. And finally, the status of the query which says that it is either still loading or if it has succeeded or failed, it would be is loading failed. What is important is that not all combinations
[00:40] of the potential values of all these properties are possible. For instance, if we are initially loading the data and we have succeeded and we have the employee array over here. It's not necessarily possible that we would have an error at the same time
[01:00] because in the initial case, it just might not be possible. It might not make sense. So for this reason, React Query is using TypeScript unions of object types to explicitly define what are the valid possibilities. So let's take a look at how it's defined, and we will
[01:20] take a look first at what are generally the possibilities. So these are defined by the query observer base result type. So here it defines that generally data could either be the data or no data yet. The error could be either the error or no error yet and so
[01:40] on and so forth. But if we scroll down, we will see just the explicit possibilities. So for instance, the query observer loading results determines that we initially have the loading, which is true. So we have no data yet, and there is no
[02:00] error yet, but we are loading. Of course, we have more properties, but these are just the important ones for now. And we have also query observer success result, which means since this is success, we do have the data and we don't have the error. And since we have a success, we are not loading
[02:20] yet. So the is loading is false. But there could be also an error state where the error is there, we don't have the data, and we are not loading because, well, we just failed, or that there was a refresh error, which means
[02:39] we did have the data before and now there is an error. And since the error happened, we are not loading yet. So depending on whatever if statements, any conditions that we're going to execute, TypeScript is going to narrow the types accordingly. So let's
[02:59] move back to the employees page and let's use the properties discussed. So we're going to create a couple of if statements to check-in which status we're in. So if we are in the loading state, let's just return a simple message defining that we are still loading or if we are in the error state,
[03:19] let's also display what is the error message. So here we're going to use the error dot message property. Unless we specify that otherwise, the native JavaScript TypeScript error prototype or interface is going to be used. So you could think that
[03:39] since we are in neither loading nor the error state, so neither of these early returns has been executed, then, well, we have excluded all these other cases so that data should actually be here. But we can see that within the data property type, undefined is still there. So at this
[03:58] point, we need to dive a little bit deeper into the different properties that represent the fact of loading. So we have a couple of them. Is loading is one of them. There is also is pending and there is also is fetching. So they all relate to data loading, data fetching, the data that is pending, but they
[04:18] have slightly different meanings. We're going to dive deeper into it in the next lesson. But most of the cases, what we want to use is the is pending property, which basically means we have no data loaded yet. So we have nothing to display whether we are already, like, fetching some data, there is a
[04:38] request ongoing or not. We have no data yet. So basically, there is no way for us to display anything over here. And if we have excluded is pending and error, then we can see that yes, undefined is being totally removed from here. So what we can do is to get rid of this conditional rendering over here. So now
[04:58] let's take a look how does our component actually behave. So let's refresh it over here and we can see that the employees list over here is displaying correctly and it's also showing the loading message over here. So let's see how would this behave if we have
[05:18] triggered an error. So for this reason, I'm going to use the browser dev tools. They block request URL or block request domains. So just click somewhere over here and we have enabled the network request blocking. This is a very useful feature. And we
[05:37] have just made sure that local host 3,000, employees page 1, this is going to throw an error whenever we want to request it and the whole network request blocking is turned on. So I'm going to refresh the page, and React Query is going to shoot a little bit of retries.
[05:57] So let's just see how this goes. I'm refreshing the page, we can see that the first request has failed, the second one, the third one. And finally, when the 4th one is going to fail, we can also see that the failed to fetch error message, which comes from here is displayed. So this is the way we can differentiate
[06:17] and display different content depending on what is the state of the query. And don't forget to turn off the enable network request blocking. If you do, this triangular exclamation mark is going to remind you about that. So just turn it off and now network is going to work normally.

https://app.egghead.io/api/v1/lessons/react-display-loading-error-and-successful-query-state-using-react-query-type-narrowing/transcript

https://app.egghead.io/api/v1/lessons/react-use-ispending-isloading-and-isfetching-flags-with-react-query/subtitles

[00:00] Let's destructure some more properties which determine whether the query is in loading state. So we have is pending and we also want the is loading one and the other one is going to be is fetching. So there is more, but these are the ones that we're interested in. So the difference between them is that is pending
[00:20] determines that there is no data available within the query, so that there is no data for this component to display. It means, basically, that the query entry exists, but it's empty. Is fetching determines that there is a request that has been sent from the client to a server, but the response hasn't arrived yet.
[00:40] So we're basically during the time of fetching. And is loading is something that we can consider as is initially loading because, technically, it boils down to is pending and is fetching at the same time. So we have no data yet, and we are during fetching, which essentially can take place only initially.
[01:00] So what we're going to start with is actually is fetching since we can initially load the data. But it could happen that for any reasons, we might be re fetching the data so that even though something might be displayed over here, we would also like to show a spinner or any kind of message, which would denote that there is some
[01:20] request that we are awaiting for its response. So let's put some conditional rendering over here, which will say that if we are during fetching, we just want to show a message or a spinner, whatever that is. So let's save it and let's see how it looks. So initially, we could see the loading message
[01:39] available over here. But we'll also trigger a fact that if we walk to another page and we would go back to the employees, what React Query is going to find out is that the query is being stale. So it would refetch it. So what we can see is that both the data and the loading message is being displayed. Let's
[01:59] see it once again. Both the data and the message is displayed. And this is because we do have the data available for this component to be displayed, which means it's not pending because the data is there, but we're also fetching or actually re fetching the data. So if we want to use the is pending, that basically
[02:19] means that there is no data to be displayed yet. And finally, if we want to use the is loading, that basically means that we have never had any data loaded yet. So in most of these situations, is loading and is pending actually boils down to the same
[02:39] place, but let's just see how is loading is going to be displayed. So we have seen we have never had any data loaded yet. So is loading is going to return early in this case. So most often, what you would like to do is probably something like this. And since is loading is a type of is pending, this is what
[02:59] you're going to use with most of the cases.

https://app.egghead.io/api/v1/lessons/react-use-ispending-isloading-and-isfetching-flags-with-react-query/transcript

https://app.egghead.io/api/v1/lessons/react-extract-react-query-usequery-into-custom-hooks/subtitles

[00:00] Create a new hook. Since we've been loading the employees data using the use query hook, let's call it use employees query. And the whole content for now, initially, of the hook is just going to be the definition and 1st and foremost, the configuration over here for the
[00:20] use query. So let's just return it over here and let's make sure that all the imports that we've had are also imported within the file. And right now, we're just going to simply use the hook in this place. So the change that we have made is that from now on, the hook is the same, but the employees
[00:40] page component doesn't need to know all the complexity about React Query, all the settings, how it's defined, what is the key. But also if we wanted to use any other custom hooks, like related to different state management solutions or just native hooks, we could just put them and expose them combined just
[01:00] as the use employees query. So the component is simpler, but also if there are multiple components which would like to use this hook, there is basically one reusable thing that different components can use without making changes in multiple places.

https://app.egghead.io/api/v1/lessons/react-extract-react-query-usequery-into-custom-hooks/transcript

https://app.egghead.io/api/v1/lessons/react-reuse-query-settings-using-the-queryoptions-api/subtitles

[00:00] Use the query options functions, which we're going to directly import from the 10stack React query package. And the query options will allow us to create the configuration for a query without defining a query itself yet. So let's create an export const employees
[00:20] query. Note that this is not going to be a hook. This is just going to be a query definition, query declaration, whatever. So let's just use the query options functions, and we're just going to cut away all the settings for this certain query. And we're going to use it back within our hook so that there are no
[00:39] breaking changes. So the whole point of extracting away the query options is that we might use it within just use query, but we could also use that within the use queries if we want to run multiple queries at the same time. Or if we want to use the use suspense
[00:59] query or use suspense queries, and there is many, many different places where we would like to use it. Also, if we wanted to directly work with the query client object, for instance, to prefetch a query, refetch a query, and so on and so forth, we might need to use the definition of the
[01:19] query by passing what is the definition over here. So one more important thing is that when we use the query options functions, there is a data tag defined here within the query key. And this allows us to pass just the key definition
[01:39] of our query, and it will remember what is the type returned from the server's response related to that query. So we'll be able to, for instance, prefetch or refetch a given query only by the query key, but react query will figure out what is the type
[01:58] related to it, which is going to be super useful. Now if we want to make directly use of the employee's query, we can go back to our component and replace our custom hook with simply use query and importing the employees query options, which we have defined, and
[02:18] they use query over here. And we can remove the one right here. And let's just refresh our page so that we can see that all the data is being correctly displayed.

https://app.egghead.io/api/v1/lessons/react-reuse-query-settings-using-the-queryoptions-api/transcript

https://app.egghead.io/api/v1/lessons/react-share-fetched-state-across-multiple-components-using-react-query/subtitles

[00:00] Let's move to a different component, budgets page in our case, and let's click on the budgets tab over here so that we can see that there is a table with some empty data. So in this example, we're going to fetch the same employees data so that we can calculate the total monthly
[00:19] cost of all the employees and total yearly cost of all employees salaries. And the same way, we're going to use a different rest resource from the server, which is going to display what is the monthly total cost of benefits and the yearly total cost of benefits. So for this reason, we're just
[00:39] going to use the same query that we've been using previously. So let's import the use query from 10stack, and we're going to also use the employees query, the one that we have just extracted previously. So let's destructure what is the data property, and we
[00:59] need to support both cases when the data is already loaded or not routed yet. So if the data is already loaded, then we just pass the data into the salaries cost, which is going to calculate the monthly and the yearly, total salary costs for an array of employees.
[01:19] So let's save it right now, and we can see that the data is already here. So when we refresh the page, we can see that this is loading. And once the data is loaded, we can see that it's immediately displayed. What is important is that once we download the data within
[01:39] any of these components, the other component would get the data immediately from the cache. So right now, I'm going to refresh the page, and I'm going to open the 10stack dev tools. Right now, we haven't loaded the employees data yet, but when we move to one of the pages that do need the data, then we can see
[01:59] that, yes, employees list key is already here. And when I will walk into the budgets tab, we will not see the data is being loaded, but the data will be displayed immediately. In the same way, if we walk back again into the welcome page and I refresh the application so that we have no data
[02:18] loaded yet, and we move into budgets, we will see that, yes, this is being loaded and it changed from blue, which denotes in loading state into the stale, which is the orange. We're going to speak about it later. And when we move to employees, we will see that the data is immediately available within the cache and so the component is going to display it
[02:38] immediately.

https://app.egghead.io/api/v1/lessons/react-share-fetched-state-across-multiple-components-using-react-query/transcript

https://app.egghead.io/api/v1/lessons/react-implement-parallel-queries-execution-using-multiple-usequery-hooks-within-react-query/subtitles

[00:00] Use the use query hook once again within the budgets page component. Let's start with renaming the data property into data employees since we would have twice the same name of the property, which is obviously not going to work. So now we can use the use query hook again, and we're
[00:20] going to use the benefits query, which is very similar to the employees query. And here, we're going to use the data, which is going to be replaced into benefits data property, and we're going to use the benefits cost the same way as we've
[00:39] done with the data employees. So these functions are very similar. And, again, it's either the object which is required by the budget table or undefined. So now when I'll save the component, we can see that both data is going to be displayed. What we're interested in is taking a look how
[00:59] this will work within the React Query DevTools. So let's walk to the welcome page. Let's refresh. Let's make sure that there are no queries loaded initially. And what we'll see within the budget tab is that those queries are running in parallel. So if we now take a look how this looks within the
[01:19] network tab, We will see that when we refresh that the order of the queries could be different each time. Know that if there is a React component which is actively displayed within the application and the component is using multiple use query hooks, we can think of it as if this
[01:39] component had multiple dependencies from an external server data. And React Query interprets this in a way that both of them have to be displayed. Of course, each has separate data state, separate loading state, separate error state, and so on. Though, since the component
[01:58] requires all of this data to be loaded, React Query is going to immediately start loading all of the hooks.

https://app.egghead.io/api/v1/lessons/react-implement-parallel-queries-execution-using-multiple-usequery-hooks-within-react-query/transcript

https://app.egghead.io/api/v1/lessons/react-manipulate-existing-queries-with-react-query-devtools/subtitles

[00:00] Open the query dev tools and let's start with changing the position to right hand side. So what we can see apart from the list of the queries are the query statuses and some query actions that we can perform. So let's take a look at the employees page, which has one query and
[00:20] that is the employees list. The green color determines that the query is fresh, meaning that the data that has been loaded is so new. It's new enough that we don't have to worry that the data could be outdated in any way. So we consider it fresh. There is no need to reload it. However,
[00:40] after some time, the query becomes stale. As we can see, it is stale right now, which means it's kind of okay ish to display. However, if there is any opportunity, we're going to reload it. And when I will move to another page, we will see that it will move to blue so that it will be refetched
[01:00] because it's stale. So it's not fresh enough. So when I click to budget, it's being blue, refetched. And when moving back to employees, again, it's being reloaded. What we see also is that there is a gray color that determines that there is a query that exists within
[01:20] the query client, but it's inactive. So essentially, it means there was a component or multiple components which required the query to be used in some way. But as for now, there are no more active subscribers, no more active components that would demand it, that would require
[01:39] it. And the number over here, that reminds what is the number of the components which are actively requiring the query data. There is also past, which relates to the enabled property of a query, which we'll deal with later on. So when it comes to the actions,
[02:00] the refetch basically means that we're going to refresh the data right here, right now. So obviously, the stale is turning into fetched. Once the data is being loaded, it becomes stale again. We're going to work on it in just a while. Invalidate means that we want to mark a query as
[02:19] stale. And in this case, as you can see, it's causing a query to be refreshed. And that is because when a query becomes stale, this additionally just causes the query client to refetch the query. Reset is a button that when clicked is causing a
[02:39] query to go back to its initial state. So there are additional properties within the use query or use queries just in the query options that we can define what is the initial state of the query. So reset when clicked moves the query back to its initial state, which additionally causes the query client to
[02:59] refetch the query. Remove is something that is essentially going to remove the query as we can see right now. And finally, we have 2 triggers. So we can manually make a query move to the loading state as we can see over here. And we can manually restore
[03:19] loading, which is going to resume the query to its natural way of working. And finally, we can also click the trigger error, which is going to manually move the query into the error state, and we can restore the error. So using the trigger loading and trigger
[03:38] error, we can visually test how does the component behave, how does it look like if instead of walking into the success state, which means that the data is available to be displayed, we can manually take a look how would the component look like. And as we can see, it freezes until I click it again. How would it look like
[03:58] if it was in the loading or the error state?

https://app.egghead.io/api/v1/lessons/react-manipulate-existing-queries-with-react-query-devtools/transcript

https://app.egghead.io/api/v1/lessons/react-configure-staletime-within-react-query/subtitles

[00:00] Go back to the definition of the employee query and add the stale time property, which defines in milliseconds the time after the data is considered stale. So since this is in milliseconds, we'll multiply 1,000 by, let's say, 3 seconds. So for 3 seconds, the data that
[00:19] is being loaded from the server is going to be considered fresh enough that there is no need for it to reload. So let's save the file, and we will see that this query is being green, is being fresh for 3 seconds. And after the time, it's moving back to the stale state. So let's take a look at how would
[00:39] this behave if we gave some more time. So this is going to be 15 seconds. I'm also going to open the network tab just to see more information about this query over here. So we're interested in how many requests are actually going to be executed. So let's
[01:00] move to the welcome page, and let's save the file. Let's refresh the application. So we can see that there is the first employee's request over here. And when we move to budgets and we move back to the employees, we can see that no additional requests being made for
[01:20] employees. But as we're waiting for the 15 seconds to pass, we're waiting for this query to become stale. And now if we walk into the budget, we can see that when the query is stale, the first moment that a new observer, a new consumer of the query, the new component
[01:39] is requiring it, then this is an opportunity for the query client to refresh the data in the background. 2 important things to note here. As you can imagine, you will want to configure different values for stale time for different queries depending on what data is
[01:59] being fetched. Another important thing is that if you don't provide what is the value of the stale time, React query by default pushes 0 since most often when we load any data from the server, it could potentially, pessimistically, be already out of sync with the new data on the
[02:19] server. By the time that we have loaded the data from the server it could have already changed. Sometimes you will want to put the infinity if you want a query never to become stale.

https://app.egghead.io/api/v1/lessons/react-configure-staletime-within-react-query/transcript

https://app.egghead.io/api/v1/lessons/react-configure-gctime-garbage-collection-within-react-query/subtitles

[00:00] Set the GC time property on the query options of a given query. This is yet again defined in milliseconds and stands for garbage collection. So as long as there is at least one active subscriber active component which requires the query data, then g
[00:20] c doesn't kick in. G c will kick in only when there are no active components and we're starting to count g c. So let me just refresh just to make sure that the new settings are applied. We'll move to employees tab. So as long as there is at least one component
[00:39] which reads the data, g c doesn't kick in. But when we walk away into a page where there are no components that would require the data, after 3 seconds, this query is being removed from the cache entirely. What is important is that stale time and g c time are totally
[00:59] independent on each other. So it could potentially happen that GC time could be smaller than stale time. They work independently and they do different things.

https://app.egghead.io/api/v1/lessons/react-configure-gctime-garbage-collection-within-react-query/transcript

https://app.egghead.io/api/v1/lessons/react-implement-a-client-side-search-using-react-query/subtitles

[00:00] Create a new piece of state, which we'll just put near the useQuery hook that we've had before. And let's just use the simplest possible approach and that would be a native use state with an initial empty string. And we're going to filter the employees objects, which we can see on the right hand side, using a
[00:20] last name, first name, whatever we choose. So that's just going to be a string property. So we've got search name and the set search name callback. So let's also create a simple corresponding input element, which is going to be an input of type text. Let's also put a nice placeholder so that it will
[00:40] say search by name. Let's also synchronize the input with the value. So the value is going to be the search name. And finally, the unchanged callback, which is going to basically use the event e. I'm not going to wrap it with useCallback, nothing like that. So
[00:59] set search name and e dot target dot value. And here we go. So whenever we type something over here, like John, this is already put into the React state. So it's not yet bound to what is the data that is being loaded by the query. So let's do it
[01:19] now. So const client site filtered employees. Since we are going to filter it client side, we are going to load whatever we've got on the server and we are just filtering it on the client side. So right now, let's be gentle and let's wrap it with the use memo call
[01:39] over here. So what we're going to put here is basically we want to filter the data, the array, but since it could not exist, we have to use optional chaining. So what we want to do right now is that for a given employee, what we want to make
[01:59] sure is that the employee, let's just filter it by last name and just to make sure that casing doesn't, fake our results, let's just make both sides, move to lowercase. And let's also put the search name dot to lowercase.
[02:19] And we can now assume that this is going to work correctly. So if the data is there, we're just going to return what the employees are. If the data is not here, it's going to return simply undefined. So also what we need to put over here, I don't have the linter turned on, so
[02:39] we need also to put what is the data so that use memo would reload and reevaluate whenever this dependency change. And also we would put the search name over here. So everything is ready. We just need to use the client side filtered employee value over here. So we're going to replace it here
[02:59] within the employee listing. So let's just replace it here. And TypeScript is yelling because employee listing expects that employees would be basically an array, so it cannot be undefined. But in our case, this could be undefined. So we can use 2 different approaches. 1 would be more implicit. The other one would
[03:19] be more explicit. The implicit one is that since we know that if is pending and error are already covered, then the data has to be here. So this one couldn't be undefined. We can figure it out. TypeScript cannot figure it out. So we could basically put the not null assertion, though
[03:39] it's not really readable. Why do we assume that this expression cannot be undefined? So either we can leave it, but also there is no problem to basically wrap this also with a conditional rendering. So let's save it and let's see how would this application behave if we refresh the page.
[03:58] So the data has been loaded. We've got one query that is currently fresh for now. And as we type something into the search name filter, we can see that Bertram Krushevski is being displayed as the only one accordingly. And we can see that the same query without any refetching
[04:18] has been used to share the data. So this is the way how we can implement client side filtering.

https://app.egghead.io/api/v1/lessons/react-implement-a-client-side-search-using-react-query/transcript

https://app.egghead.io/api/v1/lessons/react-implement-a-server-side-search-using-react-query/subtitles

[00:00] We'll replace the client side search with a server side search. And for this reason, we're going to reuse the search name and its corresponding input. And we're also going to create one more piece of state, which is going to be search nationality and set search nationality setter function.
[00:19] And nationality is simply a property on the employee entity. So let's also create that. The type is going to be nationality. Let's import it. And due to the fact that we're not putting any initial value, TypeScript is going to widen the type into nationality or undefined
[00:40] if initially we haven't passed what the search nationality is. Also, let's use a simple component, which is called nationality dropdown, which we're going to use to search by one more additional criteria. And let's also put the on change so that when there is any kind of nationality that we want
[00:59] to filter by, we're going to use the set search nationality with the value nat. Or for simplicity, we can basically put the callback directly. Now we can also see that this drop down with the nationalities, US, UK, DEFR, and so on. And as we can see, there is a new
[01:19] query that has shown up. And this query is one that I have made just in the meantime, which is used to fuel this drop down with the values. So what we're supposed to do now is we need to make sure that whenever we type any search name or choose a search nationality, this is
[01:39] going to be used to remake a new request and fetch a different set of data. So let's take a look at our HTTP function. So our get employees function is accepting a filters parameter, which includes the nationality and last
[01:59] name properties from the employee type, which we're also making optional so that we can pass one of them or the other or both or none of them, whatever. They're all simply optional. And these filters are being used to create a query string, which becomes a part of the URL just like we do with JSON
[02:18] servers. So let's walk back into the employees query since there is nothing that we have to do within this HTTP function, which basically supports the filter parameters. So our employees query includes a query key, which is right now an array of 2 elements,
[02:39] employees and list. And the thing is, if we want to make a request, which would include either the name or the nationality or both, there would be a new data set that is going to be received. And if we leave the query key to remain as it is right now, React Query is going to treat it as if it was the same request, the
[02:59] same resource. So as long as we're going to keep the same query key, React Query is not going to resend the request. So all in all, depending on the parameters that we're going to define here, React query needs to see that the query key, the identifier would be different. So the question is, what are the parameters
[03:19] that our request depends on? Simply, it's basically the search name and its date nationality. So they need to become the part of the query key. So we're just going to reuse the type from here so that employee search params, let's also create a type over here. So let's make it employee query params just in
[03:38] order to make them separate. And our query options cannot remain as it is. We have to make it a function so that each time we could actually make it a different query because it would include a different query key so that this becomes the employee query params over here.
[03:58] And we can simply use the params right here. And what is important is that neither nationality or last name is more important than the other. So we don't want to put them over here that that would be params dot last name or params dot nationality, because
[04:18] neither of them is more important. But thankfully, we can just put an object over here. So when we will be invalidating, we would be basically invalidating all the list or basically depending on whatever are the parents. So right now, TypeScript is yelling over here because this is expecting a query options object.
[04:38] But actually, right now, we don't need this use employees query anymore because we would have to be passing the params down. So let's just remove this function for now. And just to make things work, we also need to make sure that actually this object is being used over here. So whenever we
[04:58] have the params passed, get employees HTTP function is going to make use of it. So let's just move back to the employees page component, and we can see that these 3 hooks are actually defined in an invalid order. So let's reorder them quickly. And we can see that use query again
[05:17] is expecting an object and employees query is a function. So let's just call it as if it was a function. So what we can pass here is basically what is the last name. So let's pass the search name and the other property nationality, and let's pass the value of the search nationality.
[05:37] Now we don't need the client side filtered employee, the use memo call, because there is nothing basically to do on the client side when it comes to filtering. Filtering is being done on the server side. Moreover, we don't need to be doing this client site filter employee variable. So
[05:57] let's remove it from here as well because we don't need it anymore. And let's just put the data because the result, the data that is being brought by the query response is basically what we want to display immediately. So we've got this type narrowing
[06:17] working back again. So after we save it, we can see that there is a new query that is being created with this extended key with this last name, which is an empty string. So as we're going to type something into the input, we can see that there is a new query being created and the old
[06:36] one has been removed. The old one has been removed because the employee's query has the garbage collection time set to basically removed is basically
[06:56] removed. So as we'll be typing more and more signs over here, we've got crew. We've got Cruz. We can see that the employees which are left basically match the last name over here. So let's also put the value into the nationality. So let's just put it the search
[07:16] name, make it k r, and let's put, let's say, US nationality so that now we can see that the query key includes the last name, which is k r, and nationality, which is American. And we can see that both Carmelo Kris and Shania Kraichik match the last name
[07:36] and both match the nationality. And this is how we can implement server site filtering using React Query.

https://app.egghead.io/api/v1/lessons/react-implement-a-server-side-search-using-react-query/transcript

https://app.egghead.io/api/v1/lessons/react-use-type-narrowing-without-early-function-returns-with-react-query/subtitles

[00:00] The issue that we have seen in the previous lesson is that whenever we change the input value, the template becomes blank for a moment and only this message is being displayed because the query is being in the pending state. And once the data arrives, then we can finally see the whole template back
[00:19] again. So in some cases, the early returns within the if statements do their job, but sometimes we want some more piece of the template to be visible all the time and only conditionally render a smaller piece of the UI. So there are multiple different ways to do that. However,
[00:39] we're just going to simply use 2 ternary operations. So what is important is that we are still going to create a cascade of if statements or alternatively, a switch case statement. And the thing is that we always need to walk into the else statement. So
[01:00] these conditional renderings cannot be basically aside. They need to be chained if an if else, if else, if else kind of sequence. So let's start with the is pending. So if the query is in the pending state, let's just display what we have over here. And when
[01:20] it's not, so the else branch, if we have an error, then we basically display the template, the message over here. So we have the error message. And, also, if it's still not the case, then we can carry on with the
[01:40] employee listing. Now we also need to get rid of these remainings. And now we can see that basically, if it's pending, then there comes the message. If it's error, there another message. And otherwise, we need to have the data so we have the same sequence. But the difference is that we're going to see
[02:00] the input and the drop down and potentially this fetching message. So let's see how this looks like. So let's refresh the page. And the data is here, but we can also, at the same time, we can see the input and it basically doesn't show and hide. So adapt your views to your
[02:20] needs.

https://app.egghead.io/api/v1/lessons/react-use-type-narrowing-without-early-function-returns-with-react-query/transcript

https://app.egghead.io/api/v1/lessons/react-implement-a-server-side-pagination-using-react-query/subtitles

[00:00] Let's create one more piece of state. In our case, it's going to be the simple use state from react back again. The initial value is going to be 1 since the first page within this API is page number 1. It's indexed from 1, not from 0. Let's make the value page, and let's make the callback set page
[00:19] simply. And now let's also display the UI for the pagination. So we're going to have the button prev when clicked. It's going to move us to the previous page and again to the next page with the other button. And in between, let's just put the number of the current page. Now for a simple on
[00:39] click, whenever we click on the previous button, what we're going to do is we're going to set the new page value to be previous page minus 1 simply and analogically, let's put next to be p plus 1. And deliberately, for the sake of simplicity, we're ignoring all the checks whether there is
[00:59] a previous page or whether there is a next page depending on what is the number of all of the pages available, etcetera. We're just leaving this all behind. So let's see if our UI for the pagination works. And as we can see, yes, it does work. So let's take a look how can we apply this
[01:19] page setting into the HTTP function. So we have the 2nd page parameter, which is currently unused. So let's remove it from here. Let's just make the filters the only parameter that is being used. And let's also extend our search params type with a new property that is basically going to
[01:39] the page of type number. Now the default value is making TypeScript cry. So let's just put page equal 1 to be the default value for the filter. And let's copy this part since we're going to extend it as well within the employee query params on the level of
[01:59] the React query employee query definition. And here again, we are expecting that there would be one more page. So either we can make a default value on the function executing the HTTP request level like we have over here. Alternatively, we
[02:18] could also do this on this level. So it's basically a question to our design. Now this page has become a part of the key, of the query key, so there is nothing more that we should do over here. So let's now move to the component that is actually consuming
[02:38] this query. So the last thing that we should put here is basically the page parameter that is becoming the part of the query key itself. So after saving, we can see that we immediately jumped into page number 3, which is definitely what we wanted. And let's move to the previous page back again. And as we toggle
[02:58] between the 2nd and third, whatever pages, we can see that in these cases, React Query always have some data available in the other page, within the cache. So this is because I'm clicking the prev and next pretty frequently, and I'm just
[03:18] not hitting this case when GC time would remove one of the pages after 3 seconds. And as we have seen, right now, we are on page number 3, and page number 2 have been removed. So when we click previous, then it has to be fetched back again. And again, this one is being removed. But if we keep on clicking
[03:38] pretty frequently, there would be a page available within the cache. Moreover, if we cross the 15 seconds, then we would see that there would be a refetch being done in the background. But what is important, the previous value is going to be used immediately by React query, and the
[03:58] name of this behavior is stale while revalidate. So when we go back to the data that we have loaded previously, we can use the old data to display, but immediately, we are re fetching the new JSON values.

https://app.egghead.io/api/v1/lessons/react-implement-a-server-side-pagination-using-react-query/transcript

Simplify State Management with React Query

Tomasz Ducin

You might also like these resources:

Manage Application State with Jotai Atoms

React State Management Expert Interviews

Create an eCommerce Store with Next.js and Stripe Checkout

Course Content

You might also like these resources:

Manage Application State with Jotai Atoms

React State Management Expert Interviews

Create an eCommerce Store with Next.js and Stripe Checkout