Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Ship fetch bindings in Core #76

Open
zth opened this issue Feb 27, 2023 · 2 comments
Open

[Proposal] Ship fetch bindings in Core #76

zth opened this issue Feb 27, 2023 · 2 comments
Labels
proposal Proposals for changes to Core.

Comments

@zth
Copy link
Collaborator

zth commented Feb 27, 2023

I propose we ship complete fetch bindings in Core. This has a few reasons:

  1. 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.
  2. 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.

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.

@zth zth added the proposal Proposals for changes to Core. label Feb 27, 2023
@glennsl
Copy link
Contributor

glennsl commented Feb 28, 2023

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 :)

@cometkim
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Proposals for changes to Core.
Projects
None yet
Development

No branches or pull requests

3 participants