Consider a React Server Components-like Blazor hybrid

[leebenson]

React is experimenting with Server Components.

They allow certain components to run on the server while others remain on the client, and serialise state/DOM updates back to the client.

The headline benefits are:

• 'Zero bundle size' payloads for that which runs on the server.
• Privileged business logic can remain on the server -- DB access, APIs not available in the client, filesystem access, etc.
• Implicit loading, serialising changes back to the client DOM, sharing state.
• Client state is preserved when requesting server components.

The parallel with Blazor is akin to running WebAssembly + Blazor Server at once. Components run on the client by default, but if they're designated to be server components, they would run remotely, and patch the DOM over a SignalR circuit.

I think this paradigm could have tremendous benefits for Blazor beyond pre-rendering. Namely:

• All the same benefits of pre-rendering -- initial SSR on the first page and subsequent client-side logic + routing.

• A reduction in explicit API calls. In a typical pre-rendered app, the client/server would each implement a common interface; the server with the logic, the client with the explicit HttpClient call + deserialisation to get the data into a format that the client can continue with. Server Components would render this boilerplate moot-- calling a server component would implicitly execute on the server, and insert the HTML in place on the client, as Blazor Server already does now. No interfaces, no dual implementation.

• State management. Currently, sharing state between the server and the client means learning the API of a third-party lib, or rolling your own. If components could be designated to run on Blazor Server, state could operate in the same way as it already does for Blazor Server-- persisting over an open connection. The only 'state' that would cross the network is the data that is fed as props to the Blazor Server, and the resulting DOM diff back to the client.

• A greatly simplified mental model. Writing a common interface, implementing it once on the server and again on the client, using HttpClient, writing classes/records to represent the JSON serialized data exchanged back, wiring up controllers, figuring out a state serialisation strategy, avoiding heavier nuget packages out of concern for bundle sizes, considering code splitting... for many scenarios, all of this can go away.

There are some trade-offs with this feature:

1. Props passed to Blazor Server Components would need to be serialisable over the network. In React, that's typically scalar values and other types that can be represented with JSON.

2. Like Blazor Server, it'd only work with a hosted model. This is pretty obvious, of course-- it's a direct replacement in many scenarios for prerendering.

3. It'd have the same 'expense' as Blazor Server for persisting connections and managing state. But unlike Blazor Server, what's designated to run on the server would be opt-in-- not all-or-nothing.

Overall, I think this would be a significant win for Blazor. I can think of plenty of ways I could put this to use!

[javiercn]

@leebenson thanks for contacting us.

We are already looking at things like this as part of https://github.com/dotnet/aspnetcore/issues/29577

[ghost]

Thanks for contacting us. We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[jotosmurf]

We are already looking at things like this as part of #29577

@javiercn you accidentally mentioned this issue instead of referencing another one :-)

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[RChrisCoble]

Hello @danroth27, We would benefit from this concept as well for our Use Cases.

[ghost]

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.

[mkArtakMSFT]

Closing as we are taking the Blazor United approach which is going to address the same problems: https://github.com/dotnet/aspnetcore/issues/46636