[Blazor] Support serializing render fragments from SSR

[javiercn]

Currently we don't support serializing RenderFragments as root component parameters.

This has obvious drawbacks like our inability to render components with a body as a root component (That's why we need to have extra components like Routes.razor) on the template or why we can't have @RenderMode applied to things like Layout components.

To support these types of scenarios, we can support serializing the contents of the render fragment statically and re-applying those contents on the interactive side.

The way it will work is as follows:

• Everytime we render a component with a RenderMode (either on the component or at the call site), we'll look at the list of parameters and will wrap every RenderFragment component within a function that will capture the outputs produced by the render fragment.
• We will serialize that output as JSON (it's the RenderTree as JSON)
• On the interactive side, we will read that tree and pass in a RenderFragment delegate as parameter that just outputs that tree.

For the most part, this will work for static content and will also work for even components, provided that the parameters in the components are serializable.

This will mean that we can for example, apply @rendermode to things like CascadingValue provided that the T used is serializable, and the components inside the body are serializable too.

To avoid situations where we close over server state, we can require the compiler to make the function a static local function when it is passed to a component with a rendermode or @rendermode is used as an attribute. You could still get into weird situations if you try to access static variables, but I think that's acceptable.

[ghost]

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.

[ghost]

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.