releases.shpreview
Vercel/SWR

SWR

$npx -y @buildinternet/releases show swr
Mon
Wed
Fri
AprMayJunJulAugSepOctNovDecJanFebMarApr
Less
More
Releases3Avg0/wkVersionsv2.3.7 → v2.4.0
Nov 25, 2022

The last RC before SWR 2.0. This release includes several small fixes with one breaking change.

Breaking

In this release, we are dropping IE 11 support, and using ES2018 as the build target. However, when using SWR in a framework or using a bundler (esbuild, Webpack, etc.), you can still target ES5 or using a browserlist configuration to customize this.

The benefit of this change is, we can now use faster native APIs to make SWR more performant, instead of using old alternatives. A benchmark shows a 4.7x speed improvement of the useSWR() function call during SSR, when we change Object.assign({}, a, b) to { ...a, ...b }.

Details can be found in #2249.

What's Changed

New Contributors

Full Changelog: https://github.com/vercel/swr/compare/2.0.0-rc.0...2.0.0-rc.1

Oct 5, 2022

The SWR 2.0 release candidate. This RC has one breaking change, a new option for mutation APIs, and some bug fixes & improvements.

Highlights & Breakings

A failed mutation will not cause useSWR's error to be updated:

const { error, mutate } = useSWR('/api/user', getUser)

return <button onClick={async () => {
  try {
    await mutate(updateUser)
  } catch (mutationError) {
    // `mutationError` will not cause `error` to be updated.
  }
}}>Update User</button>

In 2.0, with the example above, error will only be coming from getUser and will be shared across all useSWR('/api/user') hooks. And mutation errors (mutationError) will be coming from mutations like updateUser calls, they will be separated from fetcher errors.

There is also a new option throwOnError for useSWRMutation to disable the default throwing behavior of trigger:

const { trigger } = useSWRMutation('/api/user', updateUser)

try {
  await trigger()
} catch (err) {
  // ... it throws when failed to trigger the mutation so you can
  // easily change the flow here
}
const { trigger, error } = useSWRMutation('/api/user', updateUser, {
  throwOnError: false
})

// You don't need to try-catch here, you can instead handle errors
// on the component level in a declarative way
await trigger()

Read more about this change in #2182.

What's Changed

Full Changelog: https://github.com/vercel/swr/compare/2.0.0-beta.7...2.0.0-rc.0

Sep 12, 2022

Most changes in this release are maintenance related, as we are finalizing everything for the upcoming 2.0 stable version.

What's Changed

New Contributors

Full Changelog: https://github.com/vercel/swr/compare/2.0.0-beta.6...2.0.0-beta.7

Jul 4, 2022

What's Changed

New Contributors

Full Changelog: https://github.com/vercel/swr/compare/2.0.0-beta.5...2.0.0-beta.6

Jun 26, 2022

Highlights & Breakings

