-
-
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 4a3b79f): https://yew-rs--pr3534-wasi-support-test-8w8rolp5.web.app (expires Mon, 02 Sep 2024 02:55:49 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
Benchmark - SSRYew Master
Pull Request
|
Size Comparison
✅ None of the examples has changed their size significantly. |
Since the CI check failure issue mentioned earlier has been fixed in the newer compiler version (1.80.1), it can now be merged again. I found that the benchmark CI of the |
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.
@langyo thanks for the ping, so sorry it look so long to get back to you and review the PR.
All the changes look good to me. Would you mind reverting the extra changes (reformat done by your editor)?
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.
Makes sense. We can tell users that they can use networking from p2 if they want but not force it upon them
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.
Also sorry for taking a long time to review :) Apart from the comments from @ranile I'm in the process of figuring out why the workflows are failing or whether that's just some change with the chromedriver.
packages/yew/src/functional/hooks/use_prepared_state/feat_hydration.rs
Outdated
Show resolved
Hide resolved
Although this commit is unlikely to support further improvements immediately, some small patches can be made. I added a feature called |
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.
Found a few more things, mostly about CI this time, but finally got a full overview of the whole PR so after this, I'm confident to merge.
Co-authored-by: WorldSEnder <[email protected]>
…browser environment.
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