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

XmlHttpRequest (mid-level only) #37

Open
tomhoule opened this issue Mar 20, 2019 · 1 comment
Open

XmlHttpRequest (mid-level only) #37

tomhoule opened this issue Mar 20, 2019 · 1 comment

Comments

@tomhoule
Copy link

Summary

Provide "mid-level" bindings to the XMLHttpRequest API. "mid-level" in this case would mean a callback-based API to cover the whole of XHR, mirroring web_sys::XmlHttpRequest with more idiomatic Rust types and ergonomic improvements where possible without compromising fidelity to the original.

Motivation

The "blessed" browser API for HTTP going forward is fetch, but fetch does not provide all the features XMLHttpRequest does at the moment (one notable example being download/upload progress events).

This could also be used as a base for higher level bindings providing a more ergonomic interface from Rust, but I propose leaving it to a future discussion.

Detailed Explanation

The bindings would be implemented inside a new gloo-xhr crate in a callback top-level module, to leave room for a potential future-based wrapper built on of it.

Two examples to motivate why we would benefit from "mid-level" bindings, compared to raw web_sys:

  • Callbacks would be typed Rust closures.
  • We wouldn't have many methods to set the body of a request, like in web_sys, but a set_body method generic over a (for example) XhrRequestBody trait implemented by all valid body types.

The documentation should mention that fetch is the API that is currently being pushed forward in browsers and will eventually supersede XmlHttpRequest.

Drawbacks, Rationale, and Alternatives

Alternatively, these bindings could be grouped with the fetch bindings in a common gloo-http or gloo-ajax crate.

The implementation would aim to map as close as possible to the original web API; as such few design decisions should be necessary.

Unresolved Questions

Providing nice, ideally typed errors could be challenging, as the error cases in networking APIs are many.

@fitzgen
Copy link
Member

fitzgen commented Mar 22, 2019

Sounds good to me!

I like the idea of making a trait for request bodies.

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

No branches or pull requests

2 participants