Undefined not allowed as return value of queryFn since v4

[mataslib]

Hello,

I upgraded from v3 to v4 today and was unpleasantly surprised to find that undefined is no longer an allowed return value for queryFn.

It broke my application, and while debugging I remembered that I saw this information in the migration guide.

In reference to #4910, I agree with the opinion that this is very prone to human error. It's a pity that typescript doesn't report anything wrong either.

It is quite hard to find any information on this. Why it is so, etc. I've solved this thanks to the migration guide, but I lack information on this anywhere in the documentation if I'm not looking wrong, so I think newcomers may come across this often and it should be highlighted.

For example, https://tanstack.com/query/v4/docs/react/guides/query-functions says "A query function can be literally any function that returns a promise. The promise that is returned should either resolve the data or throw an error." which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

I also wonder if undefined is forbidden for mutationFn as well, where empty-undefined response data is a common case.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Please don't take this offensively, I'm just describing my experience today. I think v3 was more developer friendly in this manner.

[TkDodo]

I've solved this thanks to the migration guide

That's what the migration guide is for - it tells you what you need to change when upgrading...

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

It is quite hard to find any information on this. Why it is so, etc.

The migration guide gives reasons for why it is necessary. If you return undefined from setQueryData, we opt out of the update now. This wasn't possible before, so you needed to:

const old = queryClient.setQueryData(key)
if (old) {
queryClient.setQueryData(key, { ...old, someNewThing })
}

so effectively, you couldn't use the functional updater in some cases. Now, you can:

queryClient.setQueryData(key, (old) => old ? ({ ...old, someNewThing }) : undefined)

as undefined lets you bail out of the update process (which would otherwise create a successful query).

It's also more streamlined with initialData:

useQuery({ queryKey, queryFn, initialData: () => someCondition ? 'foo' : undefined })

if undefined is returned from initialData, it wouldn't create the query. This was always the case, and no one would expect the query here to be in success state with undefined data. Undefined means no data so the concept is that the query cannot be "successful" if data is undefined.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Not sure why you have queries that don't return anything in the first place 🤷

I think v3 was more developer friendly in this manner.

v3 was more inconsistent. Please accept that we have to consider more use-cases than the one you're currently having and have to balance all the facts.

[camjackson]

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

I've opened a PR to update the docs: #10008

[mataslib]

Thanks for clarification. I will adapt.

Not sure why you have queries that don't return anything in the first place 🤷

Well, I used "api functions (axios/fetch)" directly as query functions. Undefined was returned when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body which resulted in undefined returned from api/query fn. Also my mutation api functions were returning undefined, as there was no need for anything else than success status. I was also following "practice" of using only undefined of undefined/null options to represent emtpy values as discussed here sindresorhus/meta#7. However it unfortunately seems, null just can not be avoided in our code in the end.

That's what the migration guide is for - it tells you what you need to change when upgrading...

Sure, migrations guide is great, I just wanted to point out that newcomers probably wouldn't read migration guide for such info since they don't have anything to migrate yet and they will probably encounter returning undefined sooner or later.

---

Is undefined forbidden for mutationFn as well? Probably is. I'm asking just to know whether mutate docs should also be updated?

[TkDodo]

when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

Also my mutation api functions were returning undefined

It's also fine for mutations, we don't have that limitation there.

[mataslib]

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

You're right, excuse me, it actually was something like 1:1 realation as /getUserNotificationConfig, which returned 200/204 with empty body until user has saved some config at least once. Since asking for existing user's config should not result in 404 as it's not client error that config wasn't saved yet.

[Queen-esther01]

I had this piece of code below as my axios request:

export const getSearch = async(searchTerm:string):Promise<any> => {
const url = new URL(`${import.meta.env.VITE_BASE_URL}?key=${import.meta.env.VITE_API_KEY}&cx=${import.meta.env.VITE_SEARCH_ID}`)
if(searchTerm !== ''){
url.searchParams.set('q', searchTerm)
}
const parsedUrl = url.toString()
//await axios.get(`${parsedUrl}`)
await axios.get(`https://pokeapi.co/api/v2/pokemon/bulbasaur`)
.then((response) => {
console.log(response.data)
return response.data
})
.catch(({ message }) => {
console.log(message)
throw new Error(message)
})
}

and this as my query hook

export const useFetchData = (searchTerm: string) => {
const { data, isLoading, isError, error } = useQuery({ queryKey: ['todos', searchTerm], queryFn: () => getSearch(searchTerm),
enabled: !!searchTerm
//enabled: false
})
return { data, isLoading, isError, error }
}

and still got the undefined not allowed as return value under the latest version. After removing the .then and .catch and used a try catch instead it worked. It seems React-Query does no longer accept the returned data inside the .then chain? data must be explicitly returned or it wont work? Perhaps, I am doing something wrong? because this has always worked for me.

