I just realized that in NextJS, XMLHTTPRequest can be inconvenient since NextJS is SSR as well as client side, so that might cause trouble on SSR. Fetch has an isomorphic fetch. I wonder how could we tackle this in isomorphic frameworks
Yeah I am currently having the same issues in my project and am already working on a sane solution for a proper XHR polyfill process for Next.
I will post my approach here when I’ve figured it out (also with an example on how to chain requests easily w/ proper chain cancellation), unless you beat me to it .
Generally I don’t think it’s such a big deal to do the polyfill ourselves, but it’s just a little annoying that the general direction of the JS community is basically the heavy weight promise route without any sane cancellation process whatsoever.
I checked out the AbortionController apis and I was not pleased.
I’m still not convinced the overhead of the promises is such a big deal, especially compared to the network requests. Of course, they have other issues, including lack of cancellation.
I think we need to take a few steps back to explain what we are currently trying to do from a language perspective:
What we want for ReScript is the smallest possible async building block that is properly cancelable without much overhead. If we’d go out and build our lowest layer on top of promises, things will be bad for following reasons:
- you need to allocate an AbortionController and a promise for every request you do, otherwise you’d loose out on cancelabiilty (also AbortionController.abort is still experimental)
- Promises are not sound and hard to handle in our type system without an extra layer (see reason-promise discussion)
- Promises can easily be constructed from our potential low level parts, but not the other way round
- Handling error paths / composition with promises is hard, especially when using
async / awaitin JS… it’s mostly about “happy-path” programming where everything goes right
Of course we can’t just ignore Promises all together, you can still use them if you want (converting to promises is actually easy), but we want to offer our community a ReScript specific async story that focuses on performance and correctness (with proper error handling and cancellation).