Easily give fetch() timeouts, type-safety, and better error handling

More in my full blog post: www.builder.io/blog/safe-data...
#javascript #typescript

[@bubsztyn]

I recommend using unknown instead of any as a default result type. It will give you a warning if you forget to pass generic when trying to access result object fields

[@TechDiffuse]

That's super useful. Thanks for this,

[@asadsalehumar1011]

The abort signal is really helpful. However there is a cons when typecasting json response using "as" because you force TypeScript to believe it's that type, but in fact it could be any type. There are use cases though, like when we know for sure the response is of a certain type. Such thing can happen in thightly coupled system, such as: React Server Components. So, it's has pros and cons.

[@funkdefied1]

I think “as” is appropriate here. The “as” assertion isn’t validated at runtime, so any weird response won’t immediately cause the program to crash like it would in a language with a stricter type system. Rather, it signals what the developer BELIEVES the response’s shape to be, given their knowledge of the API.

[@ggoadmusic]

I Like that!

[@Noam-Bahar]

I love axios

[@isaacjon]

Why would you check for result.ok ? If it was not okay wouldn't it end up in the catch block?

[@IllllIIllllI]

it only throws when there is a network error, but doesn't throw if the status code is 400 for example. result.ok is true when status code is in range 200-299

[@isaacjon]

@@IllllIIllllI so it would not be okay because it's not in the range of 200-299 right?

[@arxci9402]

Why would you time out a fetch call, lol? What if your users internet is so bad and it takes longer than the predetermined time limit you defined? Now, your user has absolutely zero chance in ever seeing your content instead of just waiting a little while linger

[@asadsalehumar1011]

There are use cases for this, especially in backend development

[@asadsalehumar1011]

For example, from my Node.js backend I might want to call another API service. But I definitely know that if it takes more than 30 seconds it's an error. So giving my fetch an AbortSignal is really useful.

[@Erliortmejurur]

I have wasted so much time hahaha

[@isaacjon]

I can't understand so many things going on here

[@zeeeeeman]

you're using `as` casting again. That is NOT the way to do it.

[@ramsey2155]

Or you could just properly use a typesafe rtc method

[@TheScriptPunk]

Jesus....you made a class when you could just make a decorator function. Also, use a helper framework to operate the error check, and bubble through an error conrext handling component.

[@PeterSahanaya]

Don't call Jesus name as a swear word

[@David-gj6dc]

"with full type checking" That's not how that works bud. Anytime you do network I/O without any runtime checks there is no type safety at all. This is JavaScript we're talking about. The only thing you get is autocomplete but you are basically lying to the compiler anytime you don't have runtime checks.

[@_sleepy-]

Don’t use javascript for backend, solved like honestly you typed so much for something that should take so little

[@kag3670]

AbortSignal.timeout() will throw error.name TimeoutError 😊