Changing XHR to Fetch API by hmdros · Pull Request #1845 · freeCodeCamp/devdocs
hey @simon04 we were reviewing your comments and the code, and we have some concerns if this move from xhr to fetch is actually beneficial or not. I can describe a bit of what we found:
fetchhas no equivalent of a progress callback, the workarounds involve adding a lot of code wrapping the fetch requests into another object like https://dev.to/tqbit/how-to-monitor-the-progress-of-a-javascript-fetch-request-and-cancel-it-on-demand-107f or https://github.com/prioe/node-fetch-progress, but we are not sure if that's the direction you want to go with this code, it will be way more complex- the way the abort works with
fetchrequests requires a lot of changes in logic becausefetchdoes not return a request object that can be aborted, it returns a promise, so the abort callback would have to be passed as an option from the caller (it requires changing entry_page.coffee, entry.coffee, db.coffee, and ajax.coffee just to pass around an abort function)
Also, we noticed one thing that seems to be a bug in the current code, this error callback
| error: (_, xhr) => @onUpdateReady() if xhr.status is 404 |
xhr as the second argument, but that's actually passed as the third argument here | options.error?.call options.context, type, xhr, options |
We want to raise these concerns before continuing with this change, we are not sure if it's really worth it (the current code works just fine and some of the code around it was designed for how xhr works)