-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add WASI support for server-side rendering. #3534
base: master
Are you sure you want to change the base?
Conversation
It would be modified later after the corresponding library branches are merged.
Benchmark - coreYew Master
Pull Request
|
Visit the preview URL for this PR (updated for commit d42077a): https://yew-rs--pr3534-wasi-support-test-o6il3hlo.web.app (expires Thu, 23 May 2024 04:59:59 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
Benchmark - SSRYew Master
Pull Request
|
Size Comparison
✅ None of the examples has changed their size significantly. |
I am commenting separately because the original comment cannot be quoted directly. Ref #3534 (comment) There's still a problem. The WASI environment cannot directly establish a server like other environments. Because this part has not been standardized yet. In other words, I can only print the SSR results directly to the stdout stream for the time being. Originally I wanted to remove this demo, but I discovered this problem when checking other demos. If it weren't for this reason, this change would be really elegant. 😉 |
I haven't reviewed this PR, but I can confirm that it works in my use-case. Landing this WASI support would be amazing. |
This merge request has almost completed all scheduled work, but no one has continued to review it. Do you have time to help take a look? |
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 for the bump
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.
I thought preview2 added support for it, no? I don't mind forcing WASI consumers to use wasm32-wasip2 target
Yew supports single thread mode for server-side rendering by `yew::LocalServerRenderer`. This mode would work in a single thread environment like WASI. | ||
|
||
```rust | ||
// Build it by `wasm32-wasi` target |
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.
Preview 2, perhaps? It's nightly only but maybe it's better to use that. I'm totally fine with making WASI examples to be nightly only in yew (no need to make the framework nightly only for it; the consumption is much better in p2)
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.
Preview 2, perhaps? It's nightly only but maybe it's better to use that. I'm totally fine with making WASI examples to be nightly only in yew (no need to make the framework nightly only for it; the consumption is much better in p2)
WASI's multi-threading proposal is still not stable even in preview2. If it were not for compatibility with the multi-threaded version of WASI, at least currently requiring users to use nightly channels to build WASI would do more harm than good.
Of course, I still support the new proposal of using WASI as soon as possible. When WASI's multi-threading capabilities stabilize at some point in the future, I'll improve the code.
.github/workflows/main-checks.yml
Outdated
- ".github/workflows/main-checks.yml" | ||
- "ci/**" | ||
- "packages/**/*" | ||
- "Cargo.toml" | ||
- "Cargo.lock" | ||
- '.github/workflows/main-checks.yml' | ||
- 'ci/**' | ||
- 'packages/**/*' | ||
- 'Cargo.toml' | ||
- 'Cargo.lock' |
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.
This still needs to be resolved. Lots of unnecessary changes here
Co-authored-by: Elina <imelina@elina.website>
Do you have time to take a look?😂 @hamza1311 |
9e24e93
to
71951bd
Compare
Until this fix of |
Description
I've been trying to use
yew
to render the page into the static HTML string on WASI. However,yew
cannot distinguish the browser WASM target (wasm32-unknown-unknown
withwasm-bindgen
) and WASI target (wasm32-wasi
), and it would choose wrong modules forwasm32-*
.In addition, since the current SSR implementation will create new tasks directly in the asynchronous context directly (based on
prokio
). It only allowed in a multi-threaded environment that it is not compatible with WASI. So I added a dedicated one for a single-threaded environment that rendering function to support single-threaded scenes.To support this new feature, I have also made changes along with some other upstream dependencies. I've created some PRs for these upstream dependencies, and added a temporary patch entry to the root Cargo.toml for this PR. If the upstream branch can be processed, these temporary patch entries could be replaced.
I also wrote a short example for this new feature.
CC @futursolo 😉
Checklist