Middleware

[shuding]

This is an implementation of #875, #172, #1030.

Middlewares

The new option config.middlewares is now supported, for example:

<SWRConfig value={{
  middlewares: [
    (useSWRNext) => (key, fn, config) => {
      console.log('fetching', key, '...')
      return useSWRNext(key, fn, config)
    }
  ]
}}>

Middlewares can be extended via multiple contexts and/or per-hook config, for example:

<SWRConfig value={{ middlewares: [A] }}>
  <SWRConfig value={{ middlewares: [B] }}>
    ...
      useSWR(..., { middlewares: [C] }
...

// Equivalent to `middlewares: [A, B, C]`.

Middlewares will be executed from inner to outer (this will be extremely helpful for custom SWR hooks that override key, fn, or config. So higher level middlewares don't need to care about the details):

<SWRConfig value={{ middlewares: [A, B, C] }}>

// C, B, A will be called successively.

Concerns

• Which key should be passed to the middlewares (original or serialized)? Original, so the middleware will have more flexibility.
• Is middlewares a good name? How about plugins/use?

Notes

This PR refactors some internal APIs such as useArgs. Those will simplify the process of building other hooks on top of SWR.

Also, the ESLint rule react/prop-types is now disabled given we have TypeScript already.

Credits to https://redux.js.org/understanding/history-and-design/middleware and #1030 (comment) for the idea and implementation discussions.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit a81bc8c:

Sandbox	Source
SWR-Basic	Configuration
SWR-States	Configuration
SWR-Infinite	Configuration
SWR-SSR	Configuration

[shuding]

I think the original key should be passed to middlewares...

[huozhi]

🚀

[koba04]

Great work 👏 👏
I've found some type errors in the middleware tests and fixed type errors and added types to middlewares in tests.

I'm also confused the behavior for multiple middlewares and modifying keys.
The following test now fails. Isn't it possible to modify keys in middlewares?

  it('should pass modified keys to the next middlewares and useSWR', async () => {
    const key = createKey()
    const createDecoratingKeyMiddleware = (c: string): Middleware => useSWRNext => (k, fn, config) => {
      return useSWRNext(`${c}${k}${c}` , fn, config)
    }
    function Page() {
      const { data } = useSWR(key, () => {
        return createResponse(key)
      }, {
        middlewares: [createDecoratingKeyMiddleware('!'), createDecoratingKeyMiddleware('#')]
      })
      return <div>hello, {data}</div>
    }

    render(<Page />)
    screen.getByText('hello,')
    await screen.findByText(`hello, #!${key}!#`) // actual: the key is not decorated
  })

[koba04]

I've also created a sample middleware for the status middleware you mentioned in #1215 (comment)

I could implement it, but it was difficult to extend the return type of useSWR (please see the @ts-ignore in the following code). so we might need to add a way to extend the SWRResponse type if SWR covers the use-case.

  it('should pass modified keys to the next middlewares and useSWR', async () => {
    const statusMiddleware: Middleware = useSWRNext => (k, fn, config) => {
      const result = useSWRNext(k, fn, config);
      return {
        ...result,
        status: result.data ? 'ready': 'fetching'
      }
    }
    function Page() {
      // @ts-ignore the status property should be typed.
      const { data, status } = useSWR('key', () => {
        return createResponse('data')
      }, {
        middlewares: [statusMiddleware]
      })
      return <div>{status}:hello, {data}</div>
    }

    render(<Page />)
    screen.getByText('fetching:hello,')
    await screen.findByText(`ready:hello, data`)
  })

[shuding]

Thanks for contributing another test case, Toru!

The following test now fails. Isn't it possible to modify keys in middlewares?

I think that's because the fetcher directly returned the original key from the outer context:

useSWR(key, () => {
  return createResponse(key)
})

If we change it to this, it will work:

useSWR(key, (k) => {
  return createResponse(k)
})

Also, the result should be !#${key}#! instead of #!${key}!#, because new middlewares will be applied first.

[shuding]

So we might need to add a way to extend the SWRResponse type if SWR covers the use-case.

Yeah absolutely. Ideally the config of custom SWR hooks should be extendable too... I don't know if there's a good way to do it with TS though.

[koba04]

I think that's because the fetcher directly returned the original key from the outer context:

I misunderstood it. Thank you!

Yeah absolutely. Ideally the config of custom SWR hooks should be extendable too... I don't know if there's a good way to do it with TS though.

The easiest way to do it is to add additional type parameters to useSWR, but I don't think it's the best way to achieve it, so I'll considering another way for it.

    function Page() {
      type CustomSWRResponse = SWRResponse<string, any> & { status: string }
      const { data, status } = useSWR<string, any, CustomSWRResponse>('key', () => {
        return createResponse('data')
      }, {
        middlewares: [statusMiddleware]
      })
      return <div>{status}:hello, {data}</div>
    }

I don't think it's a blocker to merge this, so feel free to go forward👍

[shuding]

Yeah, I think it would be very tricky to directly extend the types of key, fn, config, and return value of useSWR. Maybe for now we recommend building custom hooks on top of useSWR, which handles type issues with the custom hook itself.