Server-side Rendering (without hydration)#2335
Conversation
|
Visit the preview URL for this PR (updated for commit 3567689): https://yew-rs--pr2335-ssr-fuscyfij.web.app (expires Wed, 19 Jan 2022 13:51:11 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
|
I just read the title and already my reaction is 😲 |
|
🤯 🤯 🤯 🤯 🤯 🤯 🤯 🤯 thank you! |
|
wow, it's historical moment 😆 |
|
@futursolo Could you convert this into a draft if its not ready to be reviewed? I keep seeing new commits. |
it's ready since I submitted it. I am just doing some improvement on the docs so ssr would show as a feature flag as nobody is reviewing it at the moment. (If you keep seeing notifications, I am sorry. I guess I will stop doing it.) |
ranile
left a comment
There was a problem hiding this comment.
I wonder how routing would handed. yew-router can't work with SSR
|
I am so sorry I'm taking so long to review this. |
@voidpumpkin, I'd say that testing the API can be done any time before release. How about you review the code changes and leave the rest for later (when hydration is in place)? |
|
@futursolo Could you split out simple ssr example to only have one component per file. |
I don't think this is a good thing to do and most examples don't follow this rule either.
I am not writing Java or Angular, am I? |
I guess its just a preference. Ok i wont block the pr because of this |
voidpumpkin
left a comment
There was a problem hiding this comment.
Took me some time because i have little experience with ssr. But from what i gather i don't see any issues at the moment.
| // But you can create a sidebar manually | ||
| sidebar: [ | ||
| // But you can create a sidebar manually | ||
| sidebar: [ |
There was a problem hiding this comment.
we seriously need to add a formatting hook to commits as every person keeps formatting this file differently.
|
There's conflicts... |
# Conflicts: # packages/yew/Cargo.toml
| @@ -0,0 +1,6 @@ | |||
| # Server-side Rendering Example | |||
There was a problem hiding this comment.
You forgot to add your example in the table in examples/README.md
But don't add it now, I'm changing that table so ill just add it in my PR.
# Conflicts: # packages/yew/src/lib.rs
|
This was already approved by @voidpumpkin so merging it as 2 review requirement has been met. |
* Basic render to html implementation. * Remove HtmlWriter. * Escape html content. * Add non-suspense tests. * Add Suspense tests. * Gated "ssr" feature. * Add example. * Fix tests. * Fix docs. * Fix heading size. * Remove the unused YewRenderer. * Remove extra comment. * unify naming. * Update docs. * Update docs. * Update docs. * Isolate spawn_local. * Add doc flags. * Add ssr feature to docs. * Move ServerRenderer into their own file. * Fix docs. * Update features and docs. * Fix example. * Adjust comment position. * Fix effects being wrongly called when a component is suspended. * Fix clippy. * Uuid & no double boxing. Co-authored-by: Muhammad Hamza <muhammadhamza1311@gmail.com>

Description
This PR introduces a
ServerRendererthat can be used to render a Component into a String.The primary difference between the original API outlined in #1154 and this PR is that
render()is anasync fnwhich supports data-fetching during the rendering process via<Suspense />.One caveat is that
render()is!Senddue to the use ofRcandRefCellthroughout the entire library (and fields containingweb_sysstructs such asElement). This may cause issues when trying to useYewwith libraries that require aFuture + Sendfuture but can be worked around.I think there's not a big enough incentive to replace everything with their sync counterpart so I have decided to make render
!Send.Most Web APIs are not gated and will be compiled in as-is when used on non-wasm targets.
Due to the following reasons:
Sendwith only removal of Web APIs anyways.)NodeRef) on both server side and client side ifweb_sysis not allowed. Hence requires developer to also use feature flags to distinguish between client side and server side. I see very little reason to use feature flags if a boundary of client-side only logics can be easily established withuse_effect.(Using feature flags can be annoying from time to time as it sometimes can be easily forgotten and it's fairly easy to trigger false positive lints like
unused_variables, etc.)Fixes #1154
Fixes #1155
I have noticed that #2330 is filed in the meanwhile and I anticipate to take some time before a decision can be made on it.
So I have decided to file the server-side rending part first which should be easy to solve conflict should either this PR or #2330 is merged first. And see how #2330 goes before I work on the hydration part.
Checklist
cargo make pr-flow