-
Notifications
You must be signed in to change notification settings - Fork 960
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
feat(websocket-websys): add support for different WASM environments #4889
Conversation
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.
For some added context: this uses the same approach as for gloo-timers: rustwasm/gloo#185, extended already by the codegen fix of rustwasm/gloo#283.
This makes it possible to run this transport in environments that support setInterval
, but don't have a window
global. This way it also works in NodeJS, Deno and Bun (although Deno provides a window
for compatibility).
setInterval
and clearInterval
functions
I've updated the PR description to reflect what I think is what is happening here, let me know if that is correct. |
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.
Thanks!
I am not entirely opposed to this change but it isn't particularly clean. The idea of libp2p-websocket-websys
was that we provide WASM bindings via web-sys.
We are now working around the web-sys
crate which is a bit odd. Would it make sense to perhaps upstream this change to web-sys
instead by offering setInterval
and clearInterval
as top-level functions instead of always going through window
?
Unfortunately, there was no interest in web-sys last time this was brought up, and not since: rustwasm/wasm-bindgen#1046. As you can see at the bottom of that PR, lots of people had to implement this themselves already. Another method to do it is with an enum over window vs. worker, like this: Globidev/reqwest@9898e62 A third way is unchecked-casting |
I think I'd prefer this. It is unfortunate that Mind updating the PR and the description to explain the solution? |
setInterval
and clearInterval
functions
Sure. Done. And also implemented the requested changes in the review. |
Ah wait, I thought this was referring to the current implementation but now that I read it again with the quote I think you meant this. In this case, I'll update the PR with this. |
Yeah I was referring to an implementation that uses an enum and detects the context accordingly! :) |
f042762
to
7bca8b6
Compare
Ok, now it's updated with this implementation. Let me know if you have more comments. |
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.
Thank you!
Overall concept looks great, just a few nits :)
Add support different WASM environments (such as workers, NodeJS) that don't have a `window` global. This is done by introducing a `WebContext` `enum` that abstracts and detects the `Window` vs the `WorkerGlobalScope` API. This is done due to the `web-sys` lack of interest to support this (see discussion in [this issue](rustwasm/wasm-bindgen#1046)).
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.
Great work!
Thank you for iterating on this with me :)
We don't have any automated tests for web workers, mind testing this PR manually on your end before we merge it? |
Already did for web workers :) |
Go back to upstream libp2p. With the release of `libp2p` 0.53.2, the `websocket-websys` transport was upgraded to `0.3.1` which also ships [this fix](libp2p/rust-libp2p#4889) that forced us to fork `libp2p` temporarily.
Description
We introduce a
WebContext
enum
that abstracts and detects theWindow
vs theWorkerGlobalScope
API.Related: rustwasm/wasm-bindgen#1046.
Change checklist