Stable hash

[shuding]

This PR adds stable value hash, which is used in key serialization and value comparison. A potential optimization is to memorize hashed result in a weak map to avoid recomputing. (It's added!)

Limitation (changed behavior):

• If you have Symbols in key/value, they were using strong comparison (===). With this PR Symbols have to be serialized before comparing, meaning these are all equal: Symbol('foo') === Symbol('foo') === Symbol.for('foo'). This is blocked by the issue that Symbols can't be used as WeakMap/WeakRef keys.

New feature:

• Stable key comparison: don't need memo for useSWR([{a:1}])
• Object as key: useSWR({a:1})

[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 b6060f4:

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

[promer94]

i noticed that you changed some === to ==.
what is the purpose of these changes ? 🤔

[shuding]

Just for saving a couple of bytes, since some comparisons won't have type casting involved like typeof will always return a string.

[huozhi]

Looks great! hash a == hash b for comparing is so smart 👍

[shuding]

🎉

[nandorojo]

Out of curiosity, why change the functions to arrow functions? Just for consistency?

[shuding]

Yeah mostly for consistency and easier type definitions.

[nandorojo]

Got it.

Re: stable object keys, are these two formats equivalent?

const user = { id: 'fernando' }

useSWR(user, key => getUser(key))
useSWR(user, () => getUser(user))

In the first case, I get the actual key as an argument, whereas in the second, I'm passing it from the outer scope.

The second case is what's recommended by React Query, and has somewhat better type safety. The first case requires manually casting types to the key variable.

I'm not sure if the second method works properly or not, though.

[shuding]

They work exactly the same, since you’re using user as the key. 👍

The good part about the first is it doesn’t have outside dependency which is cleaner. But yeah the second one has type benefits. SWR doesn’t have a recommendation here and they work the same.

[nandorojo]

Sounds good. FWIW, it would be fairly easy to make the fetcher infer the type of the key. I’m happy to look into implementing this.

[shuding]

@nandorojo I spent a couple of hours on that but didn't come up with a good solution that works for tuples, unless we add another generic parameter. For example:

type SWRHook<T> = (key: T, fetcher: (...args: T) => any)

And then useSWR(['', 0], (a, b) => {}), both a and b will be inferred as string | number. But in the ideal case a should be a string and b should be a number. I wonder if there is any trick for that...

[nandorojo]

I'll see if I can come up with something.

Is adding another generic an option? If we make the generic extend readonly tuple (among other options) that might do it.

Another alternative is writing ['', 1] as const. Not great, but better than no type support.

[promer94]

And then useSWR(['', 0], (a, b) => {}), both a and b will be inferred as string | number

This is a limitation of Typescript 3.9. You have to upgrade to typescript 4 to get batter tuple infer

We used to talk about this at #572

[shuding]

We should absolutely upgrade to the latest TypeScript. 👍