[TkDodo]

It seems React-Query does no longer accept the returned data inside the .then chain?

There is no difference between async / await and .then/.catch. This is still "just javascript", and RQ wants a Promise returned. Doesn't matter how you produce it, and nothing has changed in this.

I personally think it's weird that you're combining async / await with .then / .catch in the same function. I'd stick to one way, but it shouldn't matter either way.

Feel free to show me a codesandbox reproduction where things don't work.

[suryaashish-tyke]

Then how to approach this case, where i will be getting a ReadableStream, and I dont have any thing to return

[TkDodo]

return null

[suryaashish-tyke]

And also i want the query state to be pending until the whole stream is completed. How can we achieve that!

[mataslib]

Hello,

I upgraded from v3 to v4 today and was unpleasantly surprised to find that undefined is no longer an allowed return value for queryFn.

It broke my application, and while debugging I remembered that I saw this information in the migration guide.

In reference to #4910, I agree with the opinion that this is very prone to human error. It's a pity that typescript doesn't report anything wrong either.

It is quite hard to find any information on this. Why it is so, etc. I've solved this thanks to the migration guide, but I lack information on this anywhere in the documentation if I'm not looking wrong, so I think newcomers may come across this often and it should be highlighted.

For example, https://tanstack.com/query/v4/docs/react/guides/query-functions says "A query function can be literally any function that returns a promise. The promise that is returned should either resolve the data or throw an error." which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

I also wonder if undefined is forbidden for mutationFn as well, where empty-undefined response data is a common case.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Please don't take this offensively, I'm just describing my experience today. I think v3 was more developer friendly in this manner.

[TkDodo]

I've solved this thanks to the migration guide

That's what the migration guide is for - it tells you what you need to change when upgrading...

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

It is quite hard to find any information on this. Why it is so, etc.

The migration guide gives reasons for why it is necessary. If you return undefined from setQueryData, we opt out of the update now. This wasn't possible before, so you needed to:

const old = queryClient.setQueryData(key)
if (old) {
queryClient.setQueryData(key, { ...old, someNewThing })
}

so effectively, you couldn't use the functional updater in some cases. Now, you can:

queryClient.setQueryData(key, (old) => old ? ({ ...old, someNewThing }) : undefined)

as undefined lets you bail out of the update process (which would otherwise create a successful query).

It's also more streamlined with initialData:

useQuery({ queryKey, queryFn, initialData: () => someCondition ? 'foo' : undefined })

if undefined is returned from initialData, it wouldn't create the query. This was always the case, and no one would expect the query here to be in success state with undefined data. Undefined means no data so the concept is that the query cannot be "successful" if data is undefined.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Not sure why you have queries that don't return anything in the first place 🤷

I think v3 was more developer friendly in this manner.

v3 was more inconsistent. Please accept that we have to consider more use-cases than the one you're currently having and have to balance all the facts.

[camjackson]

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

I've opened a PR to update the docs: #10008

[mataslib]

Thanks for clarification. I will adapt.

Not sure why you have queries that don't return anything in the first place 🤷

Well, I used "api functions (axios/fetch)" directly as query functions. Undefined was returned when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body which resulted in undefined returned from api/query fn. Also my mutation api functions were returning undefined, as there was no need for anything else than success status. I was also following "practice" of using only undefined of undefined/null options to represent emtpy values as discussed here sindresorhus/meta#7. However it unfortunately seems, null just can not be avoided in our code in the end.

That's what the migration guide is for - it tells you what you need to change when upgrading...

Sure, migrations guide is great, I just wanted to point out that newcomers probably wouldn't read migration guide for such info since they don't have anything to migrate yet and they will probably encounter returning undefined sooner or later.

---

Is undefined forbidden for mutationFn as well? Probably is. I'm asking just to know whether mutate docs should also be updated?

[TkDodo]

when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

Also my mutation api functions were returning undefined

It's also fine for mutations, we don't have that limitation there.

[mataslib]

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

You're right, excuse me, it actually was something like 1:1 realation as /getUserNotificationConfig, which returned 200/204 with empty body until user has saved some config at least once. Since asking for existing user's config should not result in 404 as it's not client error that config wasn't saved yet.

[Queen-esther01]

I had this piece of code below as my axios request:

export const getSearch = async(searchTerm:string):Promise<any> => {
const url = new URL(`${import.meta.env.VITE_BASE_URL}?key=${import.meta.env.VITE_API_KEY}&cx=${import.meta.env.VITE_SEARCH_ID}`)
if(searchTerm !== ''){
url.searchParams.set('q', searchTerm)
}
const parsedUrl = url.toString()
//await axios.get(`${parsedUrl}`)
await axios.get(`https://pokeapi.co/api/v2/pokemon/bulbasaur`)
.then((response) => {
console.log(response.data)
return response.data
})
.catch(({ message }) => {
console.log(message)
throw new Error(message)
})
}

