Is there a good way to only cache a response if a condition is met, to avoid caching unhappy paths?

[Mystagogue]

Good day all!

I used Tanstack Query on personal projects and I was totally sold, its amazing. I have introduced it on an professional project and quickly encountered a problem.

All responses I get from multiple external services and api gateways are of the form:

type ApiGatewayResponse<T> = { status: ResponseStatus; data: T; messages: IResponseMessage[]; };

There are multiple variants but in all cases the "data" that I am interested in is a property of the body of the response and the response status here is not the http status code but a more nuanced status that is specific to API. Whether this is a good pattern for responses or not is moot as these APIs are completely outside of my control.

You may well say I should throw an error if there is a non 200 status code, but in some of these situations I want to parse the response body and know about the internal status and messages. Sometimes responses have a 200 http status code even when the inner status property is not "success". I still want react-query to present me with this data.

In these situations the possibility exists of react-query caching the unhappy path. A path where I have a body of pertinent messages that I want to present to the user but the internal status is not "success". I only want it to cache IF the internal status is "success".

I feel like I need something like an "onlyCacheIf" property on useQuery that accepts an expression that resolves to a boolean. i.e onlyCacheIf: data?.status === "success"

In truth I have a lot of ways around this but none of them I consider "elegant" and from my experience patterns like this where there is an inner status property in API responses are very common.

I was looking for advice from other people on what they would do in such a situation? I feel like I am missing something obvious?!

Thank you all for your time

[TkDodo]

I don't really understand the problem / use case, sorry. React Query is not tied to status codes. You can return a rejected promise from the queryFn even if you get a 200 status code back...

[Mystagogue]

Thanks very much for the reply! Sorry I re-read my question and it didn't make sense to me either - you know when your asking work questions on a Sunday its not going well lol! :-)

Let me give a more explicit (but contrived) example and lets forget about the HTTP status codes.

I have 3 possible responses from the same endpoint:

{
status: "success"
innerData: "some data the user wants"
}

{
status: "error"
innerData: null
}

{
status: "feedback"
innerData: "a message the user needs to see but its not the data they want"
}

then I have:

const {data, error} = useQuery({queryFn: simpleFetch, queryKey: ["userData"]});

The first response will come back as data, the second response will come back as an error. All good.

The third however is awkward. I can choose, do I treat it as an error or as data? It is a kind of error, but yet I do need to parse the innerData property and display it to the user.

Initially I created a custom error that I could attach data to, and then read it from the error returned from useQuery. However this same pattern needs to be repeated on all endpoints and I found dealing with it a little awkward.

Second I tried treating it as successful in react query and taking it from the data property. I think this worked much better in the flow of logic in various components, however the problem is now I am caching the unhappy path (the feedback response) and need to manually invalidate it.

So I feel like maybe I am missing a trick here, maybe there is a better pattern people use to handle this sort of situation.