You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation handles all of the !response.ok cases by putting the response body into the error field. This makes it impossible to distinguish whether it was a 404 error (a legitimate case when the resource is not found) or some other error (i.e. a 500 error). In the first case I want to show the user a "Item not found" message, while in the other cases I probably want to show a "Error fetching the data" message and maybe log the error so that it can be fixed. Now I can only distinguish these cases by checking the content of the response, but this might be unsolvable in cases where the BE does not provide any general response for 404 responses that can be relied on.
The only workaround I found is to implement an openapi-fetch middleware and wrap the status code into the response. But this makes the expected response TS type differ from the actual enhanced type, which is quite painful.
Proposal
I am not sure what the best solution might be. The error could be an "enhanced" response body: error: { responseBody: ResponseType; responseStatus: number; }. But this introduces a nasty BC break which is probably not justifiable. Maybe if there was a configuration option to opt in for this behavior? I don't like this kind of configuration options either...
Description
The current implementation handles all of the
!response.ok
cases by putting the response body into theerror
field. This makes it impossible to distinguish whether it was a 404 error (a legitimate case when the resource is not found) or some other error (i.e. a 500 error). In the first case I want to show the user a "Item not found" message, while in the other cases I probably want to show a "Error fetching the data" message and maybe log the error so that it can be fixed. Now I can only distinguish these cases by checking the content of the response, but this might be unsolvable in cases where the BE does not provide any general response for 404 responses that can be relied on.The only workaround I found is to implement an
openapi-fetch
middleware and wrap the status code into the response. But this makes the expected response TS type differ from the actual enhanced type, which is quite painful.Proposal
I am not sure what the best solution might be. The
error
could be an "enhanced" response body:error: { responseBody: ResponseType; responseStatus: number; }
. But this introduces a nasty BC break which is probably not justifiable. Maybe if there was a configuration option to opt in for this behavior? I don't like this kind of configuration options either...Extra
The text was updated successfully, but these errors were encountered: