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

Type of data should be a union type with undefined when a config of type SWRConfiguration is passed to useSWR #2505

Closed
connorch opened this issue Mar 14, 2023 · 3 comments

Comments

@connorch
Copy link
Contributor

connorch commented Mar 14, 2023

Bug report

Description / Observed Behavior

When passing an SWR config of type SWRConfiguration | undefined as an argument to useSWR, data in the swr response is no longer a union type with undefined (regardless of whether the swr config defined suspense: true).

Expected Behavior

I expect data in the below example to be a union type User | undefined because the hook is not running in suspense mode.

Repro Steps / Code Example

Here is a suggested test showcasing the currently failing case:

export function testUndefinedData() {
  const fetcher = (k: string) => Promise.resolve({ value: k })
  const { data } = useSWR('/api', fetcher, {} as SWRConfiguration)
  expectType<Equal<typeof data, { value: string } | undefined>>(true)
}

Additional Context

This issue was newly introduced in 2.1.0.

I have confirmed in a local test environment that it was introduced in this PR: https://github.com/vercel/swr/pull/2452/files

@nstepien
Copy link
Contributor

When doing {} as SWRConfiguration, you're asserting that the value has a different type, I wouldn't expect it to give you the correct type for {} if you assert it to be something else.
Have you tried using {} satisfies SWRConfiguration instead?

@connorch
Copy link
Contributor Author

Yeah this is a good point. Not a big deal here since we do want to trick typescript into thinking that the {} is of type SWRConfiguration, but satisfies is the safer option 👍.

This PR is merged already though so I'm unfortunately that fix would need to come in a separate PR - please feel free to submit one.

@connorch
Copy link
Contributor Author

Fixed in #2506

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

No branches or pull requests

2 participants