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

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:

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:

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

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:

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:

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!