Mutate Multiple Keys (#1946, #1989)

You can now pass a filter function to the global mutate API to match any keys and mutate them together:

import { mutate } from 'swr'
// Or from the hook if you customized the cache provider:
// { mutate } = useSWRConfig()

mutate(
  key => typeof key === 'string' && key.startsWith('/api/item?id='),
  data => update(data),
  true
)

This action will match all keys starting with '/api/item?id=', and replace their data with update, then re-fetch after the mutation. The signature is the same as the current mutate API:

mutate(
  '/api/item?id=123',
  data => update(data),
  true
)

The only difference is if you pass a function instead of a specific key, SWR will use it to match and mutate all the data in the cache. It will be convenient to use this to batch updates, or mutate keys by pattern.

Worth noting that it works with any key types, too:

useSWR(['item', 123], ...)
useSWR(['item', 124], ...)
useSWR(['item', 125], ...)

mutate(
  key => Array.isArray(key) && key[0] === 'item',
  undefined,
  false
)

The mutation above will match all 3 keys and set the values to undefined (clear them), and skip the revalidation at the end. So another technique is to clear everything with this (e.g. when logging out):

mutate(
  () => true,
  undefined,
  false
)

More use cases and discussions can be found in the original RFC: #1946.

What's Changed

Full Changelog: https://github.com/vercel/swr/compare/2.0.0-beta.4...2.0.0-beta.5

Jun 18, 2022

Highlights

Preload API (#2026)

SWR now has a preload API that you can call programmatically to kick off the request early. For example, you can do preload('/api/user', fetcher) even outside of React:

import { useState } from 'react'
import useSWR, { preload } from 'swr'

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

// Preload the resource before rendering the User component below,
// this prevents potential waterfalls in your application.
// You can also start preloading when hovering the button or link, too.
preload('/api/user', fetcher)

function User() {
  const { data } = useSWR('/api/user', fetcher)
  ...
}

export default function App() {
  const [show, setShow] = useState(false)
  return (
    <div>
      <button onClick={() => setShow(true)}>Show User</button>
      {show ? <User /> : null}
    </div>
  )
}

So at the moment of clicking the button and actually rendering the User component, the resource is likely loaded already. If the request depends on some props or states, you can also preload it when hovering the button:

function App({ userId }) {
  const [show, setShow] = useState(false)
  return (
    <div>
      <button
        onClick={() => setShow(true)}
        onHover={() => preload('/api/user?id=' + userId, fetcher)}
      >
        Show User
      </button>
      {show ? <User /> : null}
    </div>
  )
}

Demo: https://codesandbox.io/s/swr-preloading-14bikv?file=/src/App.js

Function as SWRConfig value (#2024)

A new way to extend the SWR global configuration:

<SWRConfig value={{ revalidateOnFocus: false, dedupingInterval: 5000 }}>
  <div>
    <Header/>
    <SWRConfig value={config => ({ ...config, dedupingInterval: 1000 })}>
      <Main />
    </SWRConfig>
  </div>
</SWRConfig>

Where you can inherit the parent configuration and override the dedupingInterval value, but reuse the other options.

Breakings

SWRConfig.default → SWRConfig.defaultValue (#2023)

This is a currently undocumented API, but planned to go stable with the 2.0 release. You can access to SWR’s default options via the SWRConfig.defaultValue static and read-only property.

What's Changed

New Contributors

Full Changelog: https://github.com/vercel/swr/compare/2.0.0-beta.3...2.0.0-beta.4

May 15, 2022

Highlights

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.

Breakings

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: https://github.com/vercel/swr/compare/2.0.0-beta.1...2.0.0-beta.3

Apr 17, 2022

SWR 2.0 on its way! Check https://github.com/vercel/swr/releases/tag/2.0.0-beta.0 for the previous 2.0 beta updates.

💖 Give feedback in discussion: https://github.com/vercel/swr/discussions/1932.

Highlights

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):

You can find the full code for this example here: https://codesandbox.io/s/swr-isloading-v8dfpy.

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 (
    <div>
      <input
        type="text"
        value={search}
        onChange={(e) => setSearch(e.target.value)}
        placeholder="Search..."
      />

      <div className={isLoading ? "loading" : ""}>
        {data?.products.map(item => <Product key={item.id} name={item.name} />)
      </div>
    </div>
  );
}

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: https://codesandbox.io/s/swr-keeppreviousdata-fsjz3m.

Breakings

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: https://github.com/vercel/swr/compare/2.0.0-beta.0...2.0.0-beta.1

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: https://github.com/vercel/swr/discussions/1919.

Highlights

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.

Breakings

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.

Before:

// 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: https://github.com/vercel/swr/compare/1.2.2...2.0.0-beta.0

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: https://github.com/vercel/swr/compare/1.2.2...1.3.0

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: [...data, 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: https://codesandbox.io/s/swr-basic-forked-hi9svh

Bug Fixes

What's Changed

Full Changelog: https://github.com/vercel/swr/compare/1.2.1...1.2.2

Feb 2, 2022

Highlights of This Release

shouldRetryOnError accepts a function

Previously shouldRetryOnError is either true or false. Now it accepts a function that conditionally determines if SWR should retry. Here's a simple example:

const fetcher = url => fetch(url).then(res => {
  // Fetcher throws if the response code is not 2xx.
  if (!res.ok) throw res
  return res.json()
})

useSWR(key, fetcher, {
  shouldRetryOnError: (error) => {
    // We skip retrying if the API is returning 404:
    if (error.status === 404) return false
    return true
  }
})

Thanks to @sairajchouhan for contributing!

What's Changed

New Contributors

Full Changelog: https://github.com/vercel/swr/compare/1.2.0...1.2.1

Jan 26, 2022

Highlights of This Release

Optimistic Updates with Auto Error Rollback

There are now some new options in mutate:

mutate(patchUser(user), {
  optimisticData: user,
  populateCache: true,
  rollbackOnError: true,
  revalidate: true,
})

Here the cache will be immediately updated to user, the “optimistic value”. And then a request (remote mutation) is started via patchUser(user) and the response will be written to the cache. If that request fails, the original result will be rolled back safely so the optimistic value will be gone. And after all those finish, a revalidation will start to fetch the latest value.

This is extremely helpful for building the optimistic UI pattern.

You can do the same for the global mutate, just remember to pass the key. Also, the current mutate APIs stay unchanged so mutate(data, false) works the same.

Here's an example: https://codesandbox.io/s/swr-basic-forked-k5hps.

.mjs Support

SWR now has .mjs exported for bundlers that prefer this format.

This doesn’t break environments that don’t support .mjs. An alternative .esm.js and CJS bundle are also published.

You can read more about ES modules here.

What's Changed

New Contributors

Full Changelog: https://github.com/vercel/swr/compare/1.1.2...1.2.0

Jan 12, 2022

What's Changed

New Contributors

Full Changelog: https://github.com/vercel/swr/compare/1.1.2...1.2.0-beta.1

Dec 28, 2021

Highlights of This Release

Dedicated API for Optimistic Updates with Auto Rollback on Error

There are now some new options in mutate:

mutate(patchUser(user), {
  optimisticData: user,
  populateCache: true,
  rollbackOnError: true,
  revalidate: true,
})

Here the cache will be immediately updated to user, the “optimistic value”. And then a request (remote mutation) is started via patchUser(user) and the response will be written to the cache. If that request fails, the original result will be rolled back safely so the optimistic value will be gone. And after all those finish, a revalidation will start to fetch the latest value.

This is extremely helpful for building the optimistic UI pattern.

You can do the same for the global mutate, just remember to pass the key. Also, the current mutate APIs stay unchanged so mutate(data, false) works the same.

Here's an example: https://codesandbox.io/s/swr-basic-forked-k5hps.

What's Changed

Full Changelog: https://github.com/vercel/swr/compare/1.1.2...1.2.0-beta.0

Dec 26, 2021

Highlights of This Release

Use the Latest Fetcher Function

SWR will now use the latest fetcher function passed to the hook, when sending the request. Previously it uses the initial snapshotted fetcher.

Avoid Unnecessary Auto Revalidations

When refocusing on the window with state changes (like clicking a button that changes the SWR key immediately), SWR now avoids revalidations if they're not necessary. Details can be found in #1720.

New Types for useSWRInfinite

Two types for useSWRInfinite are added: SWRInfinteHook and SWRInfinteKeyLoader. You can use them to type the hook and the getKey function.

New populateCache option for mutate

A new option to control if the mutation data should be written to the cache. You can find the details in #1729.

What's Changed

New Contributors

Full Changelog: https://github.com/vercel/swr/compare/1.1.1...1.1.2

Dec 23, 2021

Highlights of This Release

1. More Tests and Better Code Coverage

We now have 23 test suits of 202 total test cases, with a 98.06% test coverage. The core files and main functionalities are now 100% covered. Kudos to @promer94 for improving it!

2. Use the Latest Fetcher Function

SWR will now use the latest fetcher function passed to the hook, when sending the request. Previously it uses the initial snapshotted fetcher.

3. Avoid Unnecessary Auto Revalidations

When refocusing on the window with state changes (like clicking a button that changes the SWR key immediately), SWR now avoids revalidations if they're not necessary. Details can be found in #1720.

4. New Types for useSWRInfinite

Two types for useSWRInfinite are added: SWRInfinteHook and SWRInfinteKeyLoader. You can use them to type the hook and the getKey function.

What's Changed

New Contributors

Full Changelog: https://github.com/vercel/swr/compare/1.1.2-beta.0...1.1.2-beta.1

Dec 15, 2021

What's Changed

New Contributors

Full Changelog: https://github.com/vercel/swr/compare/1.1.1...1.1.2-beta.0

Dec 10, 2021

Highlights of This Release

Dynamic refreshInterval

You can now pass a function as refreshInterval, to dynamically return the interval (in millisecond) til the next request, based on the current data:

useSWR('key', fetcher, {
  refreshInterval: function (data: Data | undefined) {
    if (!data) return 3000 // Initial request 
    return data.next_update
  }
})

If return 0, polling will be stopped.

What's Changed

New Contributors

Full Changelog: https://github.com/vercel/swr/compare/1.1.0...1.1.1

Nov 30, 2021

Highlights for This Release

1. Built-in & stable serialization for SWR keys

useSWR({ query: graphql`...`, variables }, fetcher)
useSWR({ query: graphql`...`, variables }, fetcher)
useSWR({ variables, query: graphql`...` }, fetcher)
// ^all recognized as the same resource

For array keys too, it's safe to do the following:

useSWR([ `...`, { variables } ], fetcher)

2. revalidateFirstPage for useSWRInfinite

This is a new added option for useSWRInfinite (defaults to true), you can use it to control if the first page should be revalidated when changing the size or doing a mutation.

3. Better TypeScript support

  • Key / arguments
  • Conditional / dependent
  • Constant keys
  • Returned data

What's Changed

New Contributors

Full Changelog: https://github.com/vercel/swr/compare/1.0.1...1.1.0

Previous12345Next
Latest
v2.4.0
Source
@vercel/swr
Tracking Since
Oct 29, 2019
Last fetched Apr 18, 2026
.json·.md·.atom