SWR: Frontend Data Fetching and Caching
From the recently published Tech Radar vol.24, we can see ThoughtWorks has moved SWR from Assess to Trial, which means this technology is worth pursuing. In this article, I want to share why we should try SWR and what we have to pay attention to when using SWR.
For whom is this article written?
Frontend developers. It is an article about a good pattern of fetching and caching data for a SPA. You may know some other ways of fetching and then caching data. SWR is one strategy which worth a try.
Experience designers. In my daily work with XDs, I find that XDs always have a much better sense of static UI design. But for something out of a single frame, UI developers have more insights on accessibility, performance, and some techniques for better interaction with other systems. As we all know, waiting is a factor of user experience, and we can hardly design it in a UI prototype. Thus, as an action to reduce waiting anxiety, caching is a topic that deserves an XD to communicate with the UI developers.
This article is also for other roles in a product development team. It’s meaningful for a server developer to know how a client keep data synced. And a QA should understand what the quality weakness of SWR is.
The most straightforward model of data fetching
Before all, let’s think about how a SPA can fetch data from an API endpoint and then render it in UI.
First, we send a request and wait for a response. We know it could take a few seconds. After we get the response, we need to update the UI state and trigger a rerender. Let’s draw a sequence chart below to understand better what happens in a data fetch.
It’s a good data fetch model, easy-to-implement, and does work well on many small websites. We always get fresh data upon entering the page based on this model. However, we can imagine visitors need to repeatedly watch the loading animation if they frequently visit this page.
How can we improve user experience by applying cache?
Fortunately, instead of fetching data from a remote server, there is a much faster way to get what we need. We can store the data in memory or disk to make it rendered immediately. People often call this action cache.
After caching the data, the loading phase is too short to feel. That’s cool. However, users still need to wait for data loading at their first visit. The prefetch technique can speed it up. Prefetch is a data fetch that happens before a user intentionally visits that data. Overall, we can reduce so much waiting time if using cache and some other techniques based on it.
Another advantage cache brings to us is the reliability improvement under an unstable network connection. Because of the cache, the page has already got the data it needs, regardless of the back-end server’s response quality.
But, a cache is not always reliable. Different from our simplest fetch model, the most apparent issue of cache is the data expiration. Thus, it’s not clever to store the data in a cache and never update the data. Think about the scenario of modifying user profiles — it’s so odd if we don’t update the profile appearing in other pages after a user modifies it. The solution is to combine data fetch and cache strategies.
To make the page aware of whether it needs to fetch the latest data or just read from the cache, we can set a cache’s max-age. When data exceeds its max-age, we fetch a new one and replace it. The picture below shows the logic of this strategy.
For now, we’ve got an excellent SPA web page — it saves much data traffic time and users don’t need to suffer from loading animation once opening a page. However, figuring out the appropriate max-age is not easy work, and if data is expired, it still presents a loading period.
SWR provides a comprehensive solution with an amiable design.
Stale-While-Revalidate Strategy
SWR stands for Stale-While-Revalidate. That means it returns a cached value first to make the UI render instantly, while it also revalidates the data (fetch the latest data and compare the difference) and updates the state if there is any change.
Although it still has a similar concept of max-age to cancel following revalidations which happens within a short time, it is safe to set a small value because users can’t see any UI change if there is no data difference.
SWR also works well under an unstable network environment. Compared with a long loading time, displaying stale data can reduce anxiety, and SWR can revalidate at network condition recovery. By default, most major implementation of SWR revalidates data when the component is focused. This design aims to keep the data synced with the remote server and only when necessary.
It’s also worth mentioning that since SWR is about cache, direct cache mutation is sometimes required. When a user modifies his profile, it is evident that the profile data cached is out of date. It will be better to mark this cached data obsolete and force it to revalidate data, or we can overwrite the cache directly when we foresee the response update of some endpoints.
And again, SWR is more about cache strategy than sending requests, so SWR is compatible with multiple data fetch techniques. Besides standard Fetch API and some other HTTP request libraries like Axios, it should also support different key-based queries, including GraphQL and even cloud function invoke. We use the keys for indexing the cached data, and per query technique, the key may have distinct formats.
SWR implementations
For now, several libraries support SWR. Here is a list of the top ones.
- SWR — A lightweight React Hooks library for SWR, created by the same team behind the famous framework Next.js.
- React Query — Most powerful data fetch library for React. Here is the libraries’ detailed comparison maintained by React Query team: https://react-query.tanstack.com/comparison#_top.
- swrv — A Vue port of React’s SWR using composition API of Vue3.
- Apollo — Actually, not an implementation of SWR, but it supports similar features based on fashionable GraphQL.
Cautions
We benefit from caching but should be cautious with caching.
When working with SWR, always treat data query as a read of cache. That means the data we get immediately does not always represent the truth from the server. Feel free to skip SWR and fetch data directly when the out-of-date data is not tolerable.
And, we should not assume our component can always get data immediately from the cache. For a key that you never queried before, including queries on the previous render or by prefetch, SWR can only respond with an undefined value if no initial value is given. In that case, some state transition like the loading animation is still necessary, and we should also not forget this scenario in tests.
