Open Colmea opened 8 months ago
I don't want to have to maintain that kind of code, the main goal of that lib is having a typed api client using openapi the runtime validation is a nice bonus
if you want runtime validation from openapi + zod, there's openapi-zod-client that I made specifically for this https://openapi-zod-client.vercel.app/
feel free to make your own api client like this one https://github.com/astahmer/typed-openapi/issues/19#issuecomment-1932182486 see prev discussions on the topic https://github.com/astahmer/typed-openapi/issues/18#issuecomment-1833322629 https://github.com/astahmer/typed-openapi/issues/3#issuecomment-1695647149
I'm open to merging an API client implementation based on a given runtime if it is generic enough so that it can help more people (even just as a snippet in the README !)
Thanks for all these information.
Indeed I saw the section in the Readme but tbh it was not clear for me that the runtime validation was just provided "as-is", but not really used in the client.
I will look into the code to see if I can propose something in a PR !
Otherwise, maybe a small clarification in the Readme would be useful ? Especially on the "you can also generate a client with runtime validation" => "you can also generate runtime validation to be used with your client" ?
Anyway, thanks for your work on this and Panda !
Note: I saw openapi-zod but typed-openapi was more useful for us because we have both zod and io-ts in some legacy code
Hey,
I came up with this, what do you think ? So basically we find the zod schema from the endpoint, then parse the response.
The parse function will throws a ZodError if the validation does not pass.
Example with the GET request:
// <ApiClient.get>
async get(path: Path, ...params) {
// Fetch data from the API
const responseData = await this.fetcher(
'get',
this.baseUrl + path,
params[0],
);
// Parse and validate the response data using the Zod schema
const schema = EndpointByMethod.get[path].response;
const parsedData = schema.parse(responseData);
return parsedData;
}
// </ApiClient.get>
If it's good enough for you, I can create a PR. To avoid any breaking change, I can also add a new flag in the CLI.
I havent tried but this looks good !
thinking about it again I really want to avoid any maintenance regarding the runtime validation, so I think it would be best to have this as an example snippet in the README, along with this one
but I also understand that currently the way to create your own client is somewhat-clunky, adding a way to generate a custom implementation somewhere here using a callback that receives the current method, endpointByMethod
(and anything else needed) would be future-proof for everyone's need
Hi @astahmer,
Sorry for 2 issues in one day 🥲
I would like to use this library because of the runtime validation support (zod mainly) it provides.
Based on this from README
I would expect that the generated ApiClient actually uses these zod schemas and parse the response with them, but it looks like it's note the case.
See the generated GET request here. It never uses the generated zod schema.
Am I missing something ? Or are we just supposed to use the generated zod schemas on our own (if so, why not directly use them in the ApiClient ?)
Thanks for your help!