Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: suspense when key is falsy #357

Closed
wants to merge 5 commits into from

Conversation

huozhi
Copy link
Member

@huozhi huozhi commented Apr 27, 2020

Bugfix

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

@shuding
Copy link
Member

shuding commented May 3, 2020

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

@huozhi
Copy link
Member Author

huozhi commented May 3, 2020

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

src/use-swr.ts Outdated
@@ -372,7 +372,7 @@ function useSWR<Data = any, Error = any>(

// update the state if the key changed (not the inital render) or cache updated
if (
keyRef.current !== key ||
(keyRef.current !== key && (!keyRef.current && !key)) ||
Copy link
Member

@shuding shuding May 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@huozhi huozhi May 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

}

expect(
container.firstElementChild.lastElementChild.textContent
Copy link
Member Author

@huozhi huozhi May 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

shuding commented May 12, 2020

@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
Copy link
Contributor

sergiodxa commented May 12, 2020

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
Copy link
Member Author

huozhi commented May 12, 2020

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
Copy link

enzoferey commented May 20, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants