Typesafe API call. Does this adhere to best practices ?
Answered
Nova Scotia Duck Tolling Retriev… posted this in #help-forum
Nova Scotia Duck Tolling RetrieverOP
Simple External API call with error handling that will be used by react query. I would like to know if it adhere to best practices for type safety etc. There's not much information in videos etc and they just show fetch without typescript most of the time.
EDIT: Added that it's an external api call
EDIT: Added that it's an external api call
Answered by American Crow
First i'd not manually redo the typing/validation in Zod but use something like https://transform.tools/typescript-to-zod
(If you want to practice you can ofc do it manualy).
After that you
(If you want to practice you can ofc do it manualy).
After that you
zod.infer a "normal" typescript type from that schema which you can export and use anywhere you need in your application13 Replies
@Nova Scotia Duck Tolling Retriever Simple External API call with error handling that will be used by react query. I would like to know if it adhere to best practices for type safety etc. There's not much information in videos etc and they just show fetch without typescript most of the time.
EDIT: Added that it's an external api call
casting a type with
it's better to use a validation library for external requests so you can trust the types, a good example is zod: https://zod.dev/
as like this is very dangerous, you are basically telling typescript that it should trust that the type of the variable is X with no real reason. if this API returns something different from your type the code will continue running as if nothing wrong happened and you will end up with a hard to track bugit's better to use a validation library for external requests so you can trust the types, a good example is zod: https://zod.dev/
besides this TS detail the rest of the code is fine
@Rafael Almeida casting a type with `as` like this is very dangerous, you are basically telling typescript that it should trust that the type of the variable is `X` with no real reason. if this API returns something different from your type the code will continue running as if nothing wrong happened and you will end up with a hard to track bug
it's better to use a validation library for external requests so you can trust the types, a good example is zod: <https://zod.dev/>
Nova Scotia Duck Tolling RetrieverOP
The API docs state that it should be the only possible result for an error.
I went the zod way at first but I was actually wondering if it made any sense ? I understand that it validates at runtime but does it add anything else in this example ?
Could I simply use zod everywhere instead of "Pure" typescript ?
I went the zod way at first but I was actually wondering if it made any sense ? I understand that it validates at runtime but does it add anything else in this example ?
Could I simply use zod everywhere instead of "Pure" typescript ?
its mostly a matter of how much you trust the API and how much you want the types to be accurate. if you use
as there is a chance that the types could be lying in case they change the API for some reason, and you won't know until it triggers an error or someone reports an issue with the UI@Nova Scotia Duck Tolling Retriever The API docs state that it should be the only possible result for an error.
I went the zod way at first but I was actually wondering if it made any sense ? I understand that it validates at runtime but does it add anything else in this example ?
Could I simply use zod everywhere instead of "Pure" typescript ?
American Crow
In general I'd add Zod anywhere I don't trust the input, e.g. user input (forms), external apis, url parameters.
For my own code something simple as typing out props for a component I'd do that in just Typescript.
Zod does at a bit of overhead at runtime so it's not appropriate in those cases.
For internal API's you may argue. On the one hand you can trust them since you control them.
But can you trust yourself? x (
hehe, pun intended). Meaning when you change your internal API do you remember to also adjust your types? Or do you need Zod as a "reminder" and pay some overhead cost for it? As said can be argued in both ways imo.
For my own code something simple as typing out props for a component I'd do that in just Typescript.
Zod does at a bit of overhead at runtime so it's not appropriate in those cases.
For internal API's you may argue. On the one hand you can trust them since you control them.
But can you trust yourself? x (
hehe, pun intended). Meaning when you change your internal API do you remember to also adjust your types? Or do you need Zod as a "reminder" and pay some overhead cost for it? As said can be argued in both ways imo.@American Crow In general I'd add Zod anywhere I don't trust the input, e.g. user input (forms), external apis, url parameters.
For my own code something simple as typing out props for a component I'd do that in just Typescript.
Zod does at a bit of overhead at runtime so it's not appropriate in those cases.
For internal API's you may argue. On the one hand you can trust them since you control them.
But can you trust yourself? x (<:sunglasses_1:767749456648339497> hehe, pun intended). Meaning when you change your internal API do you remember to also adjust your types? Or do you need Zod as a "reminder" and pay some overhead cost for it? As said can be argued in both ways imo.
Nova Scotia Duck Tolling RetrieverOP
Alright, so in this case I’d redo the same typing/validation but with Zod and then parse the response instead to make sure that the data I get is in the correct form ? Dows the typing follow along the components etc ? Or I’ll have to export the type and type everywhere afterwards ?
@Nova Scotia Duck Tolling Retriever Alright, so in this case I’d redo the same typing/validation but with Zod and then parse the response instead to make sure that the data I get is in the correct form ? Dows the typing follow along the components etc ? Or I’ll have to export the type and type everywhere afterwards ?
American Crow
First i'd not manually redo the typing/validation in Zod but use something like https://transform.tools/typescript-to-zod
(If you want to practice you can ofc do it manualy).
After that you
(If you want to practice you can ofc do it manualy).
After that you
zod.infer a "normal" typescript type from that schema which you can export and use anywhere you need in your applicationAnswer
@American Crow First i'd not manually redo the typing/validation in Zod but use something like https://transform.tools/typescript-to-zod
(If you want to practice you can ofc do it manualy).
After that you `zod.infer` a "normal" typescript type from that schema which you can export and use anywhere you need in your application
Nova Scotia Duck Tolling RetrieverOP
Yeah thats the exact site I used to do the other way around ahaha thanks
American Crow
haha thats funny. you welcome iam off sleeping gn
@Nova Scotia Duck Tolling Retriever The API docs state that it should be the only possible result for an error.
I went the zod way at first but I was actually wondering if it made any sense ? I understand that it validates at runtime but does it add anything else in this example ?
Could I simply use zod everywhere instead of "Pure" typescript ?
use both? Typescript is for validating dev code, but zod is used to validate runtime type assertion.
I went the zod way at first but I was actually wondering if it made any sense ? I understand that it validates at runtime but does it add anything else in this example ?Typescript doesnt validates at runtime
@ᴉuɐpɹɐɐ use both? Typescript is for validating dev code, but zod is used to validate runtime type assertion.
> I went the zod way at first but I was actually wondering if it made any sense ? I understand that it validates at runtime but does it add anything else in this example ?
Typescript doesnt validates at runtime
Nova Scotia Duck Tolling RetrieverOP
I was talking about zod validating at runtime. Sorry for the misunderstanding. But I will do that from now on 🙂
yeah thats what i mean: typescript doesnt validates at runtime therefore you need zod. your code doesnt have zod therefore it needs to be added "in this example"
@ᴉuɐpɹɐɐ yeah thats what i mean: typescript doesnt validates at runtime therefore you need zod. your code doesnt have zod therefore it needs to be added "in this example"
Nova Scotia Duck Tolling RetrieverOP
Gotcha ! Thanks for your input