You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose we ship complete fetch bindings in Core. This has a few reasons:
Fetch is as close as an industry standard as we'll get for making network requests. The default experience in ReScript today is to either a) roll your own fetch bindings (and have to understand everything with bindings etc) or b) install a package. This is a bad experience for something as fundamental as making network requests. Shipping bindings in Core would alleviate that.
Fetch is becoming ubiquitous in the JS world, not just in the browser as various server side (edge) runtimes and SSR frameworks rely on the fetch standard directly.
One thing to keep in mind is where we draw the line between Core and something like https://github.com/TheSpyder/rescript-webapi. I don't think bringing in fetch would blur that line, but it's worth keeping in mind.
The text was updated successfully, but these errors were encountered:
I think I'd favor making it a separate library, but still part of the "core" distribution. I see a modular approach being better because it allows for having different rules and guarantees. Not so much because of this one addition, but once you start adding more APIs I think the flexibility of having them be somewhat separate, but distributed together, I think it will be very valuable.
For example, fetch is available on node since version 17. But node 14 is still in LTS maintenance, and node 16 won't go out of maintenance until 2023-09-11. I think the APIs included in rescript-core ought to be guaranteed to work on LTS versions of node still in maintenance, unless clearly marked as having a higher requirement in the docstring of each function. And given that rule I don't think fetch should be included. But as a separate library in the same distribution I think it would be fine.
Either way, I'd be happy for these bindings to be based on rescript-fetch :)
Fetch is part of the WHATWG specification and interoperates with other specs such as URL and Web Streams. It will need to import large parts of webapi for this.
When Core takes over some of the web standards, what exact scope of its responsibilities can users expect?
I propose we ship complete fetch bindings in Core. This has a few reasons:
If people agree with what's stated above, and if @glennsl is fine with it, I propose we base our work on https://github.com/glennsl/rescript-fetch.
One thing to keep in mind is where we draw the line between Core and something like https://github.com/TheSpyder/rescript-webapi. I don't think bringing in
fetch
would blur that line, but it's worth keeping in mind.The text was updated successfully, but these errors were encountered: