From my reading axios has a couple extra features but for most people either one is fine and accomplishes the same thing. Only reason why I'm considering finally moving off axios is the vulnerabilities that pop up every now and then. Less external dependencies means less maintenance to worry about. Since fetch is built in & requires a similar amount of code to do the same things I'd only consider using Axios if you make use of interceptors & are already familiar with using through Axios and dont care enough to learn how to do something equivalent using Fetch. Using one over the other WONT make or break a project but some people act like it will for some odd reason, its not really a big deal
It feels more like iteration on Axios than it is on fetch. I see Ky and immediately think “oh it’s just slightly different axios”, at least in terms of using it
@@ramsey2155Yes. Different projects have different requirements. If you use something like ky you'll just end up wrapping it with your own app-specific logic again. You're better off if you just copy-paste the code and modify it to suit your needs instead.
Last time I checked, Axios still uses XMLHttpRequest in the browser and http server side. Ky uses fetch and makes things a bit nicer and also supports cool features like hooks into the request lifecycle. If you’re building a larger application, building a custom client on top of ky is totally worth it over axios imo
I've been coding for 28 years and I would absolutely use this. Call me a junior dev, idc. I know it wouldn't work in enterprise, I know it's not as easy to outsource, idc. I simply wouldn't work for a company like the one you do in the 1st place. As long as we're making up dumb competitions, using abstractions instead of redundantly typing out the same boilerplate still makes me better than you because I can do more than you in less time and spend the limited time I have on this earth innovating on novel features that are actually interesting instead of maximizing shareholder value. It's like excavators just dropped and you're not gonna use one because experienced hole diggers know they aren't compatible with the guidelines all your coworkers that still use plastic spoons use. Weird flex but ok. I disagree that AI makes fetch the better option. It can easily learn ky from in context learning, and we're not far off it just reading the entire codebase anyway. Simple succinct code only makes it less likely to hallucinate and easier for it or you to debug. It could even trim functions in the library that aren't needed and add them back in when they are.
are you telling me you don't have a wrapper over fetch in your production apps which does all the magic of defaults, error handling, logging, and TS related shit and auth token rotations ?
Yeah that part is so weird to me in all of these fetch API discussions. People write code that has 1/10th of the functionality of the library and uses fetch directly all the time and they act like it's comparable.
Does everyone write their on production wrapper to fetch data and does all the magic things? I'm doing too but it's kinda weird that no one build a library to do that 🤔
@@immer5680 it’s not a library. Bunch of functions that do stuff very specific to product/application. Like logging auth key rotations etc. even if u use this library you would still have to do it
@@hannad So your example is irrelevant to the discussion then. Would you write your own wrapper over fetch if you needed hooks, instances, retry, good TS support etc., or just used a library?
I see no problem here. Either way, you’ll have to figure out the wrapper that the team chose to write around the fetch calls. Whether it was made using a library or written from scratch makes little difference. Only with the library you will have better docs.
Exactly this - what project is NOT using wrappers of some kind? ky makes it easy to implement common request pre-processing, error handling and such - things that are already unique to each project and would otherwise be done with more effort and boilerplate.
You know, you can kinda learn anything as basic as this 'ky' in 15 minutes or less. I literally never seen it before and it sounds familiar. So I think there is a larger problem with people self declaring themselves "senior detection machines" or whatever that at the same time are downgrading the world into their own worldviews about how problems should be solved (and that everything outside of that field is "unexperienced"). Put 5 of them in a room and every single one of them will be saying the other is not a real senior very fast. But I get the point, I'm just being a bit harsh.
This is the reason why comments sections were created originally, instead of the shitshow it came to be. Never heard of ofetch before. Gave it a try. Loving it.
Because it is 1 line instead of 6! /s Honestly it's quite annoying seeing people using the most unrealistic examples for comparisons between X and Y. There is not a soul who wouldn't spend 10 minutes cleaning this up and writing 3-4 small helpers for this. In the end both would end up with 1 line...
the advantage of axios or xhr request is that we can listen to the upload progress or download progress, I think fetch didnt have that features. I know this because I used to implement a progressbar for uploading file but for backend i would prefer fetch or considering ky instead of axios
I really think the example you used between ky vs fetch, in the queryFn, was really simple and in that case makes really no sense to use a wrapper lib. It would be the same case using axios instead of fetch. The reason you would want to use ky is if you want to use it's built-in interceptors (same thing using axios). For example: what if in every request you need to check if your token is valid or something like that. If you only use fetch now you need to build a wrapper for it and what if you also need to log some errors whenever there is an http error, another wrapper you need to build. With ky you can use it's middleware hooks, which are basically interceptors, that makes you do all these things in the same config. With ky, you don't need to build multiple wrappers and also have the possibility to use the onDownloadProgress which fetch doesn't have (another wrapper basically). TLDR: If you need a bunch of interceptors and you want to use the fetch api use ky, if not fetch is enough.
@@ThisAintMyGithub I'd be comfortable having a schema check, that can be turned off, if the source is trusted. But I'd insist on having the option in order to sleep well at night.
I thought you just took my 13 minutes for nothing. I just needed some patience, beautifully explained! React query in react is a perfect example. It's not about ky vs fetch. Indeed, It's about the analysing associated costs and benefits whenever these kinds of decisions are to be made.
I wrote my own `ajax()` function in 2009 that wraps XMLHttpRequest. I still use it today with the only change being deleting stuff related to ActiveXObject. Usage: `ajax(url, dataObject).success(result=>{...}).failure(error=>{...});` and that's it. Never needed anything else.
Back in my day, we didn't use Axios. We would use the XMLHttpRequest API directly. Or write a tag to the page pointing to an API that responds with JSONP
I feel like the point of fetch's verbosity is that its made to be format agnostic and allow stuff like XML request transmissions which I'm sure more people than you think still serve.
Using Axios? Man, we still had to use XHR for all our requests. :|
5 месяцев назад
Its hilarious that the topic went around and around again and came to react query :D I think default retry and adding "auto headers" is problematic and sometimes react query can be an overkill. Still the best way to async communication is to wrap fetch for the project needs. I think.
ky is pretty much how every other language I’ve used does requests. It always cracks me up when a JS breakthrough is just doing something the way everyone else has been doing it for years 🤣
The js ecosystem has had Axios for years. Which seems to have a similar interface to Ky. It has interceptors, ways to setup base configuration, mocking solutions for tests. In other words, what is being shown in the video is nothing new in js.
those 39 lines of "boilerplate" are something that you would likely abstract into its own hooks (much like react query) and i think its important new dev to learn how to do that. There should be more of that encouraged. You can still get your 4 lines of code and you dont have to trust some library, and you dont have to guess about what the library is doing.
Who said I want to throw an error on non 20X, constructing an Error is by far the most expensive action in terms of perf in js, and do we really need a library to do retry and timeout? Did we lost the capability to wrap a function in a for loop and use setTimeout and optionally AbortController?
Switching to a fetch wrapper isn't very beneficial in plain JavaScript, BUT if you're using TypeScript with an OpenAPI-backed API, a thin wrapper like feature-fetch or openapi-fetch offers full type safety and can be extended with features like retries, delays, functioning as a plugin system 🤷
almost every project i do ends up with a function called "post" in my library and one called "get" which is just a wrapper for whatever javascript thing we are using this days to do post or get... i actually felt like going from axios to fetch was a step backwards. i look forward to trying KY. i agree if something is different from native you need a good reason to justify, but KY is definitely one of them.
you missed hooks and its extension mechanism. One can create a narrower private api client by extending a broader public client by using extend and add some hooks (for example to attach additional headers upon extension or at the moment when request is executed). In the same way you can attach an abort signal per request just by extending a private api client. And ky handles all the hooks chains and other pre saved attributes for us. Very nifty
Funny that the comments are split between "wait, people still use axios?" and "wait, people stopped using axios?". I still use axios (and query ofc), but only because headers and error handling and typing is better. Might switch to ky since that seems to handle all of that. Then again, not really sure I need to, axios works, and it's not a huge library (13kb vs 3kb for ky, it's not nothing but if you have one or two functional libraries like framer, three or something for charts, your bundle is already 200kb or more, 5% savings isn't worth the adjustment for me)
This is almost what I always do first things on a project, wrap fetch with a simple api that I can use with "get(url)", "post(url, data)", but I wrap it in a way that it always treats as content type json and the response is based on the content-type answered by the server, usually string for text/plain or object for application/json What I have been doing all along is just like that, but without the extra .json() call and the extra { json: } in the post data, everything is JSON by default, things that aren't Json I just use fetch instead I never made this into a library because it's really not a big deal
Have been using axios, but after this, it looks like I'll be switching to ky - so clean! Who wants to deal with fetch error handling?! You'd just end up wrapping it yourself anyway.
All those things you said about the useState -> useQuery transition apply to fetch -> ky inside that same code example... but useQuery gives you enough safety around queryFn that the impact is mitigated but I would argue it's better to control it. It does solve error cases from the API. When you "switched it over to ky" you had _none_ of the proper affordances you needed in your plain fetch call. So it's a bigger win than you are letting on.
I still feel like fetch is a downgrade in DX from Axios (not comparing to plain XMLHttpRequest, obviously nicer than that). You can't try catch out of the box since 3xx, 4xx isn't considered errors, you have to check response.ok. You can't create instances like you can in axios, with predefined baseUrl and headers. There is no built in interceptors. If the answer to this is "Just build a wrapper", how is this any better than axios?
@@untlsn I understand if bundle size is a big concern, but otherwise it feels like axios already had nailed down a solid way of handling HTTP requests, so why build a new wrapper to do the exact same thing? Of course fetch is a huge upgrade from plain XMLHttpRequests in usability, but almost nobody uses plain XMLHttpRequests anyway. So except from bundle size, I don't see any good reason to switch from axios to fetch at this point.
I just wrote my own request builder and solved the problem that way. It's easily maintainable and it's easy to use. Took me a few minutes to make and then I kept adding to it as I needed more stuff. There are obviously nice features in these libraries, but how often do you really need them?
I've had to help people countless times where they've used a library for something that the browser already has an api for. It's been a pain every time due to me not understanding how it works, and having to read the docs for the library. Yeah, it's smart. But not everyone wants to learn a new library every time a smart solution is made.
Omfg, how hard is it to just write a function that houses common headers and a fetch() call? You don't need some artisan builder library to do this. Also do developers pay theo to signal boost their libraries? Why does he focus on one library when there are dozens of similar (and arguably better) libraries out there. At least he isn't signal boosting Zod again.
I usually just write an simple wrapper function handling all the specifics like headers, error handling, types etc. and just reuse this. No magic and 8kb libs needed
I always thought that reason for fetch being so bad to work with was it being the first to come. Now that I know axios came first, it makes me think: How bad do the js language designers have to be to replicate a feature that was already made by community and yet do it badly.
What about ofetch? Anyone heard of that? It uses a nice lib called destr that basically parses the response for you 99% of the time and returns text if it doesn't know
The fetch API was intended to be somewhat low level. It makes few assumptions about your request, which is a good thing for a low level API, but not really great for everyday development. That being the case, it's hardly surprising that someone would build a library like ky on top of it. What is surprising to me is that so many people continue to use fetch directly in spite of it being pretty inconvenient.
I can totally see that viewpoint. It's not as big of a win from other libraries, just different, and different slows adoption. One might make a similar case with React Query as compared to Ky, but then if you use React in the first place then you shouldn't be writing vanilla code anyhow and then Query should already be in your toolkit. Of course, in my field, this is one of the reasons why I get angry with junior developers who use C without ever once learning the libraries that make using it faster and easier. Instead I find them rewriting everything from scratch. Unless you genuinely have a better means of accomplishing the task at hand, writing it from scratch, which here would be equivalent to writing vanilla JavaScript, is a big no no.
tbh I would prefer the openapi-fetch package over ky simply because it creates a contract between FE and BE. I don't need to check if I set the right endpoint path, also I don't need to set the response type manually, and most importantly, when I update the Open API schema, the typescript instantly shows what and where I should change in the codebase
The only thing that I'd like to change is how we can access the generated types. For now, I've decided to re-export those that I needed from a module with an openapi-fetch setup, but ideally, it would be great to import them from the package, as it was done in Prisma
Yes, because React cannot implicitly abort a network request in transit. The `setState` function is stable across renders, meaning it will just act on the current component render iteration instead of the one where it was "created" in.
after I saw a content about ky from coderone I think it was last week. I created a custom fetch on top of fetch and called it butter. Since then I stopped using normal fetch lmao🤣
Is this really that “different” as you say it is? I mean you said it yourself that we have been using axios for years. Ky is really just building upon that using fetch underneath.
.json() is an Anti-Pattern in TS and explicitly forbidden to do in DefinitelyTyped because passing in a generic parmeter that only sets the return type (and does not depend on the input parameters) is a "hidden" type assertion. It is better to do `.json() as T` because that makes the type assertion visible as type assertions are the boundaries in which errors can sneak in.
A couple of years ago, I had the opportunity to migrate a bunch of jQuery ajax calls to fetch. Ky, actually looks interesting and I may consider it in the future if I ever get sick of writing fetch implementations.
I don't see the point in this being a library. My apps just have a 50 LoC 'api.ts' that defines a function for making API calls, with handling for retrying when the server is unreachable, automatically defines Content-Type, handles session expiry, etc etc.
Wait, you guys don't use axios anymore 😂
I had the exact same reaction. Is axios a boomer library now?
@@MrXperx yeah I've been using raw fetch for years
I still use axios. It has interceptors and shared client instances. I'd have to roll my own in fetch otherwise.
fetch is out since almost 10 years
From my reading axios has a couple extra features but for most people either one is fine and accomplishes the same thing. Only reason why I'm considering finally moving off axios is the vulnerabilities that pop up every now and then. Less external dependencies means less maintenance to worry about. Since fetch is built in & requires a similar amount of code to do the same things I'd only consider using Axios if you make use of interceptors & are already familiar with using through Axios and dont care enough to learn how to do something equivalent using Fetch. Using one over the other WONT make or break a project but some people act like it will for some odd reason, its not really a big deal
XHR is for beta devs. real devs reload their entire page to fetch new data from the server.
🤣🤣🤣🤣🤣🤣🤣
its common sense 😆
My company's current project used to do exactly that
ill just pretend thats what im doing by chaining a window.reload after my fetch calls
W take 🤣
It feels more like iteration on Axios than it is on fetch. I see Ky and immediately think “oh it’s just slightly different axios”, at least in terms of using it
Axios uses XMLHttpRequest, Ky uses fetch. Not the same at all... Axios is a much bigger dependency.
@@red_991 that’s why I said “in terms of using it”, as if “methods usage and such”
Ky has horribor error handing
@@red_991 I'm pretty sure you're able to make axios use fetch under the hood with recent versions (quite useful when migrating older code to app dir)
I was about to say 😄
this is bs, just make an util function that includes all the default headers and you have it
@@ramsey2155I mean you could also just use axios
That can work too, but..... No thanks
@@ramsey2155 so you would use a third party tool instead of writing a function lol?
btw this is how our loved shadcn/ui works
@@ramsey2155Yes. Different projects have different requirements. If you use something like ky you'll just end up wrapping it with your own app-specific logic again. You're better off if you just copy-paste the code and modify it to suit your needs instead.
@@pokefreak2112 lmao just download the package bro, it aint that deep
I really dont see why should i go all the way from axios just to have another library instead. What's wrong wth axios?
there are people still using axios today ? 😳😳😳
Last time I checked, Axios still uses XMLHttpRequest in the browser and http server side.
Ky uses fetch and makes things a bit nicer and also supports cool features like hooks into the request lifecycle.
If you’re building a larger application, building a custom client on top of ky is totally worth it over axios imo
@@Goshified why should I care? Ain't fetch and xhr just two ways of communicating with the browser's network module?
@@sagiyoav try to use axios in react native, and tell me how you feel :)
@@luderx I don't do r-native :P
U know I'm a capacitor kinda guy... Simple worker
.
Bruh, what do you mean used, We still use axios 😮
This must be an ad
Axios has fetch adapter now, why change Axios to anything else ?
The `retry` API is so nice
To quote ThePrimeTime - "skill issue".
I've been coding for 28 years and I would absolutely use this. Call me a junior dev, idc. I know it wouldn't work in enterprise, I know it's not as easy to outsource, idc. I simply wouldn't work for a company like the one you do in the 1st place. As long as we're making up dumb competitions, using abstractions instead of redundantly typing out the same boilerplate still makes me better than you because I can do more than you in less time and spend the limited time I have on this earth innovating on novel features that are actually interesting instead of maximizing shareholder value. It's like excavators just dropped and you're not gonna use one because experienced hole diggers know they aren't compatible with the guidelines all your coworkers that still use plastic spoons use. Weird flex but ok.
I disagree that AI makes fetch the better option. It can easily learn ky from in context learning, and we're not far off it just reading the entire codebase anyway. Simple succinct code only makes it less likely to hallucinate and easier for it or you to debug. It could even trim functions in the library that aren't needed and add them back in when they are.
are you telling me you don't have a wrapper over fetch in your production apps which does all the magic of defaults, error handling, logging, and TS related shit and auth token rotations ?
Yeah that part is so weird to me in all of these fetch API discussions. People write code that has 1/10th of the functionality of the library and uses fetch directly all the time and they act like it's comparable.
Does everyone write their on production wrapper to fetch data and does all the magic things? I'm doing too but it's kinda weird that no one build a library to do that 🤔
So you basically wasted time writing your own library no one understands how to work with? Why?
@@immer5680 it’s not a library. Bunch of functions that do stuff very specific to product/application. Like logging auth key rotations etc. even if u use this library you would still have to do it
@@hannad So your example is irrelevant to the discussion then. Would you write your own wrapper over fetch if you needed hooks, instances, retry, good TS support etc., or just used a library?
I see no problem here. Either way, you’ll have to figure out the wrapper that the team chose to write around the fetch calls. Whether it was made using a library or written from scratch makes little difference. Only with the library you will have better docs.
+1 so I still prefer fetch for its nativeness
Exactly this - what project is NOT using wrappers of some kind? ky makes it easy to implement common request pre-processing, error handling and such - things that are already unique to each project and would otherwise be done with more effort and boilerplate.
You know, you can kinda learn anything as basic as this 'ky' in 15 minutes or less. I literally never seen it before and it sounds familiar.
So I think there is a larger problem with people self declaring themselves "senior detection machines" or whatever that at the same time are downgrading the world into their own worldviews about how problems should be solved (and that everything outside of that field is "unexperienced"). Put 5 of them in a room and every single one of them will be saying the other is not a real senior very fast.
But I get the point, I'm just being a bit harsh.
bruh, ofetch solved fetch problems a long time ago
This is the reason why comments sections were created originally, instead of the shitshow it came to be.
Never heard of ofetch before. Gave it a try. Loving it.
Not only ofetch, but the entire UnJS ecosystem is gold.
except upload progress, you still need XHR fallback for stupid loading bar
I don't understand the point of adding a dependency for something that would take you like 30 minutes and 20 lines of code to reproduce.
Because it is 1 line instead of 6! /s
Honestly it's quite annoying seeing people using the most unrealistic examples for comparisons between X and Y. There is not a soul who wouldn't spend 10 minutes cleaning this up and writing 3-4 small helpers for this. In the end both would end up with 1 line...
30min is for a 0.5x engineer, more like 5min. It's skill issue at this point
Why re write code for everything yet there is already a robust library that can be used .
Timeout
@@weiSane"robust" lmao
I see positive here because it's not about react, so can be used in vanilla JS.
I just use axios. Why use something else? Does fetch support interceptors?
service workers allow you to intercept fetch requests
Fetch by itself not
But ky dose by hooks in extend method
@@puppy0cam That's not what Axios interceptors are about.
the advantage of axios or xhr request is that we can listen to the upload progress or download progress, I think fetch didnt have that features. I know this because I used to implement a progressbar for uploading file
but for backend i would prefer fetch or considering ky instead of axios
@@nizomsidiq3 Axios also supports fetch so you can use it on backend.
I really think the example you used between ky vs fetch, in the queryFn, was really simple and in that case makes really no sense to use a wrapper lib. It would be the same case using axios instead of fetch. The reason you would want to use ky is if you want to use it's built-in interceptors (same thing using axios).
For example: what if in every request you need to check if your token is valid or something like that. If you only use fetch now you need to build a wrapper for it and what if you also need to log some errors whenever there is an http error, another wrapper you need to build. With ky you can use it's middleware hooks, which are basically interceptors, that makes you do all these things in the same config.
With ky, you don't need to build multiple wrappers and also have the possibility to use the onDownloadProgress which fetch doesn't have (another wrapper basically).
TLDR: If you need a bunch of interceptors and you want to use the fetch api use ky, if not fetch is enough.
Been using react query for months. It's a life-saver if you're building anything mildly complex.
The .json() thing, is convenient but typescript will assume that the thing received matches that type going forward. It might very well be a lie.
unknown, while inconvenient is a solid choice as return type. It forces you to check if what you received matches your expectations.
@@nefthy thank you for saying this. People should just use zod. runtime errors are worse than dealing with unknown types
Yeah, my thoughts exactly. There would need to be schema validation calls after each one anyway, and at that point you may as well be using tRPC...
@@ThisAintMyGithub I'd be comfortable having a schema check, that can be turned off, if the source is trusted. But I'd insist on having the option in order to sleep well at night.
It's so easy to make your own common fetch variants for this that you really don't need an extra dependency for it.
I thought you just took my 13 minutes for nothing. I just needed some patience, beautifully explained! React query in react is a perfect example. It's not about ky vs fetch. Indeed, It's about the analysing associated costs and benefits whenever these kinds of decisions are to be made.
I think ky is for nodejs users. ReactQuery is for react. In that case ky makes sense
I wrote my own `ajax()` function in 2009 that wraps XMLHttpRequest. I still use it today with the only change being deleting stuff related to ActiveXObject. Usage: `ajax(url, dataObject).success(result=>{...}).failure(error=>{...});` and that's it. Never needed anything else.
No types 💀
I just use axios with react query
KY, it lubes up the experience of fetch...
Back in my day, we didn't use Axios. We would use the XMLHttpRequest API directly. Or write a tag to the page pointing to an API that responds with JSONP
I use xhr btw
I feel like the point of fetch's verbosity is that its made to be format agnostic and allow stuff like XML request transmissions which I'm sure more people than you think still serve.
Using Axios? Man, we still had to use XHR for all our requests. :|
Its hilarious that the topic went around and around again and came to react query :D I think default retry and adding "auto headers" is problematic and sometimes react query can be an overkill. Still the best way to async communication is to wrap fetch for the project needs. I think.
Ky: easing in the hard things.
ky is pretty much how every other language I’ve used does requests. It always cracks me up when a JS breakthrough is just doing something the way everyone else has been doing it for years 🤣
The js ecosystem has had Axios for years. Which seems to have a similar interface to Ky. It has interceptors, ways to setup base configuration, mocking solutions for tests. In other words, what is being shown in the video is nothing new in js.
@@Liquidian Oh good to know!
those 39 lines of "boilerplate" are something that you would likely abstract into its own hooks (much like react query) and i think its important new dev to learn how to do that. There should be more of that encouraged.
You can still get your 4 lines of code and you dont have to trust some library, and you dont have to guess about what the library is doing.
12 lines of code
Theo: That's terrifying
😂😂😂
1:57 - literally ran into that yesterday - took me a good 10 minutes before I realized I forgot the content type.
Who said I want to throw an error on non 20X, constructing an Error is by far the most expensive action in terms of perf in js, and do we really need a library to do retry and timeout? Did we lost the capability to wrap a function in a for loop and use setTimeout and optionally AbortController?
Switching to a fetch wrapper isn't very beneficial in plain JavaScript, BUT if you're using TypeScript with an OpenAPI-backed API, a thin wrapper like feature-fetch or openapi-fetch offers full type safety and can be extended with features like retries, delays, functioning as a plugin system 🤷
It makes total sense to use it in server side
almost every project i do ends up with a function called "post" in my library and one called "get" which is just a wrapper for whatever javascript thing we are using this days to do post or get...
i actually felt like going from axios to fetch was a step backwards. i look forward to trying KY.
i agree if something is different from native you need a good reason to justify, but KY is definitely one of them.
you missed hooks and its extension mechanism.
One can create a narrower private api client by extending a broader public client by using extend and add some hooks (for example to attach additional headers upon extension or at the moment when request is executed).
In the same way you can attach an abort signal per request just by extending a private api client.
And ky handles all the hooks chains and other pre saved attributes for us. Very nifty
I don't use ky, i use ramlethal
the content-type mismatch while dealing with s3 goddamn
Funny that the comments are split between "wait, people still use axios?" and "wait, people stopped using axios?".
I still use axios (and query ofc), but only because headers and error handling and typing is better. Might switch to ky since that seems to handle all of that. Then again, not really sure I need to, axios works, and it's not a huge library (13kb vs 3kb for ky, it's not nothing but if you have one or two functional libraries like framer, three or something for charts, your bundle is already 200kb or more, 5% savings isn't worth the adjustment for me)
This is almost what I always do first things on a project, wrap fetch with a simple api that I can use with "get(url)", "post(url, data)", but I wrap it in a way that it always treats as content type json and the response is based on the content-type answered by the server, usually string for text/plain or object for application/json
What I have been doing all along is just like that, but without the extra .json() call and the extra { json: } in the post data, everything is JSON by default, things that aren't Json I just use fetch instead
I never made this into a library because it's really not a big deal
For vanilla React, react-query is the way to go. But I found very little need for use it, when building stuff with NextJS.
same here.
Fetch isn’t the problem. How you manage it is and react-query solves it
Have been using axios, but after this, it looks like I'll be switching to ky - so clean! Who wants to deal with fetch error handling?! You'd just end up wrapping it yourself anyway.
All those things you said about the useState -> useQuery transition apply to fetch -> ky inside that same code example... but useQuery gives you enough safety around queryFn that the impact is mitigated but I would argue it's better to control it. It does solve error cases from the API.
When you "switched it over to ky" you had _none_ of the proper affordances you needed in your plain fetch call. So it's a bigger win than you are letting on.
I still feel like fetch is a downgrade in DX from Axios (not comparing to plain XMLHttpRequest, obviously nicer than that).
You can't try catch out of the box since 3xx, 4xx isn't considered errors, you have to check response.ok.
You can't create instances like you can in axios, with predefined baseUrl and headers.
There is no built in interceptors.
If the answer to this is "Just build a wrapper", how is this any better than axios?
Its build in and way way smaller
You can reproduce api axios using fetch in much less code
@@untlsn I understand if bundle size is a big concern, but otherwise it feels like axios already had nailed down a solid way of handling HTTP requests, so why build a new wrapper to do the exact same thing?
Of course fetch is a huge upgrade from plain XMLHttpRequests in usability, but almost nobody uses plain XMLHttpRequests anyway.
So except from bundle size, I don't see any good reason to switch from axios to fetch at this point.
ky: Like fetch() but less horrible.
This is why I do ports and adapters. I can easily switch between fetch, axios or something else.
like 3 years ago "back in the day"
I just wrote my own request builder and solved the problem that way. It's easily maintainable and it's easy to use. Took me a few minutes to make and then I kept adding to it as I needed more stuff. There are obviously nice features in these libraries, but how often do you really need them?
I still use axios because it works really well with react-query
Significant wins usually come with mastering the lib in question. Abstraction always costs! React query exists but sounds like a react problem ...
I've had to help people countless times where they've used a library for something that the browser already has an api for.
It's been a pain every time due to me not understanding how it works, and having to read the docs for the library.
Yeah, it's smart. But not everyone wants to learn a new library every time a smart solution is made.
Sindre Sorhus is the backbone of modern web dev
Omfg, how hard is it to just write a function that houses common headers and a fetch() call? You don't need some artisan builder library to do this. Also do developers pay theo to signal boost their libraries? Why does he focus on one library when there are dozens of similar (and arguably better) libraries out there. At least he isn't signal boosting Zod again.
I usually just write an simple wrapper function handling all the specifics like headers, error handling, types etc. and just reuse this. No magic and 8kb libs needed
people really into giving edging names for simple wrapper functions
Hey , do any of you guys know what font Theo uses in Vscode ?
Thanks
I always thought that reason for fetch being so bad to work with was it being the first to come. Now that I know axios came first, it makes me think: How bad do the js language designers have to be to replicate a feature that was already made by community and yet do it badly.
Using ky since months ago. It is nice
What if the ky code was part of the browser's standard library? Would that make it better?
i can tell how senior you are if you argue that NIH Syndrome is a marker for how senior you are.
what you mean "you remember axios" 😭😭 i still use it to this day in every project
0:37 nothing can be perfect, tho.
Missing piece here would be ky working both in client and server side.
What about ofetch? Anyone heard of that? It uses a nice lib called destr that basically parses the response for you 99% of the time and returns text if it doesn't know
Ky and axios have one big advantage over pure fetch - middlewares
So you can change request and response on fly
Ky would be great if they added progress bar support in all browsers, however they will have to use xml or only support on chrome
I don't feel moving from axios
I'm calling the "Ky" library Kentucky and I refuse to stop
The fetch API was intended to be somewhat low level. It makes few assumptions about your request, which is a good thing for a low level API, but not really great for everyday development. That being the case, it's hardly surprising that someone would build a library like ky on top of it. What is surprising to me is that so many people continue to use fetch directly in spite of it being pretty inconvenient.
Me wrapping vue createFetch and just living the good life not caring about random people judgements. :)
I can totally see that viewpoint. It's not as big of a win from other libraries, just different, and different slows adoption. One might make a similar case with React Query as compared to Ky, but then if you use React in the first place then you shouldn't be writing vanilla code anyhow and then Query should already be in your toolkit. Of course, in my field, this is one of the reasons why I get angry with junior developers who use C without ever once learning the libraries that make using it faster and easier. Instead I find them rewriting everything from scratch. Unless you genuinely have a better means of accomplishing the task at hand, writing it from scratch, which here would be equivalent to writing vanilla JavaScript, is a big no no.
When he said let me ask "chat", I thought he was talking about ChatGPT
tbh I would prefer the openapi-fetch package over ky simply because it creates a contract between FE and BE. I don't need to check if I set the right endpoint path, also I don't need to set the response type manually, and most importantly, when I update the Open API schema, the typescript instantly shows what and where I should change in the codebase
The only thing that I'd like to change is how we can access the generated types. For now, I've decided to re-export those that I needed from a module with an openapi-fetch setup, but ideally, it would be great to import them from the package, as it was done in Prisma
ky kinda old news. sindre had that and "got" out years back
Abort controller and pass signal to fetch . You are good
Invented the abstraction of server calls. I hope nobody was impressed.
actually in axios@1.7.0 already include fetch adapter
How can the second request come before the first?
Theo, I thought react will discard the component of previous render if a prop has changed?? Would it really have a race condition there??
Yes, because React cannot implicitly abort a network request in transit. The `setState` function is stable across renders, meaning it will just act on the current component render iteration instead of the one where it was "created" in.
@@MrMudbill this is why I hate react honestly. useState is a huge rabbit hole.
@@MrMudbill I thought the function will disconnect but didn’t know the state is connected
I'd like a follow up to this discussion but including vercel's swr hooks.
if the endpoints you're calling happen to be compatible with ky's defaults, great. If not, good luck peeling that onion.
What defaults are you talking about? Non-2xx as errors? It's literally 1 line of code to "unpeel it".
Non-2xx as errors sounds weird, I didn’t think 1xx and 3xx codes were considered request errors
after I saw a content about ky from coderone I think it was last week. I created a custom fetch on top of fetch and called it butter. Since then I stopped using normal fetch lmao🤣
Is this really that “different” as you say it is? I mean you said it yourself that we have been using axios for years. Ky is really just building upon that using fetch underneath.
.json() is an Anti-Pattern in TS and explicitly forbidden to do in DefinitelyTyped because passing in a generic parmeter that only sets the return type (and does not depend on the input parameters) is a "hidden" type assertion. It is better to do `.json() as T` because that makes the type assertion visible as type assertions are the boundaries in which errors can sneak in.
A couple of years ago, I had the opportunity to migrate a bunch of jQuery ajax calls to fetch. Ky, actually looks interesting and I may consider it in the future if I ever get sick of writing fetch implementations.
I don't see the point in this being a library. My apps just have a 50 LoC 'api.ts' that defines a function for making API calls, with handling for retrying when the server is unreachable, automatically defines Content-Type, handles session expiry, etc etc.
Me and my POST function
Why doesn't .json() take a zod schema? .json() is just a lie waiting to happen.
What about server side rendering in next js
For me to shift from axios, it should have interceptor.
I just want to have 2 main paths, not 3
splitting the happy path into actual success and "I got some response I guess" is awkward
wym used axios :( i sitll use it 😥
ofetch, unjs is dope