and this as my query hook

export const useFetchData = (searchTerm: string) => {
const { data, isLoading, isError, error } = useQuery({ queryKey: ['todos', searchTerm], queryFn: () => getSearch(searchTerm),
enabled: !!searchTerm
//enabled: false
})
return { data, isLoading, isError, error }
}

and still got the undefined not allowed as return value under the latest version. After removing the .then and .catch and used a try catch instead it worked. It seems React-Query does no longer accept the returned data inside the .then chain? data must be explicitly returned or it wont work? Perhaps, I am doing something wrong? because this has always worked for me.

[TkDodo]

It seems React-Query does no longer accept the returned data inside the .then chain?

There is no difference between async / await and .then/.catch. This is still "just javascript", and RQ wants a Promise returned. Doesn't matter how you produce it, and nothing has changed in this.

I personally think it's weird that you're combining async / await with .then / .catch in the same function. I'd stick to one way, but it shouldn't matter either way.

Feel free to show me a codesandbox reproduction where things don't work.

[suryaashish-tyke]

Then how to approach this case, where i will be getting a ReadableStream, and I dont have any thing to return

[TkDodo]

return null

[suryaashish-tyke]

And also i want the query state to be pending until the whole stream is completed. How can we achieve that!

[mataslib]

Hello,

I upgraded from v3 to v4 today and was unpleasantly surprised to find that undefined is no longer an allowed return value for queryFn.

It broke my application, and while debugging I remembered that I saw this information in the migration guide.

In reference to #4910, I agree with the opinion that this is very prone to human error. It's a pity that typescript doesn't report anything wrong either.

It is quite hard to find any information on this. Why it is so, etc. I've solved this thanks to the migration guide, but I lack information on this anywhere in the documentation if I'm not looking wrong, so I think newcomers may come across this often and it should be highlighted.

For example, https://tanstack.com/query/v4/docs/react/guides/query-functions says "A query function can be literally any function that returns a promise. The promise that is returned should either resolve the data or throw an error." which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

I also wonder if undefined is forbidden for mutationFn as well, where empty-undefined response data is a common case.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Please don't take this offensively, I'm just describing my experience today. I think v3 was more developer friendly in this manner.

[TkDodo]

I've solved this thanks to the migration guide

That's what the migration guide is for - it tells you what you need to change when upgrading...

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

It is quite hard to find any information on this. Why it is so, etc.

The migration guide gives reasons for why it is necessary. If you return undefined from setQueryData, we opt out of the update now. This wasn't possible before, so you needed to:

const old = queryClient.setQueryData(key)
if (old) {
queryClient.setQueryData(key, { ...old, someNewThing })
}

so effectively, you couldn't use the functional updater in some cases. Now, you can:

queryClient.setQueryData(key, (old) => old ? ({ ...old, someNewThing }) : undefined)

as undefined lets you bail out of the update process (which would otherwise create a successful query).

It's also more streamlined with initialData:

useQuery({ queryKey, queryFn, initialData: () => someCondition ? 'foo' : undefined })

if undefined is returned from initialData, it wouldn't create the query. This was always the case, and no one would expect the query here to be in success state with undefined data. Undefined means no data so the concept is that the query cannot be "successful" if data is undefined.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Not sure why you have queries that don't return anything in the first place 🤷

I think v3 was more developer friendly in this manner.

v3 was more inconsistent. Please accept that we have to consider more use-cases than the one you're currently having and have to balance all the facts.

[camjackson]

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

I've opened a PR to update the docs: #10008

[mataslib]

Thanks for clarification. I will adapt.

Not sure why you have queries that don't return anything in the first place 🤷

Well, I used "api functions (axios/fetch)" directly as query functions. Undefined was returned when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body which resulted in undefined returned from api/query fn. Also my mutation api functions were returning undefined, as there was no need for anything else than success status. I was also following "practice" of using only undefined of undefined/null options to represent emtpy values as discussed here sindresorhus/meta#7. However it unfortunately seems, null just can not be avoided in our code in the end.

That's what the migration guide is for - it tells you what you need to change when upgrading...

Sure, migrations guide is great, I just wanted to point out that newcomers probably wouldn't read migration guide for such info since they don't have anything to migrate yet and they will probably encounter returning undefined sooner or later.

---

Is undefined forbidden for mutationFn as well? Probably is. I'm asking just to know whether mutate docs should also be updated?

[TkDodo]

when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

Also my mutation api functions were returning undefined

It's also fine for mutations, we don't have that limitation there.

[mataslib]

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

You're right, excuse me, it actually was something like 1:1 realation as /getUserNotificationConfig, which returned 200/204 with empty body until user has saved some config at least once. Since asking for existing user's config should not result in 404 as it's not client error that config wasn't saved yet.

[Queen-esther01]

