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: avoid incompatibility with web APIs #1120

Open
Gozala opened this issue Mar 18, 2021 · 0 comments
Open

Proposal: avoid incompatibility with web APIs #1120

Gozala opened this issue Mar 18, 2021 · 0 comments

Comments

@Gozala
Copy link
Contributor

Gozala commented Mar 18, 2021

Is your feature request related to a problem? Please describe.

node-fetch overloads body on Request / Response objects by using node native streams as opposed to web standard streams. It also makes assumptions about .stream() method on Blobs to be node streams as opposed to web streams.

Describe the solution you'd like

I would like to propose an alternative which can retain convenience of having node native streams in node without creating a problem for libraries that expect web streams instead of node streams. I would like to propose:

  1. Renaming .body to something else that does not overload standard field e.g. body.toNodeStream() method (Could be whatever other name as long as it's less prone to conflict with current and future fields).
  2. Rename current blob.stream() method on blobs to blob.toNodeStream() method as well.

That would retain convenience of having node streams without introducing conflicts. With that in place web standard compatible fields could be added:

  1. body getter that can wrap this.toNodeStream() into a web ReadableStream.
  2. blob.stream() that would also just wrap this.toNodeStream().

Also it is possible to leave out last two. Third party library could just wrap node-fetch , fetch-blob to bring a desired compatibility.

Describe alternatives you've considered

  • Forking and replacing node streams with web streams, which would be unfortunate and would lead to fragmentation as opposed to cooperation.
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

1 participant