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

Infer response schema #150

Open
davemaier opened this issue Sep 26, 2024 · 2 comments
Open

Infer response schema #150

davemaier opened this issue Sep 26, 2024 · 2 comments

Comments

@davemaier
Copy link

Hi!

I've just started using this library and I'm a bit confused about the response type. Is it correct that I need to add a response type schema to each hook manually?

Would it generally be possible to infer the response schema from the type information in the elysia object like it's done in eden treaty or am I missing some conceptual differences here?

This would be super useful.

@nxht
Copy link
Contributor

nxht commented Oct 1, 2024

If you're meaning the typebox schema, yes it's necessary as Typescript's type information is not available at the runtime.

@davemaier
Copy link
Author

Thank you for answering my question and sorry for the late reply. I see that this is making inference of response types impossible currently.

Nevertheless, having correct documentation of the response for apis that don't explicitly describe the response would be super nice. An app of a customer for instance uses drizzle and eden treaty and therefore profits from end to end type safety. But the swagger docs don't reflect that and it's also not possible to generate api clients for other languages over the openapi spec (would be great for the mobile app).

I think that there should be some kind of CLI included with this package that can be used to generate a json file that contains the missing type information for the response schema so that this can then be used at runtime. I've already played around with the TS compiler APIs and I think that an approach would be totally feasible. Additionally this can be a purely optional thing in the library.

Please let me know what you think about it and if something like this could be merged into the library if I came up with the code.

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

No branches or pull requests

2 participants