I do NOT like casting the return of the .json() as a given type. Much better (imo) to use Zod or Yup or some similar library to double-check we are getting what we expect.
@@frazuppi4897 Client always should check the response before casting it to specific type. Server can be down, change it's response type, change API version etc. Better way is to integrate Zod and validate response inside .json() function. Even if you code a sever yourself - you can't code without errors. If response type differs from type you expect - throw and handle an error 💫
@@illia_mikhow makes zero sense, server can be down? then you'll get timeout man, api's change? Then you crash because that is what you should do, you display an error to the user and change the code that is EXACTLY what you'll do if you have zod validation
This is dangerous advice for anyone who wants to write reliable production-grade software. Don't ever do it for a real world business application. Data should be validated at boundaries. API's and upstream data sources (even within your own app/codebase) are liable to change or have regressions. Whether you're blindly casting with `as` or using `declare` to create a generic fetch() the issue is the same: you have zero runtime confidence that the response from the API is what you say it is -- not today, and especially in the uncertain future. You are using TypeScript to lie to yourself and anyone who maintains your codebase and creating the illusion of type safety. Its irresponsible imho to not mention this in the video. TypeScript is a fancy linter and static analysis tool and using it in this way arguably sabotages its purpose. When you break the "chain of trust" that data is actually what you tell TypeScript to pretend it is you break everything.
Of course you have to check it at runtime. Typescript is always just a better linter and should be treated like that. When you use the more generic fetch you don‘t make it any worse than casting it in the json() call. When you do a type check at the json() call but you don‘t have do cast or check it there anymore. Of course it‘s not runtime safe but that is always the case using TypeScript. But I get your point 👍
What we do is auto-generate request and response types based on our Open API schema. Of course you can go ahead and say that if the documentation is not maintained, the types aren't and you run into the same issue as you described, but this can be part of your code review process to make sure the schema _is_ updated with every code change.
This approach is not type-safe. You just have made an implicit type assertion. Without any response validator, fetch will never be type-safe because you can't know what the response will be.
I think we have different understandings of type-safe in TypeScript types. TypeScript will never be type-safe at runtime. We can‘t achieve that with only types. So yes, if you want real runtime safety, we need to do real checks. 👍
Good stuff. Although, I would say better create a wrapper function instead of overriding the existing one. Redeclaring globals could bite you in unexpected places.
@@bahaaalhalabi8940 the problem here is that the override is global. It would affect all 3rd party code and libraries linked to the project. If you have some libs written in TypeScript, they could fail to compile.
I do NOT like casting the return of the .json() as a given type. Much better (imo) to use Zod or Yup or some similar library to double-check we are getting what we expect.
useless, you are calling a server you should know what you get, expecially if you code it
@@frazuppi4897 Then why use types at all? I coded that function, I know what it returns...
@@frazuppi4897 Client always should check the response before casting it to specific type. Server can be down, change it's response type, change API version etc. Better way is to integrate Zod and validate response inside .json() function. Even if you code a sever yourself - you can't code without errors. If response type differs from type you expect - throw and handle an error 💫
@@illia_mikhow makes zero sense, server can be down? then you'll get timeout man, api's change? Then you crash because that is what you should do, you display an error to the user and change the code that is EXACTLY what you'll do if you have zod validation
@@illia_mikhow imho oc
this channel really rocks
Amazing video🎉...I will use this in my projects after this.
Thank you for creating these videos.
It's really amazing! Will use it
It's more about type hints then type safety. I doubt it validates anything at runtime
exactly, i think this should use zod instead
This is dangerous advice for anyone who wants to write reliable production-grade software. Don't ever do it for a real world business application. Data should be validated at boundaries. API's and upstream data sources (even within your own app/codebase) are liable to change or have regressions. Whether you're blindly casting with `as` or using `declare` to create a generic fetch() the issue is the same: you have zero runtime confidence that the response from the API is what you say it is -- not today, and especially in the uncertain future. You are using TypeScript to lie to yourself and anyone who maintains your codebase and creating the illusion of type safety. Its irresponsible imho to not mention this in the video. TypeScript is a fancy linter and static analysis tool and using it in this way arguably sabotages its purpose. When you break the "chain of trust" that data is actually what you tell TypeScript to pretend it is you break everything.
Of course you have to check it at runtime. Typescript is always just a better linter and should be treated like that. When you use the more generic fetch you don‘t make it any worse than casting it in the json() call. When you do a type check at the json() call but you don‘t have do cast or check it there anymore. Of course it‘s not runtime safe but that is always the case using TypeScript. But I get your point 👍
What we do is auto-generate request and response types based on our Open API schema. Of course you can go ahead and say that if the documentation is not maintained, the types aren't and you run into the same issue as you described, but this can be part of your code review process to make sure the schema _is_ updated with every code change.
@@Typed-Rocks someone who doesn't read comments is doomed.
Now auto-generate this based on Open API schemas. 🤩
I‘m also a huge fan of openapi. Using it in production all the time with openapi generators
UPDATE -> PATCH
Ups, you are right 😝
This approach is not type-safe. You just have made an implicit type assertion. Without any response validator, fetch will never be type-safe because you can't know what the response will be.
I think we have different understandings of type-safe in TypeScript types. TypeScript will never be type-safe at runtime. We can‘t achieve that with only types. So yes, if you want real runtime safety, we need to do real checks. 👍
@@Typed-Rocks why not update the video to advice those who dont know that to use zod.
typescript !== type safety
Using fetch, get request must not have a body. You will get a TypeError (at least in Chrome)
Amazing
Awesome
Where's PATCH?
I somehow used UPDATE instead. A mistake :)
Good stuff. Although, I would say better create a wrapper function instead of overriding the existing one. Redeclaring globals could bite you in unexpected places.
Absolutely. I only would to it for types to make them more strict
He is overriding the types not the functionality, fetch will work normally.
@@bahaaalhalabi8940 the problem here is that the override is global. It would affect all 3rd party code and libraries linked to the project. If you have some libs written in TypeScript, they could fail to compile.
Or just use axios
Just use Zod (or alternatives).
kinda of useless