Abdulazeez Abdulazeez Adeshina Software enthusiast, writer, food lover, and hacker.

Caching clash: useSWR() vs. react-query

8 min read 2313

useSWR Versus React-Query

Editor’s note: This post contains outdated information, and it is currently being reviewed for updates. It uses react-query v0.3 as its point of comparison. For more recent information on react-query features and capabilities, see our posts on the v1 release and the v2 release.


Storing data in our React application is mostly done through state. But what happens when the app is reloaded? The state returns to point blank, except it is filled up when the component mounts. This is usually done in the useEffect() Hook or componentDidMount() method.

The data loaded into the application’s state is mostly from an external source and repeatedly retrieved. But imagine a scenario in which the data source crashes for a moment or the network becomes slow, and as a result, our app returns a blank page without any data.

Luckily, there are two libraries that deal with the retrieval of data into cache without dealing with state: react-query and SWR. In this article, we will build a simple app to showcase the features of SWR and then compare SWR to react-query.

If you don’t what react-query is all about, read on it here. I’ll assume you are familiar with JavaScript, React, React Suspense, and JSX. Lastly, all the code in this article can be found here.


SWR, an initialism derived from stale-while-revalidate, is a React Hook library from ZEIT that retrieves data from an external source (API), stores the data into cache, and then renders the data. This is similar to what react-query does. Some of the features of SWR we’ll be looking at include data fetching and Suspense mode.

The SWR library can be installed either from Yarn or npm:

npm i swr

// or

yarn add swr

What is useSWR()?

SWR’s useSWR(key, fetcher, options) is a Hook that retrieves data asynchronously from a URL with the aid of a fetcher function, both passed as arguments to the Hook. The key argument here is the URL in string format, and the fetcher is either a function declared in the global configuration, a predefined custom function, or a function defined as the useSWR() argument.

By default, useSWR() returns the data received, a validation request state, a manual revalidate argument, and an error, if there are any. This can be easily done by setting the Hook to a destructurable object variable:

const { data, isValidating, revalidate, error } = useSWR(key, fetcher)

useSWR() features

Data fetching is useSWR()’s primary feature. Just like react-query, data fetching is done once — only when the component is to render data — unlike the traditional method of loading data every time the component is rendered.

We made a custom demo for .
No really. Click here to check it out.

Global configuration

useSWR() has a global configuration context provider that gives access to all the Hook’s options, so the options argument in the useSWR() Hook can be left blank. Here is an example of the global configuration in use:

import useSWR, { SWRConfig } from 'swr'

