However, the type guard section seems a bit off to me. Is the suggestion to check each and every property of `Product` in `isProduct`? Seems a bit verbose.
I tend to use Axios, which uses generics to set the payload return type (obviously, some trust in your API responses is needed here):
axios.get<Product[]>(...);In our team we use io-ts to validate all of our endpoints, but simple type guards could achieve the same goal.
I also use axios, and I also take advantage of the generics you've shown above, but I acknowledge that I'm essentially just saying "Trust me" and doing a cast when I do that.
And I'll add - that exact style of code has been a source of bugs in our production codebase before. A dev will pick the wrong type for the axios generic, and if the api response happens to overlap on the used fields, no one notices. Then it blows up 6 months later when someone tries to access a field on the defined type that wasn't actually returned in the api response.
We use it to great effect ourselves, by generating types for axios.
https://github.com/ovotech/laminar/tree/main/packages/lamina...
Now granted, you’re now trusting the api writers with their contract, but if its another team in the org we’ve found it to be warranted.
Very much this. That scenario will break if e.g. the backend API changes. This is a constant source of frustration for someone I know, whose backend team has a habit of not communicating their changes to the frontend team.
There's nothing TS can do to enforce that the actual type of the response matches what the type declaration says (hence the need for runtime checks in this case).
Checking for the existence of a key on an object is dirt cheap.
Even if you happen to have a case where it is expensive, there's absolutely nothing that says your typeguard has to take that approach.
I've seen some reasonably sane code that just checks that the 'Type' field of the object matches the expected value, and the 'Version' field is the right number. It's not going to catch all the possible errors there if someone breaks the api contract, but it's a lot better than a raw cast.
In most cases it's worth it to trade the small performance penalty for correctness, especially since the cost of fetching data is already dominated by the network and backend.
Tbh the bench here suggests the only non algo perf worth doing would be switching to rust with pre allocated memory for each request. By the time we are up to the scale where the sin le digit gains are worth it we'll have more than enough capability for going straight to the software end zone.
I can see how the proposed solution could be "better", but I'd rather avoid the validation code and instead get the type right.