react-query@tsnext feedback

[wolverineks]

useQuery

• why no discriminated unions? is that coming back?
• why does typeof error default to unknown? can it default to Error?
• if suspense: true, typeof data should not include undefined

useMutation

• my preference is, TResult and TVariables get inferred from mutationFn, and TError defaults to Error

[boschni]

Hi @wolverineks, thanks for giving feedback on the new types! I'll try to answer your questions below. Because typings and defaults are also a matter of taste, everything is open for debate :)

Discriminated unions
They add quite a bit of types and some complexity while in my opinion, not bringing much value:

// A common pattern is to destructure the query result, but in doing so, the unions would have no effect:
const { error, data } = useQuery()

// In case someone would use the status property to discriminate:
const result = useQuery()

if (result.status === 'idle') {
  // We already know there is no `data` or `error`
}

if (result.status === 'loading') {
  // Still need to assert `data` or `error`
}

if (result.status === 'success') {
  // Now `data` is available, but we could have also asserted `data`
}

if (result.status === 'error') {
  // Now `error` is available, but we could have also asserted `error`
}

Default error type in queries and mutations
The error type defaults to unknown because it could be anything (even on mistake):

// In this case the error would be a `string`:
const { error } = useQuery('post', () => {
  return Promise.reject('rejected')
})

// In this case the error would be an `AxiosError`:
const { error } = useQuery(['post', 1], (key, id) => {
  return axios.get(`/post/${id.toString()}`)
})

// In this case the error would be an `Error`:
const { error } = useQuery(['post', undefined], (key, id) => {
  return axios.get(`/post/${id.toString()}`)
})

I think it is good practise to actually check the error type and mimics the direction TypeScript is going: https://devblogs.microsoft.com/typescript/announcing-typescript-4-0-beta/#unknown-on-catch . You can however still explicitly define the error type or create your own useQuery wrapper to set a default type.

Suspense
Was this feature available in the current types? While technically correct, I think it would be hard to type.

[wolverineks]

Why allow typing the error?

[rubenmoya]

Hello! I'm facing the same problem, I don't mind typing the Error but that means I have to type the result too which is inferred and I'd love to keep it that way since those types come from my "repositories" and I'd love to avoid importing stuff from them in my components

[boschni]

Hi @rubenmoya! It is good practise to actually check in the component what kind of error you are dealing with:

const { error } = useQuery('key', queryFn)

if (error instanceof Error) {
  return <div>{error.message}</div>
}

But you could also create a wrapper if you want to predefine the error type:

function useMyQuery<T>(key: QueryKey, fn: QueryFunction<T>, config?: QueryConfig<T, Error>): QueryResult<T, Error> {
  return useQuery(key, fn, config)
}

[rubenmoya]

Thank you! It works like a charm ✨

[twhitbeck]

I cringe whenever I have to add runtime code to satisfy TypeScript.

[rjerue]

Is there any way to make the status be error, but the type not be error? I thought the status got set to error when the promise rejected, and the value of the rejected promise is what got passed up. I guess one could pass anything into reject even if its type isn't error.