function Example () {
  const { data } = useSWR('http://book-api.com')
  const { data: latest } = useSWR('http://latest-books-api.com')

function App () {
  return (
        refreshInterval: 3000,
        fetcher: (...args) => fetch(...args).then(res => res.json())
      <Example />

In the code above, the global configuration provider component <SWRConfig /> gives us the opportunity to define the fetcher function so we don’t have to add it as an argument every time in our useSWR() Hook. The fetcher defined in the global configuration provider is universal for the components consuming it, i.e., wrapped under it.

Although this isn’t a mandatory step when using the Hook, it is the best approach provided the app maintains data retrieval homogeneity.

Fetching data

Fetching data with useSWR() is pretty straightforward. We’ll see from a little demo how data fetching works.

First, we define our sample component — let’s call it RocketLauncher — and store the result from our useSWR() into two destructurable variables:

function RocketLauncher() {
  const { data, error }  = useSWR('http://rocket-time.api', fetcher)

  return  (


const fetcher = url => fetch(url).then(r => r.json())

The destructurable variables contain the following:

  1. The data variable holds the data returned from the fetcher function
  2. The error variable holds whatever error is sent back from the Hook

Next, we render the data returned:

 { error ? (
      <b>There's an error: {error.message}</b>
    ) : data ? (
        {data.map(recipe => (
          <li key={rocket.id}>{rocket.name}</li>
    ) : null }

The block of code above renders the data retrieved from u``seSWR() if there’s no error returned; otherwise, a blank page is returned. We’ll get to see all these in action in the next section

Building the app

In this section, we’ll be rebuilding a recipe app formerly built with react-query in this article to demonstrate how useSWR() works. In the next section, we’ll take a look at the similarities and differences between the two.

Let’s get started.


You can get the setup process for our application from the previous article linked above since we’re simply rebuilding the app with a different library.


The next thing we’ll do is build the app’s frontend. We’ll use the global configuration so we don’t have to call fetcher every time. We’ll also enable Suspense mode in the global configuration settings.


import React, { lazy } from "react";
import ReactDOM from "react-dom";

const rootElement = document.getElementById("root");
ReactDOM.render(<App />, rootElement)

This is a basic render file. Next, we import useSWR() and the recipe components since we’ll be writing the main app component, <App />, in the index.jsx file:

import useSWR, { SWRConfig } from "swr";
import fetcher from "./fetch";

const Recipes = lazy(() => import("./components/Recipes"));
const Recipe = lazy(() => import("./components/Recipe"));

We imported useSWR alongside the global configuration context provider. Next, we’ll write our App component:

function App () {
  const [activeRecipe, setActiveRecipe] = React.useState(null);
  return (
      <h1>Fast Recipes</h1>
      <hr />
          refreshInterval: 3000,
          fetcher: fetcher,
          suspense: true
        <React.Suspense fallback={<h1> Loading ...</h1>}>
          {activeRecipe ? (
          ) : (
            <Recipes setActiveRecipe={setActiveRecipe} />

In the code above, we wrap our lazily loaded recipe components under React’s Suspense, which is also wrapped under the global configuration provider, SWRConfig.

The global configuration provider has been equipped with our fetcher function, which we will define next, so we don’t have to add the fetcher as an argument to the useSWR() Hook in the Recipe and Recipes components.


This file contains the code that retrieves data from the source passed into the useSWR() Hook in JSON format.

import fetch from "unfetch"

const fetcher = url => fetch(url).then(r => r.json())

export default fetcher;


We’ll start off by importing React and the SWR library:

import React from "react";
import useSWR from "swr";

import Button from "./Button";

Next, we’ll write the Recipe component:

export default function Recipe({ activeRecipe, setActiveRecipe }) {
  const { data } = useSWR(
    "http://localhost:8081/" + activeRecipe);
  return (
      <Button onClick={() => setActiveRecipe(null)}>Back</Button>
      <h2>ID: {activeRecipe}</h2>
      {data ? (
          <p>Title: {data.title}</p>
          <p>Content: {data.content}</p>
      ) : null}
      <br />
      <br />

The Recipe component takes two props, activeRecipe and setActiveRecipe, that are involved with the retrieval and rendering of data.

The useSWR() Hook is passed the data source URL and the data to be retrieved is stored in the data variable. The data upon retrieved is retrieved is rendered as can be seen from lines 8 to 13. The data returned is cached and won’t be retrieved when the app loads again unless there is a change in the data from the source.

It follows a mechanism of “if retrieved data is the same as what’s in the cache, render cache data; otherwise, cache the new data.”

We’ll write the Recipes component next.


The Recipes component is responsible for the rendering of the list of recipes retrieved from the data source via useSWR(). The code responsible for that is:

import React from "react";
import useSWR from "swr";
import Button from "./Button";

export default function Recipes({ setActiveRecipe }) {
  const { data: Recipes } = useSWR(`http://localhost:8081`);
  return (
        Recipes List        
      {Recipes ? Recipes.map(Recipe => (
        <p key={Recipe.title}>
            onClick={() => {
            Load Recipe
          </Button>{" "}
      )) : 'loading'}

In the component, we started off by importing React and SWR to enable us to use the useSWR() Hook.

A loading message is displayed when the data is being fetched. The useSWR() Hook is used to retrieve the list of recipes from the backend.

Next, the data retrieved from SWR is cached, mapped out from its array, and then rendered on the DOM, as can be seen from lines 12 to 23.

The code for the helper component Button follows below.


import React from "react";
export default function Button({ children, timeoutMs = 3000, onClick }) {
  const handleClick = e => {
  return (
      <button onClick={handleClick}>

Running our app

Next thing is to preview the app we’ve been building. We’ll start by running the app first without the backend to verify that a blank page will be displayed when no data is returned. From your terminal, start the React app and the backend in two different terminal consoles:

//React App
npm run start or yarn start

//Backend App
node api.js

Next, open the app on your browser with http://localhost:3000 and you should get the same page as the one in the gif below. Feel free to check the recipes one after the other, and reload the app to experience caching.

useSWR Recipes App

SWR vs. react-query

If you have followed the two articles, you will have noticed that they both perform the same functions: rendering, fetching data, and caching. However, in addition to those basic similarities, there are some differences between the two libraries.


Fetching and caching data

Both react-query and SWR are Hook libraries that fetch data remotely. These two libraries fetch data asynchronously and cache data upon retrieval and, as a result, prevents the continuous retrieval of data from the data source on every app render.

Suspense mode

Both libraries allow the use of React’s Suspense. This feature allows the app to keep the user updated while the app fetches data via either of the libraries.

Fast and reactive app state

Both libraries improve the load time and responsiveness of your app, especially when rendering data after the first time. This is due to the caching of data, which makes it readily available whenever the app needs it (even when it’s offline).

That said, there is a small difference in load time between useSWR() and react-query. useSWR() comes out on top here, 628ms to 523ms, as shown in the screencaps below.

useSWR Load Time
useSWR() load time.
React-query Load Time
react-query load time.


Although both applications are remote, data fetching, agnostic Hook libraries, they have their differences — they are written by different authors, after all. These libraries have limitations and advantages over each other. Let’s take a look at them.

Global fetcher

Unlike react-query, where we have to call the fetcher as the second argument, SWR enables us to define a global fetcher function in the configuration provider so we don’t have to import or define the fetcher function every time we need to use the useSWR() Hook.

Prefetching data

React-query has an advantage over SWR in this regard. SWR is capable of prefetching data, but it requires additional configurations, such as writing more functions and mutating them to the useEffect() Hook. In contrast, react-query has a prop handler that lets you prefetch data by setting the data ID and source without extra configurations.

GraphQL support

SWR offers greater advantage for modern apps that use GraphQL. Depending on its configuration, GraphQL can be a faster alternative to REST. In such cases where a user’s application retrieves data from a GraphQL server, SWR comes in handy.

GraphQL queries can be sent and data received, as demonstrated in this snippet from the SWR library:

import { request } from 'graphql-request'

const API = 'https://api.graph.cool/simple/v1/movies'
const fetcher = query => request(API, query)

function App () {
  const { data, error } = useSWR(
      Movie(title: "Inception") {
        actors {
  // ...

Mutating data

SWR enables update data locally while waiting for the remote source to revalidate it.


Both libraries are great for remote data fetching and can be used in React projects. SWR generally works hand in hand with Next.js, another project from the authors.

However, SWR has the major advantage due to its compatibility with GraphQL and overall speed, as these are some of the factors taken into consideration when selecting third-party libraries for (mostly large-scale) applications.

Therefore, for large-scale applications or projects that have to do with the distribution of data, SWR is preferred, while react-query is better for side projects or smaller applications.

In this article, we looked at what SWR is, the useSWR() Hook, and its features by rebuilding a recipe app previously built with react-query. We also looked at the similarities and the differences between SWR and react-query.

Lastly, you can read more on SWR and react-query, and you can see the full code for the app we built in this GitHub repo. Happy coding. ❤️

Full visibility into production React apps

Debugging React applications can be difficult, especially when users experience issues that are hard to reproduce. If you’re interested in monitoring and tracking Redux state, automatically surfacing JavaScript errors, and tracking slow network requests and component load time, try LogRocket.

LogRocket is like a DVR for web and mobile apps, recording literally everything that happens on your React app. Instead of guessing why problems happen, you can aggregate and report on what state your application was in when an issue occurred. LogRocket also monitors your app's performance, reporting with metrics like client CPU load, client memory usage, and more.

The LogRocket Redux middleware package adds an extra layer of visibility into your user sessions. LogRocket logs all actions and state from your Redux stores.

Modernize how you debug your React apps — .

Abdulazeez Abdulazeez Adeshina Software enthusiast, writer, food lover, and hacker.

9 Replies to “Caching clash: useSWR() vs. react-query”

  1. A few corrections here (I am the author of React Query):

    – React Query is also capable of the GraphQL pattern described. The syntax is only slightly different (the query markup is passed through to the fetcher, where it can then be used in the same exact way. eg.

    import { request } from ‘graphql-request’

    const QUERY = `{
    Movie(title: “Inception”) {
    actors {

    function App() {
    const { data, error } = useSWR(QUERY, () =>
    request(‘https://api.graph.cool/simple/v1/movies’, QUERY)

    – React Query is also capable of optimistically mutating data via the setQueryData function (https://github.com/tannerlinsley/react-query#setquerydata)

    – React Query automatically handles garbage collection of stale and unused query data, something that SWR does not do.

  2. More feedback (React Query author here):

    – React Query ships with a query (promise) cancellation API

    – React Query supports declarative updates to query data from mutation responses (useful when doing patch mutations)

    – React Query ships with a useIsFetching hook: https://github.com/tannerlinsley/react-query#useisfetching

    – React Query ships with custom key serializers: https://github.com/tannerlinsley/react-query#custom-query-key-serializers-experimental

    – React Query ships with better support for auto-refreshing of queries when using iframes in your apps.

    – The “speed” of each library is going to be negligible and variable depending on the latency of your requests. There is technically nothing in either library that is making them “faster” or “slower” than each other by any means. I would absolutely profile, measure and gather some better stats on why you believe one is faster than the other to support your claim.

    – SWR does not support GraphQL out of the box any more than React Query does. They merely supply an example of how to do it (I have done the same in my earlier comment above for React Query). I wouldn’t use this as a factor in comparing the technical capabilities of the two libraries, since both are simply promise-based APIs and have nothing to do with GraphQL directly.

    – I designed and built React Query around a Next.js site as well (most of the examples use Next.js to demonstrate how to use the library). I would not use this as a strength, again, simply because there is nothing about SWR’s API that makes it easier to use with Next that React Query.

    – When mentioning that you would want to use one over the other because of memory or large application size, I would still recommend React Query over SWR, given that it comes built-in with single-query and group-query invalidation (something that is less than trivial in SWR), handles garbage collection automatically for unused data (SWR could potentially become a memory leak if many different variations of queries were run over and over in the same window session. Not likely for small to medium apps, but still possible).

  3. React Query 1.0 is now out that takes much of the great things of React Query and makes them even better including:

    – usePaginatedQuery – A dedicated hook for window-like querying of paginated data or cursor-driven batches of data
    – useInfiniteQuery – A dedicated hook for accumulative querying of paginated data or cursor-driven batches of data
    – Synchronous Query Cache Reads/Writes/Upserts/Deletes
    – Improved query key matching for removing and refetching queries
    – External subscriptions to query cache updates
    – Unlimited query key length support
    – Optional Query Variables
    – onSettled callback for query and mutation hooks
    – onSuccess and onError callbacks for mutations
    – Better SSR support via config.initialData
    – config.initialData now supports passing an initializer function, similar to React.useState
    – Query status is now automatically inferred based on initialData (success for non-undefined intitial data, loading for undefined intitial data)
    – Query objects now supply an updatedAt property for making better informed decisions about synchronous cache usage
    – Overall, less over-fetching out of the box when using multiple instances of a query.
    – Added a new config.refetchOnMount that defaults to true and when set to false will disable additional instances of a query to trigger background refetches.
    – More reliable suspense support for prefetched queries and background refetching lifecycles
    – Support for errorBoundaries out of the box when using Suspense for both queries and mutations
    – Added a globalConfig.queryFnParamsFilter function that allows filtering the parameters that get sent to the query function.

    Maybe this article needs another refresh?

  4. Great! I’ll see what can be done or perhaps write a new article on what’s new in react query ( maybe ) & congrats on releasing 1.0 👍🏿

  5. Hi there, thanks for the post. Your section on GraphQL has some very misleading information in it. Specifically:

    > GraphQL is a much faster and more efficient alternative to REST.
    > In REST, you have to query the whole API to get specific data and results, which returns a whole lot of (mostly unused) data, slowing down your app.

    There’s nothing about this that is true inherently. It is true that you can use an API that was not made for your client and that may send data that you do not need. In situations where the API is out of your control (like GitHub’s, for example), there’s an argument for GraphQL. However, if your company controls both the API and the client (as is the case for many readers of your blog, I’m sure), then there’s absolutely nothing inherent about REST that makes it slower than GraphQL.

    API design is API design. You can either do it poorly or not. GraphQL solves some very specific problems for very specific types of companies and situations. It does not do the things that you’ve claimed unless there is already a problem, and, one can bet that a team that introduced the problematic REST API would not have much better luck with avoiding problems using GraphQL.

  6. You’re welcome. If you’re able, it would be great if you updated the article. As people with a voice (and a blog), we have responsibility to the development community to not mislead them and stoke the FUD (Fear, Uncertainty and Doubt) that is already present and misleading people.

    1. Hey, Tanner. We hear you. Would you be willing to write a new post so that we can eliminate the back and forth in the comments?

Leave a Reply