Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] concise response type alias #77

Open
scottc opened this issue Jun 7, 2019 · 4 comments
Open

[feature] concise response type alias #77

scottc opened this issue Jun 7, 2019 · 4 comments

Comments

@scottc
Copy link

scottc commented Jun 7, 2019

The response types can be quite long, and inconvenient to use.

const x: Promise<ResponseWithBody<200, OkBody> | ResponseWithBody<404, NotFoundBody> | ResponseWithBody<400, BadRequestBody>> = undefined;

I propose generating some concise type aliases.

type SomeAlias1 = ResponseWithBody<200, OkBody>;
type SomeAlias2 = ResponseWithBody<404, NotFoundBody>;
type SomeAlias3 = ResponseWithBody<400, BadRequestBody>;

type SomeUnionResponseAlias = SomeAlias1 | SomeAlias2 | SomeAlias3;

The alias's should be backwards compatible, optional to use and work as drop in replacements.

@Markionium
Copy link
Collaborator

Hi Scott,

I really like the idea.

Just to clarify, when you say optional you mean you would like like to be able to control if they are generated or not?

@scottc
Copy link
Author

scottc commented Jun 7, 2019

Just to clarify, when you say optional you mean you would like like to be able to control if they are generated or not?

My original intent was "optional to use" the aliases.

Typescript type definitions are only used at compile time, and there is no additional code generated in the output .js file. So I can't think of any drawbacks of always generating these additional types. Would be up-to the developer to decide which types they want to import and use.

@mtennoe
Copy link
Owner

mtennoe commented Jun 7, 2019

Really like this idea as well! Ensuring we export both the verbose and the consise types would make them optional to use as well. Should not cause any bundle size issues either for the consumer, as as you mention these are just compile time types

@mtennoe
Copy link
Owner

mtennoe commented Jun 17, 2019

@scottc - Wanna give this a shot?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants