[RFC] Less misleading useSWR signature

[SevenOutman]

The problem

Current signature of useSWR(key, fetcher) allows user to define key and fetcher associations per useSWR call, which can be misleading and error-prone.

Assume we call useSWR with the same key and different fetchers like this (as the signature allows):

// Component A
const { data } = useSWR(key, () => dataA)

// Component B
const { data } = useSWR(key, () => dataB)

The data in Component A can be either dataA or dataB depending on how Component B is used, vice versa. This makes the fetcher arg in useSWR meaningless, because it does not reflect what's data actually going to be.

Deeper reason

1. Given the cache regarded as the single source-of-truth of useSWR data, a resource identified by a given key should have only one fetcher associated, which defines how that resource should be populated in the cache
2. useSWR is not the place for defining this association, but for declaring a subscription to a resource in the cache identified by the given key. Unlike the one-and-only fetcher for a resource, there can be multiple different subscriptions at the same time.

This one-to-one-to-many relation (fetcher-cache-subscriptions) bears this fixed conclusion - defining fetcher vs subscriptions are two separate things.

Current signature useSWR(key, fetcher) brings the convenience of not having to declare the fetcher separately but right when it comes to you that you need to read a resource. But it also brings ambiguity in the long run - it's less obvious to the user that useSWR is not registering the fetcher (well, it currently is but it should not be) but creating a subscription to the resource in the cache.

This proposal

The core of this proposal is to disallow the anti-pattern of defining key-fetcher association per useSWR call. There're two approaches accordingly:

Approach 1: only allow key at useSWR call and define fetcher elsewhere

First, useSWR should not allow to define key-fetcher association in-place, but only accept arguments around which resource to subscribe and how the subscription is fed.

const { data } = useSWR(key, options)

Second, define the key-fetcher association globally or per cache instance. This can mostly be done with a global fetcher.

<SWRConfig
  value={{
    fetcher
  }}
/>

With this approach, there would be few more steps to kick-off swr in a project than what swr is offering now, but we already know that splitting app state management from the component tree is a laborious (yet good) practice to adopt.

Approach 2: fetcher as key

Allowing passing the fetcher itself along with its arguments as resource key keeps things straight-forward as it is today, while address the problem around key-fetcher associations.

const { data: user1 } = useSWR([fetchUser, { id: 1 }], options)
const { data: user2 } = useSWR([fetchUser, { id: 2 }], options)

Possible implementation

As we can already serialize an array of generic values as key stably, use a Map/WeakMap to map fetchers to a set of serialized arguments it's called with

Map {
  fetcher1 -> Map {
    args1 -> cached data11
    args2 -> cached data12
  }
  fetcher2 -> Map {
    args1 -> cached data21
    args2 -> cached data22
  }
}

---

This is just a rough idea, please remind me if I'm missing anything.

[Retrospection]

Cloud go deeper in the reason why there are some situations that may use the same key but different fetcher?

In my opinion, SWR requires you claim all dependency clearly in the key to match specific fetcher, and it make efforts to develop a serialization method to achieve this.

[SevenOutman]

We don't usually need to set different fetchers. What I'm trying to say is that the API could be misleading by allowing users to do so.

[Retrospection]

For me, I treat the swr signature as a remote cache map, which the key is just like the hashmap key, and the fetcher is just like some value associated to the hashed key.

I'm not very sure whether the swr is designed to match this mental model, but it is useful for me which cannot lead to misleading use.