Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove vendored fetch polyfill, update to email@example.com #24418
The original reason for vendoring the fetch polyfill was to remove the default blob response type but this was reverted.
Here's a little history around the fetch polyfill and the blob issue:
Currently the vendored fetch polyfill is useless since it was changed back to the original version. We can just use the npm version again. I also updated to 3.0 which brings better spec compliance and support for cancellation via
[General] [Changed] - Remove vendored fetch polyfill, update to firstname.lastname@example.org
Tested using fetch in RN tester to make sure everything still works.
Summary: This adds https://github.com/mysticatea/abort-controller to polyfill [AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController). This is used to cancel requests when using `fetch`. This also updates `event-target-shim` to 5.0 to make sure we only have one version of this dependency. This updates required adding a polyfill for `console.assert` which is used by the new version. I made one based on https://github.com/gskinner/console-polyfill/blob/master/console.js#L74. The polyfill is very small, especially since we already use `event-target-shim` so I think it makes sense to include in core. Depends on #24418 so that the fetch polyfill supports the `signal` parameter. Fixes #18115 [General] [Added] - Add support for cancelling fetch requests with AbortController Pull Request resolved: #24419 Differential Revision: D14912858 Pulled By: cpojer fbshipit-source-id: 8a6402910398db51e2f3e3262f07aabdf68fcf72
Ahha, after mentioned by @zhigang1992, I found fetch is to be managed by npm directly, I created a PR #24726 to fix fetch
Hello, I'm one of the authors and maintainers of whatwg-fetch
I'm happy to learn that adding
I have also found this puzzling comment:
Can anyone explain is this still relevant? Is there something we can tweak in whatwg-fetch to make this workaround obsolete?
Finally, what is the reason React Native bundles a
I don't have context on the comment so I can't help there.
Summary: The old whatwg-fetch module doesn't actually export anything, so we would always hit the `else` condition. The new whatwg-fetch (3.0.0, introduced in #24418) now exports an ES module. As a result, `whatwg` and `whatwg.fetch` are both truthy but the `module.exports` will end up empty. This breaks the RN fetch module. This will switch the behavior back to the expected polyfill behavior (calling `require('whatwg-fetch')` and allowing it to polyfill fetch in global scope). The RN fetch module will re-export these globals. Reviewed By: cpojer Differential Revision: D15639851 fbshipit-source-id: ebd8bce85f7797d8539f53982e515ac47f6425e7
Summary: The original reason for vendoring the fetch polyfill was to remove the default blob response type but this was reverted. Here's a little history around the fetch polyfill and the blob issue: - Original commit introducing the vendored polyfill: #19333, the goal was to fix a memory leak because our blob implementation doesn't release resources automatically. Not an ideal fix but since the issue was pretty severe and the infra for a proper fix was not in place. - This introduced an issue when downloading images using `fetch` which was fixed by #22063 which re-added the default blob content type. However that re-introduced the original fetch memory leak. - We have better infra now with jsi and I was able to get blob deallocation working, see #24405 Currently the vendored fetch polyfill is useless since it was changed back to the original version. We can just use the npm version again. I also updated to 3.0 which brings better spec compliance and support for cancellation via `AbortController`, https://github.com/github/fetch/releases/tag/v3.0.0. ## Changelog [General] [Changed] - Remove vendored fetch polyfill, update to email@example.com Pull Request resolved: #24418 Differential Revision: D14932683 Pulled By: cpojer fbshipit-source-id: 915e3d25978e8b9d7507ed807e7fba45aa88385a