acacode / acacode/swagger-typescript-api
[Feature request] Discriminated unions on status for error or success responses
- 主要語言
- TypeScript
- 星號
- 4.1k
- 分支
- 436
- PR 合併指標
- 30 天內沒有已合併 PR
描述
How would the swagger-typescript-api team feel about having the `status` from the response as a typescript union discriminant where rest of the props would be defined based on its value?
For example, if the `swagger.json` file contains this for a given api call -
```json
"responses": {
"200": {
"description": "Resource is successfully created.",
"schema": { "$ref": "#/definitions/ResourceSuccessResponse" }
},
"400": {
"description": "Create resource request has invalid fields.",
"schema": { "$ref": "#/definitions/ErrorResponse" }
},
"401": {
"description": "Create resource request has invalid user credentials.",
"schema": { "$ref": "#/definitions/ErrorResponse" }
},
"409": {
"description": "Resource name already exists.",
"schema": { "$ref": "#/definitions/ErrorResponse" }
}
}
```
hypothetically the response could be of this format -
```ts
type HttpResponseType = {
status: Status,
data: ResponseData
}
type ResourceCreationResponse =
| HttpResponseType<200, ResourceSuccess>
| HttpResponseType<400, ErrorResponse>
| HttpResponseType<401, ErrorResponse>
| HttpResponseType<409, ErrorResponse>
type ResourceSuccess = {
resource: string
}
type ErrorResponse = {
code: number
message: string
}
declare const a: MyApiCallResponseType;
if(a.status === 200) {
console.log(a.data) // `a.data` is of type ResourceSuccess now
}
```
This could also be an option if not the default.
I would be willing to make a PR for this if this seems like a good idea. It definitely makes the resulting types stronger in my experience with slight flexibility cost.
貢獻指南
這個儲存庫沒有索引到貢獻指南
評估
這個 Issue 還沒有評估資料。