I had this piece of code below as my axios request:

export const getSearch = async(searchTerm:string):Promise<any> => {
const url = new URL(`${import.meta.env.VITE_BASE_URL}?key=${import.meta.env.VITE_API_KEY}&cx=${import.meta.env.VITE_SEARCH_ID}`)
if(searchTerm !== ''){
url.searchParams.set('q', searchTerm)
}
const parsedUrl = url.toString()
//await axios.get(`${parsedUrl}`)
await axios.get(`https://pokeapi.co/api/v2/pokemon/bulbasaur`)
.then((response) => {
console.log(response.data)
return response.data
})
.catch(({ message }) => {
console.log(message)
throw new Error(message)
})
}

and this as my query hook

export const useFetchData = (searchTerm: string) => {
const { data, isLoading, isError, error } = useQuery({ queryKey: ['todos', searchTerm], queryFn: () => getSearch(searchTerm),
enabled: !!searchTerm
//enabled: false
})
return { data, isLoading, isError, error }
}

and still got the undefined not allowed as return value under the latest version. After removing the .then and .catch and used a try catch instead it worked. It seems React-Query does no longer accept the returned data inside the .then chain? data must be explicitly returned or it wont work? Perhaps, I am doing something wrong? because this has always worked for me.

[TkDodo]

It seems React-Query does no longer accept the returned data inside the .then chain?

There is no difference between async / await and .then/.catch. This is still "just javascript", and RQ wants a Promise returned. Doesn't matter how you produce it, and nothing has changed in this.

I personally think it's weird that you're combining async / await with .then / .catch in the same function. I'd stick to one way, but it shouldn't matter either way.

Feel free to show me a codesandbox reproduction where things don't work.

[suryaashish-tyke]

Then how to approach this case, where i will be getting a ReadableStream, and I dont have any thing to return

[TkDodo]

return null

[suryaashish-tyke]

And also i want the query state to be pending until the whole stream is completed. How can we achieve that!

[mataslib]

Hello,

I upgraded from v3 to v4 today and was unpleasantly surprised to find that undefined is no longer an allowed return value for queryFn.

It broke my application, and while debugging I remembered that I saw this information in the migration guide.

In reference to #4910, I agree with the opinion that this is very prone to human error. It's a pity that typescript doesn't report anything wrong either.

It is quite hard to find any information on this. Why it is so, etc. I've solved this thanks to the migration guide, but I lack information on this anywhere in the documentation if I'm not looking wrong, so I think newcomers may come across this often and it should be highlighted.

For example, https://tanstack.com/query/v4/docs/react/guides/query-functions says "A query function can be literally any function that returns a promise. The promise that is returned should either resolve the data or throw an error." which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

I also wonder if undefined is forbidden for mutationFn as well, where empty-undefined response data is a common case.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Please don't take this offensively, I'm just describing my experience today. I think v3 was more developer friendly in this manner.

[TkDodo]

I've solved this thanks to the migration guide

That's what the migration guide is for - it tells you what you need to change when upgrading...

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

It is quite hard to find any information on this. Why it is so, etc.

The migration guide gives reasons for why it is necessary. If you return undefined from setQueryData, we opt out of the update now. This wasn't possible before, so you needed to:

const old = queryClient.setQueryData(key)
if (old) {
queryClient.setQueryData(key, { ...old, someNewThing })
}

so effectively, you couldn't use the functional updater in some cases. Now, you can:

queryClient.setQueryData(key, (old) => old ? ({ ...old, someNewThing }) : undefined)

as undefined lets you bail out of the update process (which would otherwise create a successful query).

It's also more streamlined with initialData:

useQuery({ queryKey, queryFn, initialData: () => someCondition ? 'foo' : undefined })

if undefined is returned from initialData, it wouldn't create the query. This was always the case, and no one would expect the query here to be in success state with undefined data. Undefined means no data so the concept is that the query cannot be "successful" if data is undefined.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Not sure why you have queries that don't return anything in the first place 🤷

I think v3 was more developer friendly in this manner.

v3 was more inconsistent. Please accept that we have to consider more use-cases than the one you're currently having and have to balance all the facts.

[camjackson]

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

I've opened a PR to update the docs: #10008

[mataslib]

Thanks for clarification. I will adapt.

Not sure why you have queries that don't return anything in the first place 🤷

Well, I used "api functions (axios/fetch)" directly as query functions. Undefined was returned when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body which resulted in undefined returned from api/query fn. Also my mutation api functions were returning undefined, as there was no need for anything else than success status. I was also following "practice" of using only undefined of undefined/null options to represent emtpy values as discussed here sindresorhus/meta#7. However it unfortunately seems, null just can not be avoided in our code in the end.

That's what the migration guide is for - it tells you what you need to change when upgrading...

