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

Avoid completely replacing the DOM when Blazor components are re-rendered after prerendering #42561

Open
javiercn opened this issue Jul 4, 2022 · 12 comments
Assignees
Labels
area-blazor Includes: Blazor, Razor Components enhancement This issue represents an ask for new feature or an enhancement to an existing one Pillar: Technical Debt Priority:1 Work that is critical for the release, but we could probably ship without
Milestone

Comments

@javiercn
Copy link
Member

javiercn commented Jul 4, 2022

Right now, after prerendering we replace the entire contents of the prerendered component with a fresh DOM copy created from scratch. This has several bad side-effects like:

  • Videos are stopped and restarted
  • Animations can be retriggered
  • The page can flicker if CSS is injected as part of the head contents.
  • LCP score suffers because (even though there is no significant visual change in most cases) the tools detect the interactive DOM insertion as the LCP element.

Instead of replacing the contents of the DOM wholesale, we can do a best effort to reconciliate the DOM with the new rendered DOM when we are trying to apply the render batch.

In an ideal scenario, a developer should be able to produce exact prerenders, meaning that the render after prerendering is identical to the prerendered one.

In that case, the renderer would only need to "attach" event handlers to the appropriate nodes, leaving everything else the same.

The renderer does not have to be perfect and handle all possible scenarios, it can impose strict limitations and "bail out" if it can't figure out how to reconcile a given DOM subtree by replacing that node wholesale.

For example, the render can impose a strict order, suggesting that DOM children nodes in a given subtree must appear in the same order as the prerendered node (in other words, the renderer won't search for them, but iterate in order). A similar restriction might be imposed on attributes (which is not rare, since attributes are emitted in compilation order, except for splatting). Things like @key could be leveraged during prerendering too to offer a bit more flexibility in the ordering.

In general, this will likely result in a much higher node reuse and will give the developers the chance to always get this right.

@javiercn javiercn added area-blazor Includes: Blazor, Razor Components feature-prerendering Issues related to prerendering blazor components labels Jul 4, 2022
@javiercn javiercn added this to the .NET 7 Planning milestone Jul 4, 2022
@ghost
Copy link

ghost commented Jul 4, 2022

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@mkArtakMSFT mkArtakMSFT added the enhancement This issue represents an ask for new feature or an enhancement to an existing one label Sep 20, 2022
@mkArtakMSFT mkArtakMSFT added the Priority:1 Work that is critical for the release, but we could probably ship without label Nov 10, 2022
@3hxx
Copy link

3hxx commented Nov 21, 2022

Yes yes yes. This is long overdue my guys 🙏😍😇

@aryehsilver
Copy link

Great to see this is finally being worked on. Let's hope it doesn't get pushed off any longer.

@fingers10
Copy link

You can refer ilovedotnet for this issue. The site is built from scratch using blazor wasm and the site also facing flicker issue when it gets loaded. The site has prerendering enabled during publish time in the pipeline. When the site loads the prerendered screen appears and when the blazor engine kicks in, there comes a flash and screen appears after that.

@ghost
Copy link

ghost commented Mar 3, 2023

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@ghost
Copy link

ghost commented Dec 13, 2023

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@kevon-vems
Copy link

Following

@oluatte
Copy link

oluatte commented Jan 17, 2024

Also interested in this. We're building a consumer facing web app & the flicker is very noticeable.

@rogihee
Copy link
Contributor

rogihee commented Jan 23, 2024

This one hurts pretty badly with .NET 8 if you have SSR with any kind of interactivity somewhere

@andersme
Copy link

andersme commented May 3, 2024

This one hurts pretty badly with .NET 8 if you have SSR with any kind of interactivity somewhere

Agreed. Without making this transition seamless, SSR is pretty useless right now. This is a must-have to compete with the competitors in the market.

@andersme
Copy link

This one hurts pretty badly with .NET 8 if you have SSR with any kind of interactivity somewhere

Agreed. Without making this transition seamless, SSR is pretty useless right now. This is a must-have to compete with the competitors in the market.

And now I've simply replaced the WebAssembly interactivity with HTMX. What a cobbled mess Blazor has become.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-blazor Includes: Blazor, Razor Components enhancement This issue represents an ask for new feature or an enhancement to an existing one Pillar: Technical Debt Priority:1 Work that is critical for the release, but we could probably ship without
Projects
None yet
Development

No branches or pull requests