Responses are a union of possible operations response types #3
Conversation
|
I think the best solution to this would if would could make the types smart enough so that you could narrow on the type, many APIs have a single response type per status. I spent some time trying to do this, but it made my brain hurt 😄. |
| : 'default' extends keyof T | ||
| ? T['default'] | ||
| : unknown | ||
| type _OpReturnType<T> = keyof T extends number | 'default' ? T[keyof T] : never |
There was a problem hiding this comment.
doesn't this include all the error types as well?
There was a problem hiding this comment.
I believe so, that's the point of this PR, currently you can write code that doesn't handle error cases and typescript won't catch it.
|
how do you narrow it down, though, is the status code in |
This is what I was hoping to do, I have a branch where I was working on this, but I didn't get it working. As it stands now, you have to narrow the type on the response object itself, which is a bit annoying. However, I think it's much better than the current behavior where you can just ignore error cases, resulting in runtime errors. |
Currently the data property of a response is based on the type of one success responses. This is incorrect, because different status codes may return different response types.
This is a breaking change, since working code may now cause compile errors, requiring you to narrow the type before you can use it.
Fixes #2