Sure, migrations guide is great, I just wanted to point out that newcomers probably wouldn't read migration guide for such info since they don't have anything to migrate yet and they will probably encounter returning undefined sooner or later.

---

Is undefined forbidden for mutationFn as well? Probably is. I'm asking just to know whether mutate docs should also be updated?

[TkDodo]

when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

Also my mutation api functions were returning undefined

It's also fine for mutations, we don't have that limitation there.

[mataslib]

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

You're right, excuse me, it actually was something like 1:1 realation as /getUserNotificationConfig, which returned 200/204 with empty body until user has saved some config at least once. Since asking for existing user's config should not result in 404 as it's not client error that config wasn't saved yet.

[Queen-esther01]

I had this piece of code below as my axios request:

export const getSearch = async(searchTerm:string):Promise<any> => {
const url = new URL(`${import.meta.env.VITE_BASE_URL}?key=${import.meta.env.VITE_API_KEY}&cx=${import.meta.env.VITE_SEARCH_ID}`)
if(searchTerm !== ''){
url.searchParams.set('q', searchTerm)
}
const parsedUrl = url.toString()
//await axios.get(`${parsedUrl}`)
await axios.get(`https://pokeapi.co/api/v2/pokemon/bulbasaur`)
.then((response) => {
console.log(response.data)
return response.data
})
.catch(({ message }) => {
console.log(message)
throw new Error(message)
})
}

and this as my query hook

export const useFetchData = (searchTerm: string) => {
const { data, isLoading, isError, error } = useQuery({ queryKey: ['todos', searchTerm], queryFn: () => getSearch(searchTerm),
enabled: !!searchTerm
//enabled: false
})
return { data, isLoading, isError, error }
}

and still got the undefined not allowed as return value under the latest version. After removing the .then and .catch and used a try catch instead it worked. It seems React-Query does no longer accept the returned data inside the .then chain? data must be explicitly returned or it wont work? Perhaps, I am doing something wrong? because this has always worked for me.

[TkDodo]

It seems React-Query does no longer accept the returned data inside the .then chain?

There is no difference between async / await and .then/.catch. This is still "just javascript", and RQ wants a Promise returned. Doesn't matter how you produce it, and nothing has changed in this.

I personally think it's weird that you're combining async / await with .then / .catch in the same function. I'd stick to one way, but it shouldn't matter either way.

Feel free to show me a codesandbox reproduction where things don't work.

[suryaashish-tyke]

Then how to approach this case, where i will be getting a ReadableStream, and I dont have any thing to return

[TkDodo]

return null

[suryaashish-tyke]

And also i want the query state to be pending until the whole stream is completed. How can we achieve that!

[mataslib]

Hello,

I upgraded from v3 to v4 today and was unpleasantly surprised to find that undefined is no longer an allowed return value for queryFn.

It broke my application, and while debugging I remembered that I saw this information in the migration guide.

In reference to #4910, I agree with the opinion that this is very prone to human error. It's a pity that typescript doesn't report anything wrong either.

It is quite hard to find any information on this. Why it is so, etc. I've solved this thanks to the migration guide, but I lack information on this anywhere in the documentation if I'm not looking wrong, so I think newcomers may come across this often and it should be highlighted.

For example, https://tanstack.com/query/v4/docs/react/guides/query-functions says "A query function can be literally any function that returns a promise. The promise that is returned should either resolve the data or throw an error." which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

I also wonder if undefined is forbidden for mutationFn as well, where empty-undefined response data is a common case.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Please don't take this offensively, I'm just describing my experience today. I think v3 was more developer friendly in this manner.

[TkDodo]

I've solved this thanks to the migration guide

That's what the migration guide is for - it tells you what you need to change when upgrading...

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

It is quite hard to find any information on this. Why it is so, etc.

The migration guide gives reasons for why it is necessary. If you return undefined from setQueryData, we opt out of the update now. This wasn't possible before, so you needed to:

const old = queryClient.setQueryData(key)
if (old) {
queryClient.setQueryData(key, { ...old, someNewThing })
}

so effectively, you couldn't use the functional updater in some cases. Now, you can:

queryClient.setQueryData(key, (old) => old ? ({ ...old, someNewThing }) : undefined)

as undefined lets you bail out of the update process (which would otherwise create a successful query).

It's also more streamlined with initialData:

useQuery({ queryKey, queryFn, initialData: () => someCondition ? 'foo' : undefined })

if undefined is returned from initialData, it wouldn't create the query. This was always the case, and no one would expect the query here to be in success state with undefined data. Undefined means no data so the concept is that the query cannot be "successful" if data is undefined.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Not sure why you have queries that don't return anything in the first place 🤷

I think v3 was more developer friendly in this manner.

v3 was more inconsistent. Please accept that we have to consider more use-cases than the one you're currently having and have to balance all the facts.

[camjackson]

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

I've opened a PR to update the docs: #10008

[mataslib]

Thanks for clarification. I will adapt.

Not sure why you have queries that don't return anything in the first place 🤷

Well, I used "api functions (axios/fetch)" directly as query functions. Undefined was returned when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body which resulted in undefined returned from api/query fn. Also my mutation api functions were returning undefined, as there was no need for anything else than success status. I was also following "practice" of using only undefined of undefined/null options to represent emtpy values as discussed here sindresorhus/meta#7. However it unfortunately seems, null just can not be avoided in our code in the end.

That's what the migration guide is for - it tells you what you need to change when upgrading...

Sure, migrations guide is great, I just wanted to point out that newcomers probably wouldn't read migration guide for such info since they don't have anything to migrate yet and they will probably encounter returning undefined sooner or later.

---

Is undefined forbidden for mutationFn as well? Probably is. I'm asking just to know whether mutate docs should also be updated?

[TkDodo]

when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

Also my mutation api functions were returning undefined

It's also fine for mutations, we don't have that limitation there.

[mataslib]

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

You're right, excuse me, it actually was something like 1:1 realation as /getUserNotificationConfig, which returned 200/204 with empty body until user has saved some config at least once. Since asking for existing user's config should not result in 404 as it's not client error that config wasn't saved yet.

[Queen-esther01]

I had this piece of code below as my axios request:

export const getSearch = async(searchTerm:string):Promise<any> => {
const url = new URL(`${import.meta.env.VITE_BASE_URL}?key=${import.meta.env.VITE_API_KEY}&cx=${import.meta.env.VITE_SEARCH_ID}`)
if(searchTerm !== ''){
url.searchParams.set('q', searchTerm)
}
const parsedUrl = url.toString()
//await axios.get(`${parsedUrl}`)
await axios.get(`https://pokeapi.co/api/v2/pokemon/bulbasaur`)
.then((response) => {
console.log(response.data)
return response.data
})
.catch(({ message }) => {
console.log(message)
throw new Error(message)
})
}

and this as my query hook

export const useFetchData = (searchTerm: string) => {
const { data, isLoading, isError, error } = useQuery({ queryKey: ['todos', searchTerm], queryFn: () => getSearch(searchTerm),
enabled: !!searchTerm
//enabled: false
})
return { data, isLoading, isError, error }
}

and still got the undefined not allowed as return value under the latest version. After removing the .then and .catch and used a try catch instead it worked. It seems React-Query does no longer accept the returned data inside the .then chain? data must be explicitly returned or it wont work? Perhaps, I am doing something wrong? because this has always worked for me.

[TkDodo]

It seems React-Query does no longer accept the returned data inside the .then chain?

There is no difference between async / await and .then/.catch. This is still "just javascript", and RQ wants a Promise returned. Doesn't matter how you produce it, and nothing has changed in this.

I personally think it's weird that you're combining async / await with .then / .catch in the same function. I'd stick to one way, but it shouldn't matter either way.

Feel free to show me a codesandbox reproduction where things don't work.

[suryaashish-tyke]

Then how to approach this case, where i will be getting a ReadableStream, and I dont have any thing to return

[TkDodo]

return null

[suryaashish-tyke]

And also i want the query state to be pending until the whole stream is completed. How can we achieve that!

[mataslib]

Hello,

I upgraded from v3 to v4 today and was unpleasantly surprised to find that undefined is no longer an allowed return value for queryFn.

It broke my application, and while debugging I remembered that I saw this information in the migration guide.

In reference to #4910, I agree with the opinion that this is very prone to human error. It's a pity that typescript doesn't report anything wrong either.

It is quite hard to find any information on this. Why it is so, etc. I've solved this thanks to the migration guide, but I lack information on this anywhere in the documentation if I'm not looking wrong, so I think newcomers may come across this often and it should be highlighted.

For example, https://tanstack.com/query/v4/docs/react/guides/query-functions says "A query function can be literally any function that returns a promise. The promise that is returned should either resolve the data or throw an error." which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

I also wonder if undefined is forbidden for mutationFn as well, where empty-undefined response data is a common case.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Please don't take this offensively, I'm just describing my experience today. I think v3 was more developer friendly in this manner.

[TkDodo]

I've solved this thanks to the migration guide

That's what the migration guide is for - it tells you what you need to change when upgrading...

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

It is quite hard to find any information on this. Why it is so, etc.

The migration guide gives reasons for why it is necessary. If you return undefined from setQueryData, we opt out of the update now. This wasn't possible before, so you needed to:

const old = queryClient.setQueryData(key)
if (old) {
queryClient.setQueryData(key, { ...old, someNewThing })
}

so effectively, you couldn't use the functional updater in some cases. Now, you can:

queryClient.setQueryData(key, (old) => old ? ({ ...old, someNewThing }) : undefined)

as undefined lets you bail out of the update process (which would otherwise create a successful query).

It's also more streamlined with initialData:

useQuery({ queryKey, queryFn, initialData: () => someCondition ? 'foo' : undefined })

if undefined is returned from initialData, it wouldn't create the query. This was always the case, and no one would expect the query here to be in success state with undefined data. Undefined means no data so the concept is that the query cannot be "successful" if data is undefined.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Not sure why you have queries that don't return anything in the first place 🤷

I think v3 was more developer friendly in this manner.

v3 was more inconsistent. Please accept that we have to consider more use-cases than the one you're currently having and have to balance all the facts.

[camjackson]

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

I've opened a PR to update the docs: #10008

[mataslib]

Thanks for clarification. I will adapt.

Not sure why you have queries that don't return anything in the first place 🤷

Well, I used "api functions (axios/fetch)" directly as query functions. Undefined was returned when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body which resulted in undefined returned from api/query fn. Also my mutation api functions were returning undefined, as there was no need for anything else than success status. I was also following "practice" of using only undefined of undefined/null options to represent emtpy values as discussed here sindresorhus/meta#7. However it unfortunately seems, null just can not be avoided in our code in the end.

That's what the migration guide is for - it tells you what you need to change when upgrading...

Sure, migrations guide is great, I just wanted to point out that newcomers probably wouldn't read migration guide for such info since they don't have anything to migrate yet and they will probably encounter returning undefined sooner or later.

---

Is undefined forbidden for mutationFn as well? Probably is. I'm asking just to know whether mutate docs should also be updated?

[TkDodo]

when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

Also my mutation api functions were returning undefined

It's also fine for mutations, we don't have that limitation there.

[mataslib]

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

You're right, excuse me, it actually was something like 1:1 realation as /getUserNotificationConfig, which returned 200/204 with empty body until user has saved some config at least once. Since asking for existing user's config should not result in 404 as it's not client error that config wasn't saved yet.

[Queen-esther01]

I had this piece of code below as my axios request:

export const getSearch = async(searchTerm:string):Promise<any> => {
const url = new URL(`${import.meta.env.VITE_BASE_URL}?key=${import.meta.env.VITE_API_KEY}&cx=${import.meta.env.VITE_SEARCH_ID}`)
if(searchTerm !== ''){
url.searchParams.set('q', searchTerm)
}
const parsedUrl = url.toString()
//await axios.get(`${parsedUrl}`)
await axios.get(`https://pokeapi.co/api/v2/pokemon/bulbasaur`)
.then((response) => {
console.log(response.data)
return response.data
})
.catch(({ message }) => {
console.log(message)
throw new Error(message)
})
}

and this as my query hook

export const useFetchData = (searchTerm: string) => {
const { data, isLoading, isError, error } = useQuery({ queryKey: ['todos', searchTerm], queryFn: () => getSearch(searchTerm),
enabled: !!searchTerm
//enabled: false
})
return { data, isLoading, isError, error }
}

and still got the undefined not allowed as return value under the latest version. After removing the .then and .catch and used a try catch instead it worked. It seems React-Query does no longer accept the returned data inside the .then chain? data must be explicitly returned or it wont work? Perhaps, I am doing something wrong? because this has always worked for me.

[TkDodo]

It seems React-Query does no longer accept the returned data inside the .then chain?

There is no difference between async / await and .then/.catch. This is still "just javascript", and RQ wants a Promise returned. Doesn't matter how you produce it, and nothing has changed in this.

I personally think it's weird that you're combining async / await with .then / .catch in the same function. I'd stick to one way, but it shouldn't matter either way.

Feel free to show me a codesandbox reproduction where things don't work.

[suryaashish-tyke]

Then how to approach this case, where i will be getting a ReadableStream, and I dont have any thing to return

[TkDodo]

return null

[suryaashish-tyke]

And also i want the query state to be pending until the whole stream is completed. How can we achieve that!

[mataslib]

Hello,

I upgraded from v3 to v4 today and was unpleasantly surprised to find that undefined is no longer an allowed return value for queryFn.

It broke my application, and while debugging I remembered that I saw this information in the migration guide.

In reference to #4910, I agree with the opinion that this is very prone to human error. It's a pity that typescript doesn't report anything wrong either.

It is quite hard to find any information on this. Why it is so, etc. I've solved this thanks to the migration guide, but I lack information on this anywhere in the documentation if I'm not looking wrong, so I think newcomers may come across this often and it should be highlighted.

For example, https://tanstack.com/query/v4/docs/react/guides/query-functions says "A query function can be literally any function that returns a promise. The promise that is returned should either resolve the data or throw an error." which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

I also wonder if undefined is forbidden for mutationFn as well, where empty-undefined response data is a common case.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Please don't take this offensively, I'm just describing my experience today. I think v3 was more developer friendly in this manner.

[TkDodo]

I've solved this thanks to the migration guide

