How we implemented SWR in a project and why we loved it

Kamil Polok

Jun 09, 20216 min read

How we implemented SWR in a project and why we loved it

Table of Content

  • Why SWR?

  • What is SWR?

  • Why we loved SWR

  • How SWR works

  • Data mutation

  • SWR integrations

Why SWR?

Recently, we had the opportunity at SDH to develop a project using React with support from Redux/Toolkit. Thing is, though data was kept and fetched in the store, there was no caching mechanism implemented in the app.  And holding dozens of responses in the state is not my idea of a cool idea. Whatever the case, it soon got a little too easy to get lost in all those state slices, despite the use of Toolkit.  

What’s more, it had zero influence on the backend at that point. With those iceberg-sized chunks of data drifting about, some requests took an eternity to resolve.  And since the UI’s application consisted of long item lists with few CRUD operations,  it soon became clear that some form of cache would come in pretty handy just about then. So the choice fell to SWR - a library made by the developers of Vercel (also of Next.js fame).

What is SWR?

Ok, do you like reading definitions? I hope not, because this is going to be one of the shortest you've ever read. ‘SWR is a React Hooks library for remote data fetching’. That's it. Simple? Yes, but I will now show you that SWR is also very powerful. And in case you were wondering, SWR stands for stale-while-revalidate. Which already explains how it works. SWR returns data from cache (stale), sends a fetch request to get updated data (revalidate), then returns new data.  Like I said, simple. 

Why we loved SWR

It’s easy to recognise how using SWR eliminates problems described at the beginning of this article. Thanks to SWR, we:

  • Made the UI work perfectly (after initial data requests) thanks to caching data 
  • Removed nearly all slices holding API data and accompanying logic
  • Simplified the flow of revalidating data after making CRUD operations on data collections
  • Sped up the development of new API-dependent features

How did we actually implement this library for such magical results? 

How SWR works

After a short while of working with SWR, it proved itself to be rather simple and quite user-friendly. Fancy making an API request using SWR? Have this:

Screenshot 2023-07-21 at 16.32.34.png

The only catch is the fetcher. It’s just your custom function for fetching data. The application we worked on already had axios set up and running with its entire config (interceptors, headers, base URL, etc.), so we just wrapped our axios instance like this to get our own custom fetcher:

Screenshot 2023-07-21 at 16.32.42.png

Therefore, the entire hook could look as simple as this (let's skip error handling in this example):

Screenshot 2023-07-21 at 16.32.48.png

And... that's it! We’ve created a hook for fetching API data using all the SWR goodies. Whenever this hook is fired, it will return previously fetched data first (if present), and only then revalidate data and return new collection afterwards.

SWR out of the box comes with a handful of pre-configured parameters (all are listed here), which make working with it a piece of cake. A favorite option worth mentioning is dedupingInterval.

Typical use-case scenario: fetch data in one component, keep developing this component further, watch children grow out of control, only for a 4th level child to need the data. How you get this data into the child component without much effort whilst avoiding repeated requests is always a challenge. But fear not: simply reuse the SWR hook... The deduping interval will not allow the request to be made again within a specified amount of time (2 seconds by default). Fair enough.

"But if I call the endpoint, and it returns the same data as before, my component will still re-render". It will not: SWR implements deep comparison so re-render will only be triggered when data has actually changed. And the comparison function can, of course, be customized. 

Data mutation

But you might argue that GETting data is always easy - what about the mutating part? Surely this is more complicated. Well, not really, mutations don't have to be a nightmare, and I was surprised how easy it is to mutate data using SWR (previously having had some fun with Apollo). Here's a real-life example:

Screenshot 2023-07-21 at 16.32.54.png

In this example mutate is a function imported from SWR and /users is the key we gave it in useUsers hook (It doesn't have to be the endpoint URL - you can pass the key and URL separately).

Should you wish to cache and update a single entity (object) fetched from a bigger collection, simply mutate it by its key like so:

Screenshot 2023-07-21 at 16.33.01.png

Looks too simple? It is simple. Try it for yourself and you just may save considerable time writing extensive Redux logic and debugging your API calls.

SWR integrations

As you can see, implementing SWR is simple; with a few nice touches,  it doesn’t take much to advance the above examples to higher, more abstract levels. Obviously, SWR is not limited to this and there is a great number of options and integrations available:

graphQL integration

error handling with retry options

auto revalidation

pagination support (also for infinite loading)

data prefetching

and many more (documentation)

We found working with SWR supremely cool and will definitely consider using it for future projects. If you’d like to learn more about this awesome library, visit their official website with documentation, configs and examples here.

Happy coding!


Don't miss a beat - subscribe to our newsletter
I agree to receive marketing communication from Startup House. Click for the details

Published on June 09, 2021


Kamil Polok Front-end developer Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.

You may also highlightlike...

14 accessibility hacks to make your users’ day better
AccessibilityUX designFront-end development

14 accessibility hacks to make your users’ day better

Accessibility in app development is often overlooked, but it plays a vital role in ensuring inclusivity and improving user experience for individuals with disabilities. With approximately one billion people worldwide experiencing some form of disability, it's crucial to consider accessibility as a necessary aspect of app design and development. By incorporating accessibility features from the beginning, you not only cater to a significant user base but also create a more user-friendly and inclusive app for everyone.

Maciek Kozłowski

Dec 02, 20197 min read

Exploring the Current Version of React: Features, Upgrades, and Documentation
ReactDigital products

Exploring the Current Version of React: Features, Upgrades, and Documentation

React, the popular JavaScript library for building user interfaces, continues to evolve with each new version, introducing exciting features and improvements.

Marek Majdak

Jun 01, 20235 min read

Why do we love using Gatsby and Strapi for building websites?
Next.jsStrapiFront-end development

Why do we love using Gatsby and Strapi for building websites?

Static site generators (SSGs) and headless content management systems (CMSs) have gained popularity for creating fast, performant, and easily editable websites. By combining the power of Gatsby, a React-based static site generator, with Strapi, a flexible headless CMS built with Node.js, developers can create blazing fast websites that offer seamless content management. This article explores the concept of static sites, the role of CMSs, and how Gatsby and Strapi work together to deliver swift, customizable, and user-friendly web experiences.

Mateusz Wójcik

Feb 21, 20205 min read

Let's talk
let's talk

Let's build

something together


We highlightbuild startups from scratch.

Startup Development House sp. z o.o.

Aleje Jerozolimskie 81

Warsaw, 02-001

VAT-ID: PL5213739631

KRS: 0000624654

REGON: 364787848

Contact us

Follow us


Copyright © 2023 Startup Development House sp. z o.o.

EU ProjectsPrivacy policy