[RFC] Plugin / middleware

A plugin (or middleware) can extend the configuration, key, and fetcher function of SWR. With this feature we can make SWR lightweight and more customizable.

API

import swrAxios from 'swr-axios'
import useSWR from 'swr'

// ...
useSWR('key', fetcher, { use: swrAxios })

You can use multiple plugins too:

useSWR('key', fetcher, { use: [...plugins] }

Or pass them to the context:

<SWRConfig value={{ use: [...plugins] }}>

Implementation Details

swrAxios should be a function, which accepts all the params passed to the SWR hook, and return the extended ones:

function swrAxios (key, fetcher, config) {
  ...
  return [newKey, newFetcher, newConfig]
}

That way, middleware can be chained, and you will also be able to use custom configs too (because they’ll be passed to the handlers).

Ideas

• swr-fetch (with fetch polyfill, or isomorphic-fetch, etc.)
• swr-logger (middleware for logging network requests)
• swr-axios, swr-got, swr-graphql … (wrapped with custom data fetching libs)
• swr-local-storage (custom cache backend)
• swr-error-handler (e.g. redirect to /login on 404 etc.)
• swr-state (global local state)
• swr-socketio …

Related Feature Requests

• Custom fetch providers like Axios #166
• Status indicator #141
• Cancel requests #129

[koba04]

This is an interesting proposal. I don’t fully understand the goal of the middleware system. But the following also might be an option for the interface.

const plugin = next => (key, fn, config) => {
  // preprocessing
  const result = next(key, fn, config) // a chained middleware or useSWR
  // postprocessing
  return result
}

The interface, which this PR proposes, has to override the fetcher implementation in many cases like logging. Personally, I feel it seems to be more clear to be able to add plugin implementations around the original useSWR. The interface is similar to the Redux middleware, so some developers might be already familiar with it.

The following is my experimentation with the interface. https://github.com/koba04/swr/blob/a23416532c35364b54dfbb7b235176b0b61a7313/test/use-swr-middleware.test.tsx#L8-L22 It’s just proof of concept, so it doesn’t cover many cases like SWRConfig and so on.

I think it depends on the use-case what the appropriate interface for the middleware system is, so this is just an idea.

[sergiodxa]

🤔 I think I get it, I’m still unsure about having plugins support in useSWR, maybe this repo could be a monorepo as you said and have two or more libs:

• swr
• swr-axios
• swr-*

So if you want only SWR you yarn add swr, but if you want to use it with axios you could install yarn add swr swr-axios and if you want SWR with another integration you could yarn add swr swr-*.

And all of these extra packages could be custom hooks using useSWR internally (they could set swr as peer dependency too) so you don’t need custom plugins support in SWR, compose the hooks creating new hooks, this way you don’t need to add an extra feature to SWR, and you could still have a better single implementation of how to integrate SWR with Axios (and other fetching libs).

Also those swr-* could not only be here, but be in other repos, so you could publish your own wrapper around SWR to integrate it with another library, as a lot of Redux libraries did, eventually officially supported implementations could be moved to this repo or be recommended in the README.

What do you think? @o-alexandrov @quietshu

I’m mostly worry about adding a feature that could not be really necessary since hooks allow composability and specially it’s probably not going to be used by ZEIT, I like that SWR comes from ZEIT internal usage since that guarantees me you are going to keep maintaining the lib and those features.