Am I wrong or is this going to retry 404's and other 4xx things that it shouldn't retry?
Retry XMLHttpRequest Carefully
11–20 of 23 posts
Re: Retry XMLHttpRequest Carefully
#12This post reminded of a /fun/ bug I ran into at my last job. The root of the issue was our server was returning a 408 timeout error when something timed out on the backend. Astute readers might immediately notice an issue with that code, mainly that it's for a /client/ timeout not 504 (server timeout). Since we controlled the client and server you might think it doesn't matter much, as long as the client knows how to…
Really curious what the use case is for dev tools hiding a network request from you?
Sure, don't display it in the UI, but if the browser is retrying something I sure want to know about it when debugging!
Odd.
Re: Retry XMLHttpRequest Carefully
#13This post reminded of a /fun/ bug I ran into at my last job. The root of the issue was our server was returning a 408 timeout error when something timed out on the backend. Astute readers might immediately notice an issue with that code, mainly that it's for a /client/ timeout not 504 (server timeout). Since we controlled the client and server you might think it doesn't matter much, as long as the client knows how to…
Really curious what the use case is for dev tools hiding a network request from you? Sure, don't display it in the UI, but if the browser is retrying something I sure want to know about it when debugging! Odd.
Yeah, that was my thought as well. It threw me for a loop because I never would have expected that my browser dev tools would hide something like that. It was a core tenant of my debugging that was broken.
Re: Retry XMLHttpRequest Carefully
#14Just use axios and https://www.npmjs.com/package/retry-axios
Or node-fetch and @adobe/node-fetch-retry.
Re: Retry XMLHttpRequest Carefully
#15Very nice write-up. I'd be curious to see it using fetch rather than the older xhr Api - that would make more sense as a library today I think? Or are there compelling reasons to stick with xhr in a post-ie world?
I still use xhr because of familiarity. Using a javascript closure as a callback in xhr works quite well and seems much easier to me than dealing with the promises that are required for fetch. (I understand what promises are; I just think the ones in javascript are poorly-defined.)
https://pouchdb.com/2015/05/18/we-have-a-problem-with-promis...
Re: Retry XMLHttpRequest Carefully
#16Very nice write-up. I'd be curious to see it using fetch rather than the older xhr Api - that would make more sense as a library today I think? Or are there compelling reasons to stick with xhr in a post-ie world?
I still use xhr because of familiarity. Using a javascript closure as a callback in xhr works quite well and seems much easier to me than dealing with the promises that are required for fetch. (I understand what promises are; I just think the ones in javascript are poorly-defined.) https://pouchdb.com/2015/05/18/we-have-a-problem-with-promis...
From the end of the article you linked:
> Awaiting async/await
> That's the point I made in "Taming the asynchronous beast with ES7", where I explored the ES7 async/await keywords, and how they integrate promises more deeply into the language. Instead of having to write pseudo-synchronous code (with a fake catch() method that's kinda like catch, but not really), ES7 will allow us to use the real try/catch/return keywords, just like we learned in CS 101.
> This is a huge boon to JavaScript as a language. Because in the end, these promise anti-patterns will still keep cropping up, as long as our tools don't tell us when we're making a mistake.
Async/await is extremely well-supported and reliable in the ecosystem now, and allows you to express Promise-based asynchronous flows with a much more natural syntax. I highly recommend that you take a look, as it pretty much obviates all the pain points mentioned in the linked article.
Re: Retry XMLHttpRequest Carefully
#17This is a good introduction to the subject. At the end you might want to mention rate limiting, truncation (giving up after a specified number of retries) and, for the most sophistication, circuit breakers.
Thank you for your suggestions! I'll see if I can write a few intelligent sentences on these (somewhat more advanced) subjects.
If every developer just did what you advise and no more, I would consider it a big win. I saw at a previous employer exactly how much extra work and complexity we had to build into our operations just to deal with clients using dumb simple retry loops.
Re: Retry XMLHttpRequest Carefully
#18Earlier quoted context omitted.
I still use xhr because of familiarity. Using a javascript closure as a callback in xhr works quite well and seems much easier to me than dealing with the promises that are required for fetch. (I understand what promises are; I just think the ones in javascript are poorly-defined.) https://pouchdb.com/2015/05/18/we-have-a-problem-with-promis...
From the end of the article you linked: > Awaiting async/await > That's the point I made in "Taming the asynchronous beast with ES7", where I explored the ES7 async/await keywords, and how they integrate promises more deeply into the language. Instead of having to write pseudo-synchronous code (with a fake catch() method that's kinda like catch, but not really), ES7 will allow us to use the real try/catch/return keyw…
I'll do that. The whole promise chaining thing seems very awkward to me, and I stopped investigating promise-based solutions because I was under the impression that "everybody" preferred promise chaining to async/await. Maybe that's exactly the reason I might prefer async/await ;-)
Re: Retry XMLHttpRequest Carefully
#19This post reminded of a /fun/ bug I ran into at my last job. The root of the issue was our server was returning a 408 timeout error when something timed out on the backend. Astute readers might immediately notice an issue with that code, mainly that it's for a /client/ timeout not 504 (server timeout). Since we controlled the client and server you might think it doesn't matter much, as long as the client knows how to…
Really curious what the use case is for dev tools hiding a network request from you? Sure, don't display it in the UI, but if the browser is retrying something I sure want to know about it when debugging! Odd.
The same happens with CORS preflight requests. https://httptoolkit.tech/blog/chrome-79-doesnt-show-cors-pre...
Re: Retry XMLHttpRequest Carefully
#20Very nice write-up. I'd be curious to see it using fetch rather than the older xhr Api - that would make more sense as a library today I think? Or are there compelling reasons to stick with xhr in a post-ie world?
The only thing I’ve seen that I’ve hit recently is fetch doesn’t have a progress API.
Use case: I was fetching a large image from a server to render into a canvas and I wanted to show a progress bar for the download. AFAIK there is no way to do this with fetch