Added a more updated alternative to isomorphic-fetch. #272
Conversation
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed. If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
lquixada
changed the title
| module.exports = require('isomorphic-fetch'); | ||
| } | ||
| // Add a universal fetch polyfill (React Native compatible) | ||
| require('cross-fetch/polyfill') |
There was a problem hiding this comment.
I never really wanted to use a polyfill here - requiring ideally shouldn't mutate global state.
Would it maybe make sense to to not require the polyfill here if global.fetch exists (basically what we had here before and only replace the require('isomorphic-fetch') call?
I actually forget which of our users are even using this. I think it's just relay-classic and I'm sure they aren't depending on it actually being a polyfill so it's probably ok. We were also already deferring to ReactNative's or the browser if in those environments without polyfilling. What do you think?
There was a problem hiding this comment.
Totally agree with not touching the global state. I only suggested the polyfill because requiring isomorphic-fetch do that automatically. So I wanted to do a 1:1 conversion.
However, for the sake of consistency, I think it's better to depend on one implementation, be it the native one or the third-party one. The code in question relies on both leading to the same problem polyfill faces as sindresorhus discusses here.
For instance, if fetch spec receives a new feature and it's deployed to the browser, the chosen fallback library might not follow that improvement or might take long to publish it.
So, my suggestion is to use only the native fetch (consistent but gets some environments uncovered), to use only a third-party library (consistent but adds more codebase) or to leave this decision to the users.
There was a problem hiding this comment.
hi @zpao! any news on this matter?
|
upgraded the isomorphic-fetch alternative to version 3. |
isomorphic-fetch hasn't been updated for a while, so cross-fetch was created in order to provide a more updated, flexible and fixed alternative to the community.