fix: suspense when key is falsy

[huozhi]

Bugfix

• try to solve issue SWR should suspense when key is falsey #339

When previous and current key are both not falsy while detecting the key change, schedule a rerender

[shuding]

I think generally just !key should be OK. It also covers other falsy values like ''.

[huozhi]

@shuding I've made it simpler with !key, ty!

[shuding]

I don’t know why the tests passed, but shouldn’t this be

(keyRef.current && key)

?

However it still confuses me that when key is falsy, the effect will end early from line 361.

[huozhi]

good catch here. the previous test didn't really match the behavior so I removed it. I thought the condition was missed there but actually line 361 has already filtered it out.

[huozhi]

since <Suspense> might render inline styles onto children, then the html will look like

<div style="display: none !important">10</div>
<div>fallback</div>

so I always queried the content of last element child here. it would be wether the fallback div or the children with returned data.

@shuding I'm not sure if it's sth I implemented incorrectly or there's any other elegant way to work around. other suspense test cases seem don't have this problem

[shuding]

@huozhi @sergiodxa

I recently realized that this issue (#339) is more tricky than I thought, that:

useSWR(null, { suspense: true })

is an "anti-pattern". Theoretically, we should return empty data if key is null (because the data fetching just "ended" immediately). We don't have any choice.

However, that breaks the "rule" that SWR synchronously reads data with Suspense.

That said, there's no easy way to avoid this:

const [ready, setReady] = useState(false)
const { data } = useSWR(ready ? '/api' : null, { suspense: true })  // <- we can't throw promise here!
useEffect(() => { setReady(true) }, [])
console.log(data)

We can't throw a promise on line 2, otherwise this component will never mount, and we will never reach line 4. And if we return empty data on line 2 if key is null, line 4 will output undefined.

[sergiodxa]

That makes sense. I think we should discourage that usage then? Maybe document how to lift the state up you may need? So you never pass null as key with suspense

[huozhi]

agree to leave it as current behavior. throwing promise truly breaks the how swr works.
#266 (comment) mentioned that user could probably wrap another layer on top of swr to make it really suspended when key is falsy. i.e.

const useSuspensedSWR = (key, fetcher, options) => {
   // ..customized logic, maybe handle arguments overloading
   if (options && options.suspense && !key) {
       throw new Promise(() => {})
   }
   // ..customized logic
   useSwr(key, fetcher, options)
}

this PR can be closed. or if there any other solution could be addressed I'd love to help and update PR.

[enzoferey]

Then, what would be the recommended way of doing conditional and dependent fetching in Suspense ? Creating N nested Suspense contexts is not really what we would like I believe.

#168 seems to help, but not sure what are the plans with it.