Provide a mechanism for rendering Blazor pages statically even when the app is set up for interactive rendering

[danroth27]

We provide a way to opt into interactivity on a per page or component level. When interactivity is enabled globally, there should similarly be a way to opt out of interactivity so that architectural choices made for one part of your app don't limit your choices in other parts of your app. For example, you might have an app that is setup to use interactive WebAssembly rendering globally, but you want to add a page that only renders statically from the server.

[SteveSandersonMS]

The error page, which uses HttpContext to get the request ID

We already accounted for that when implementing error support. No matter how your app is set up, the error page will render non-interactively automatically.

Scaffolded CRUD pages that interact with EF Core to handle data interactions

Can you clarify? Why wouldn't you want those to be interactive? Those sorts of pages are full of reasons to have interactive behaviors. Shouldn't it be up to the developer to choose whether CRUD pages use interactive rendering or not?

The default Identity UI, that uses server based functionality for user identity and account management

I agree about this, although (1) we already have an adequate workaround, and (2) it's only a point-in-time limitation that the Identity UI pages are not coded in such a way that they work nicely in interactive mode. Longer term it would be best if we did make them work properly in interactive mode (and yes they will have to do something nonobvious to set cookies).

Please don't interpret this as rejecting the feature request. I totally agree developers should have the flexibility to do this anywhere that they want. I'm just trying to sharpen up the definition of the scenarios to make sure we don't optimize the design for the wrong things. My justification for the feature would be something like "in per-page mode you can opt into interactivity, so in global mode you should be able to opt out of interactivity - in both cases so that architectural choices made for one part of your app don't limit your choices in other parts of your app"

[danroth27]

We already accounted for that when implementing error support. No matter how your app is set up, the error page will render non-interactively automatically.

How is this accomplished?

Can you clarify? Why wouldn't you want those to be interactive? Those sorts of pages are full of reasons to have interactive behaviors. Shouldn't it be up to the developer to choose whether CRUD pages use interactive rendering or not?

You're correct that interactivity may be desired. I was focusing on static server rendering to simplify the scenario and to get to parity with the scaffolding support we have for MVC & Razor Pages. Interactive server rendering should be relatively straightforward to support since the code is still running from the server. Interactive WebAssembly rendering however adds a bunch of complexity because it requires a different data access strategy (API endpoints, HTTP requests, etc).

it's only a point-in-time limitation that the Identity UI pages are not coded in such a way that they work nicely in interactive mode. Longer term it would be best if we did make them work properly in interactive mode (and yes they will have to do something nonobvious to set cookies).

In addition to figuring out a way to set the cookies presumably we'll need a way to abstract access to the identity related services and data. For some components, it does seem like supporting all render modes introduces a significant amount of complexity currently.

My justification for the feature would be something like "in per-page mode you can opt into interactivity, so in global mode you should be able to opt out of interactivity - in both cases so that architectural choices made for one part of your app don't limit your choices in other parts of your app"

Agreed. I'm happy to update the original post description accordingly.

[SteveSandersonMS]

How is this accomplished?

Internal stuff, not exposed as public API. The renderer explicitly checks if the current HttpContext contains IErrorHandlingFeature or whatever it's called - the thing that's the error handling middlware places there when re-running the pipeline.

For some components, it does seem like supporting all render modes introduces a significant amount of complexity currently.

Definitely. Just handling SSR + InteractiveServer is not so much complexity (except in some edge cases where you have to be able to set cookies), but I definitely agree that InteractiveWebAssembly adds a whole extra dimension. Limiting the scaffolding to SSR + InteractiveServer would be a pretty reasonable option.

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.

[gabephudson]

This feature would be extremely useful for global InteractiveServer projects that want certain components/pages to render statically. In Blazor 8, it is currently tricky to do this.

I'm trying to convert a large(ish) Blazor Server 7 app to the new Blazor 8 web pattern and am having A LOT of issues unless I keep it globally InteractiveServer, especially with third party Blazor components.

This would allow me to carve out pages that can run statically. Currently, setting the rendermode on individual pages doesn't work, as it causes the circuit to drop and create a new one on each page (and the app relies on scoped services currently). :(

(I tried setting rendermode option in _Imports.Razor file, but as you know, it doesn't function there. Dan suggests I try using the Router to do this.)

My simple goal is to have a default global "InteractiveServer" render mode (primarily to keep a single circuit open across the app), but to be able to specify components as static when needed.

I understand this will be less useful for new apps, but it will really help with converting existing apps.