Skip to content
Change Log

Change Log

Please visit the SWR release page for all history releases.


Published on Sun May 15 2022.


Better React 18 Support (#1962)

This is a change of SWR's internal implementation detail. For developers that use SWR, it will just work out of the box without any changes in their apps.

Brought to you by @promer94 and @shuding, this release includes a core refactoring that improves React 18 support by adopting APIs like useSyncExternalStore and startTransition internally. Especially when rendering UIs concurrently with React 18, this new SWR version ensures stronger UI consistency.

Worth note that the current stable 1.x version of SWR still works well in React 18.

This core change isn't breaking and does not affect React <=17 apps.


Avoid using Suspense on the server-side (#1931)

When using suspense: true with SWR on the server-side (including pre-rendering in Next.js), it's now required to provide the initial data via fallbackData or fallback. This means that you can't use Suspense to fetch data on the server side as of today, but either doing fully client-side data fetching, or fetch the data via the framework (such as getStaticProps in Next.js).

While Suspense for libraries is still experimental, this behavior might change before the 2.0 stable release. More discussions can be found here: #1906.

What's Changed

New Contributors

Full Changelog:


Published on Sun Apr 17 2022.

SWR 2.0 on its way! Check for the previous 2.0 beta updates.

💖 Give feedback in discussion:


New isLoading state (#1928)

Previously, useSWR only returns a isValidating state, which is an indicator of both initial requests and automatic & manual revalidations. It includes polling requests and focus revalidations, etc.

But if you need to display an initial skeleton while loading the data, you will have to do something like

const isLoading = typeof data === 'undefined' && !error

...which is a popular pattern in the community. In this case, isValidating doesn't help much.

In this release, useSWR, useSWRInfinite and useSWRImmutable will return an extra isLoading state along with the isValidating state. They will fit to different scenarios:

function Stock() {
  const { data, isLoading, isValidating } = useSWR(STOCK_API, fetcher, {
    refreshInterval: 3000

  // If it's still loading the initial data, there is nothing to display.
  // We return a skeleton here.
  if (isLoading) return <div className="skeleton" />;

  // Otherwise, display the data and a spinner that indicates a background
  // revalidation.
  return (
      <div>AAPL ${data}</div>
      {isValidating ? <div className="spinner" /> : null}

In the example above, we display a skeleton while loading the data. After the data is loaded, we show a spinner next to the data whenever we are re-fetching (revalidating):

CleanShot 2022-04-17 at 02 40 22

You can find the full code for this example here:

New keepPreviousData option (#1929)

When doing data fetching based on continuous user actions, e.g. real-time search when typing, keeping the previous fetched data can improve the UX a lot.

In SWR 2.0, there is now a keepPreviousData option to enable that behavior. Here's a simple search UI:

function Search() {
  const [search, setSearch] = React.useState('');

  const { data, isLoading } = useSWR(`/search?q=${search}`, fetcher, {
    keepPreviousData: true

  return (
        onChange={(e) => setSearch(}

      <div className={isLoading ? "loading" : ""}>
        {data? => <Product key={} name={} />)

With keepPreviousData enabled, you will still get the previous data even if you change the SWR key and the data for the new key starts loading again. This improves the visual continuity quite a lot, the search feels smoother after flipping the switch:

You can find the full code for this example here:


Type InfiniteFetcher is renamed to SWRInfiniteFetcher (#1930)

This type was already marked as deprecated in 1.x, and it now removed in this beta. If you are using it, please do the following change:

- import { InfiniteFetcher } from 'swr/infinite'
+ import { SWRInfiniteFetcher } from 'swr/infinite'

What's Changed

Full Changelog:


Published on Mon Apr 11 2022.

SWR 2.0 coming soon, and this is the first beta version!

Keep in mind that APIs might still change until the stable release. Documentation will also be updated once stable.

💖 Give feedback in discussion:


useSWRMutation — dedicated API for remote mutations, e.g. POST (#1450)

Added in #1450, the new useSWRMutation hook covers all the use cases of: - Requests that change data on the remote side: such as POST, PUT, DELETE, etc. - Requests that need to be triggered manually, instead of automatically by SWR. - Passing extra argument to fetcher, when triggering a request. - Knowing the status of a mutation, similar to isValidating but for mutations. - A lot more...

Here's a quick example of how it looks:

import useSWRMutation from 'swr/mutation'

async function sendRequest(url, { arg }) {
  return fetch(url, {
    method: 'POST',
    body: JSON.stringify(arg)

function App() {
  const { trigger } = useSWRMutation('/api/user', sendRequest)

  return <button onClick={() => {
    trigger({ username: 'johndoe' })
  }}>Create User</button>

In this example, the "fetcher", which is sendRequest, will receive the value { username: 'johndoe' } as the arg from the second parameter. The request will only be triggered when clicking the button.

The new useSWRMutation hook is actually more powerful than this, it also supports: - Optimistic updates - Automatic error rollback - Detect and avoid race conditions between useSWR - Populate the cache of useSWR after mutation finishes - ...

More examples to come.


Fetcher no longer accepts multiple arguments (#1864)

Previously, if the key is an array, the values will be passed to the fetcher function as arguments separately. In 2.0, the key will always be passed to the fetcher as is.


// SWR 1.x
useSWR([1, 2, 3], (a, b, c) => {
  assert(a === 1)
  assert(b === 2)
  assert(c === 3)

After 2.0.0:

// SWR 2.0.0
useSWR([1, 2, 3], (a) => {
  assert(a === [1, 2, 3])

Internal structure of the cached data (#1863)

This change affects the code that directly reads/writes to the cache, or provides a cache preset. For example if you have something like cache.set(key, value), you'll have to update your code.

Previously, the cached value of key will be the associated data, so this was guaranteed:

// SWR 1.x
assert(cache.get(key) === data)

And we keep other states (error, isValidating) with a special, prefixed key. Something like '$err$' + key.

Since 2.0.0, the internal structure will be an object that holds all the current states:

// SWR 2.0.0
assert(cache.get(key) === { data, error, isValidating })

So you will have to do the following change to your code, get:

- cache.get(key)
+ cache.get(key)?.data

And set:

- cache.set(key, data)
+ cache.set(key, { ...cache.get(key), data })

What's Changed

New Contributors

Full Changelog:


Published on Sun Apr 10 2022.

What's Changed

  • type: fix type error on SWRConfig by @Himself65 in #1913
  • chore: update React 18 dependencies by @shuding in #1824
  • test: fix an act warning by @koba04 in #1888
  • feat: support functional optimisticData by @huozhi in #1861
  • bugfix: make suspense and revalidateIfStale work together by @simowe in #1851

Full Changelog:


Published on Fri Feb 18 2022.

Highlights of This Release

populateCache Option Now Supports Function

We added better Optimistic UI support in v1.2.0. However, what if your API is only returning a subset of the data (such as the mutated part), that can be populated into the cache? Usually, an extra revalidation after that mutation is needed. But now you can also use a function as populateCache to transform the mutate result into the full data:

await mutate(addTodo(newTodo), {
  optimisticData: [, newTodo],
  rollbackOnError: true,
  populateCache: (addedTodo, currentData) => {
    // `addedTodo` is what the API returns. It's not
    // returning a list of all current todos but only
    // the new added one.
    // In this case, we can transform the mutate result
    // together with current data, into the new data
    // that can be updated.
    return [...currentData, addedTodo];
  // Since the API already gives us the updated information,
  // we don't need to revalidate here.
  revalidate: false,

The new definition:

populateCache?: boolean | ((mutationResult: any, currentData: Data) => Data)

Here is a demo for it:

Bug Fixes

What's Changed

Full Changelog: