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

Implement bytes_stream() for wasm. #1713

Merged

Conversation

dmeijboom
Copy link
Contributor

@dmeijboom dmeijboom commented Jan 4, 2023

Adds support of Response.bytes_stream() to the wasm32 target.

Follow up of: #1576
Fixes #1704

Todo:

  • Testing with our Yew based application (will do that tomorrow)

@seanmonstar
Copy link
Owner

I think a question I always had with this PR was what are the consequences of pulling in that crate. Sometimes wasm things surprise me. Are there any concerns that we should know about? Like does it require more specific wasm targets? Or if we change the dependency later, would that cause people issues?

@frewsxcv
Copy link
Contributor

frewsxcv commented Jan 5, 2023

I'm not aware of any concerns pulling in the wasm-streams crate. It solely supports wasm32-unknown-unknown, just like reqwest does (as far as I know). This wasm-streams API is not exposed in any way so removing it in the future would not be a breaking change.

@dmeijboom
Copy link
Contributor Author

I think a question I always had with this PR was what are the consequences of pulling in that crate.

The wasm-streams crate maps ReadableStream -> Stream and WritableStream to Sink. This is neat as we can keep the code similar to the non-wasm implementation. I couldn't find other libraries that are able to do this and it seems like the crate is at least somewhat mature (not a lot of open issues, tested on chrome & firefox, proper documentation etc.).

Sometimes wasm things surprise me.

Me too... 😅

Are there any concerns that we should know about? Like does it require more specific wasm targets? Or if we change the dependency later, would that cause people issues?

I think it should be fine. It supports wasm32-unknown-unknown which is what reqwest also supports. Also note that the return type is a Rust stream so even if we have to make changes later it shouldn't be breaking for reqwest wasm users as it's only used internally (right?).

@seanmonstar
Copy link
Owner

Alrighty, thanks for clarifying! We can merge, though looks like CI is grumpy.

Co-authored-by: muji <muji@tmpfs.org>
@dmeijboom dmeijboom force-pushed the feature/bytes-stream-wasm branch from 01bc4b2 to a4a549e Compare January 5, 2023 11:30
@dmeijboom
Copy link
Contributor Author

dmeijboom commented Jan 5, 2023

Alrighty, thanks for clarifying! We can merge, though looks like CI is grumpy.

Indeed. There was also an issue with imports that should only be imported if the stream feature is enabled. Fixed that as well!

Edit: tested this branch with our Yew app and that seems to work!

@seanmonstar seanmonstar merged commit 4d96adf into seanmonstar:master Jan 5, 2023
Nutomic pushed a commit to Nutomic/reqwest that referenced this pull request Nov 7, 2024
Co-authored-by: muji <muji@tmpfs.org>
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

Successfully merging this pull request may close these issues.

Implement Response.bytes_stream for wasm
3 participants