-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Provide isomorphic implementation of WHATWG fetch() API. #10029
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
Conversation
packages/fetch/fetch-tests.js
Outdated
// Write your tests here! | ||
// Here is an example. | ||
Tinytest.add('fetch - example', function (test) { | ||
test.equal(typeof fetch, "function"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need more tests, obviously!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No way - I like how manageable these tests are ... 🙂.
If anyone else wants to help replace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woohoo! This is great @benjamn - so far so great!
packages/fetch/fetch-tests.js
Outdated
// Write your tests here! | ||
// Here is an example. | ||
Tinytest.add('fetch - example', function (test) { | ||
test.equal(typeof fetch, "function"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No way - I like how manageable these tests are ... 🙂.
@benjamn what would the strategy be for replacing server-side calls that are now synchronous because of fibers. Just Promise.await the fetch? And what about error handling? HTTP package will throw if the status code is >= 400 (see https://github.com/meteor/meteor/blob/devel/packages/http/httpcall_server.js#L119 and https://github.com/meteor/meteor/blob/devel/packages/http/httpcall_client.js#L180), fetch will not do this. |
This PR is part of a longer-term plan to encourage developers to move away from fibers and towards existing web standards. So I would honestly recommend actually
Thanks for pointing that out! I don't consider |
My questions were a reply to #10029 (comment). So in the context of replacing HTTP in the current core packages, are those also the recommendations? Because awaiting in an async instead of relying on fibers would be a backwards incompatible change for end-users, which Meteor usually tries to prevent. Same thing for the errors. I agree that fetch shouldn't be a drop-in replacement for HTTP. Rather the opposite and it should just follow the fetch-spec. But handling errors differently might brake existing core packages. E.g. when they rely on a 404 throwing an error or something. |
I will replace HTTP in |
In light of @sebakerckhof's astute feedback, and in order to make this package available for use with the Let's make |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Additional fetch
tests seem like a good idea, and I agree with getting this out sooner rather than later, but I think we can also probably relish in certain (test) benefits we're gaining thanks to the existing tests that whatwg-fetch
and node-fetch
have to offer!
ba95309
to
a20f4e7
Compare
As described in my talk about Meteor 1.7's modern/legacy bundling system (relevant slides), the WHATWG
fetch()
API is a great example of a feature that requires a totally different implementation in modern browsers, legacy browsers, and Node.The
fetch()
API is already widely used in the JavaScript community, and I suspect it will eventually replace the core Meteorhttp
package for most HTTP request needs, especially since it is essentially free in modern browsers.