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:

  • fetch has 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 fetch requests requires a lot of changes in logic because fetch does 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
is expecting the 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)