That's what the migration guide is for - it tells you what you need to change when upgrading...

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

It is quite hard to find any information on this. Why it is so, etc.

The migration guide gives reasons for why it is necessary. If you return undefined from setQueryData, we opt out of the update now. This wasn't possible before, so you needed to:

const old = queryClient.setQueryData(key)
if (old) {
queryClient.setQueryData(key, { ...old, someNewThing })
}

so effectively, you couldn't use the functional updater in some cases. Now, you can:

queryClient.setQueryData(key, (old) => old ? ({ ...old, someNewThing }) : undefined)

as undefined lets you bail out of the update process (which would otherwise create a successful query).

It's also more streamlined with initialData:

useQuery({ queryKey, queryFn, initialData: () => someCondition ? 'foo' : undefined })

if undefined is returned from initialData, it wouldn't create the query. This was always the case, and no one would expect the query here to be in success state with undefined data. Undefined means no data so the concept is that the query cannot be "successful" if data is undefined.

I solved this with axios intercepting every response and replacing undefined with null. Is this correct way?

Not sure why you have queries that don't return anything in the first place 🤷

I think v3 was more developer friendly in this manner.

v3 was more inconsistent. Please accept that we have to consider more use-cases than the one you're currently having and have to balance all the facts.

[camjackson]

which is not entirely accurate. The function must not return undefined in the promise which is a pretty significant detail.

please create a PR to the docs to clarify this.

I've opened a PR to update the docs: #10008

[mataslib]

Thanks for clarification. I will adapt.

Not sure why you have queries that don't return anything in the first place 🤷

Well, I used "api functions (axios/fetch)" directly as query functions. Undefined was returned when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body which resulted in undefined returned from api/query fn. Also my mutation api functions were returning undefined, as there was no need for anything else than success status. I was also following "practice" of using only undefined of undefined/null options to represent emtpy values as discussed here sindresorhus/meta#7. However it unfortunately seems, null just can not be avoided in our code in the end.

That's what the migration guide is for - it tells you what you need to change when upgrading...

Sure, migrations guide is great, I just wanted to point out that newcomers probably wouldn't read migration guide for such info since they don't have anything to migrate yet and they will probably encounter returning undefined sooner or later.

---

Is undefined forbidden for mutationFn as well? Probably is. I'm asking just to know whether mutate docs should also be updated?

[TkDodo]

when there was no record found for id eg. GET /someResource/${id} returned 404 Not Found with empty body

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

Also my mutation api functions were returning undefined

It's also fine for mutations, we don't have that limitation there.

[mataslib]

404 Not Found in axios rejects the Promise, so you would get a query in error state, not success state. There, it's fine.

You're right, excuse me, it actually was something like 1:1 realation as /getUserNotificationConfig, which returned 200/204 with empty body until user has saved some config at least once. Since asking for existing user's config should not result in 404 as it's not client error that config wasn't saved yet.

[Queen-esther01]

I had this piece of code below as my axios request:

export const getSearch = async(searchTerm:string):Promise<any> => {
const url = new URL(`${import.meta.env.VITE_BASE_URL}?key=${import.meta.env.VITE_API_KEY}&cx=${import.meta.env.VITE_SEARCH_ID}`)
if(searchTerm !== ''){
url.searchParams.set('q', searchTerm)
}
const parsedUrl = url.toString()
//await axios.get(`${parsedUrl}`)
await axios.get(`https://pokeapi.co/api/v2/pokemon/bulbasaur`)
.then((response) => {
console.log(response.data)
return response.data
})
.catch(({ message }) => {
console.log(message)
throw new Error(message)
})
}

and this as my query hook

export const useFetchData = (searchTerm: string) => {
const { data, isLoading, isError, error } = useQuery({ queryKey: ['todos', searchTerm], queryFn: () => getSearch(searchTerm),
enabled: !!searchTerm
//enabled: false
})
return { data, isLoading, isError, error }
}

and still got the undefined not allowed as return value under the latest version. After removing the .then and .catch and used a try catch instead it worked. It seems React-Query does no longer accept the returned data inside the .then chain? data must be explicitly returned or it wont work? Perhaps, I am doing something wrong? because this has always worked for me.

[TkDodo]

It seems React-Query does no longer accept the returned data inside the .then chain?

There is no difference between async / await and .then/.catch. This is still "just javascript", and RQ wants a Promise returned. Doesn't matter how you produce it, and nothing has changed in this.

I personally think it's weird that you're combining async / await with .then / .catch in the same function. I'd stick to one way, but it shouldn't matter either way.

Feel free to show me a codesandbox reproduction where things don't work.

[suryaashish-tyke]

Then how to approach this case, where i will be getting a ReadableStream, and I dont have any thing to return

[TkDodo]

return null

[suryaashish-tyke]

And also i want the query state to be pending until the whole stream is completed. How can we achieve that!