Blazor 8: Server side rendering with interactive layout

Layouts can be placed on both the server and client side, and each page can choose which layout it wants to use. SSR pages on the server can use layouts on the client. As far as I know (AFAIK), SSR pages are just interactive components/pages minus events, i.e., you have the full component life cycle and properties/methods, etc.

I have not found what I would call a "have your cake and eat it" mode after spending the last four days trying God knows how many different combinations of settings and component locations.

Given your comments, my assumption is that you would like pretty much the old client Web Assembly project with server-side API and a few SSR pages. If that is the case, then yes, this is possible, but there are a couple of gotchas to take into account.

Take a quick look at the new project templates and select the Web Assembly/global project with individual accounts (just for pointers). This will create SSR pages on the server, with a router and other stuff on the client. The magic for this is in the App.razor file on the server:

private IComponentRenderMode? RenderModeForPage => HttpContext.Request.Path.StartsWithSegments("/Account") ? null : InteractiveWebAssembly;

A null render mode means it's an SSR page.

Now, create your own Web Assembly/global project without the account stuff and alter the App.razor so you can have WASM with SSR pages; it all works fine. Now for the quirks.

1. You are on your WASM pages, navigating with or without the internet; all is good; it's cached on the client side.
2. You navigate to an SSR page; it goes to the server, and the App.Razor server page is run, and then your SSR page; all is well.

The quirks/gotchas:

3. You navigate to a WASM page, it goes back to the server and does the whole prerender thing and then runs on the client again. I have not found a way to stop this behaviour; I do not know why it needs to do this.

4a. You are on the SSR page, and you lose the internet connection; you now cannot navigate anywhere; you are just stuck on the SSR page until the internet comes back.

4b. You lose the internet while on WASM (no problem); you navigate to the SSR page and get the "You're not connected page"; you then try to go back to your cached WASM pages; nothing works; you are stuck on the not connected page until the internet comes back.

4b is not too much of an issue; just check for the internet before navigation. 4a not sure how to solve this one, and 3 just bugs the hell out of me.

All of the new project template selections/types have varying degrees of quirks and gotchas.

I have spent the last year and a half with the old-style WASM and API server path (with gRPC), no prerendering or Blazor server, without problem.

The new auto per component project is very appealing, but it is no silver bullet. It's the route I will probably go unless requirements dictate otherwise. But the last four days spent banging my head against a brick wall with the varying options and gotchas have shown me what code-arounds I would need to put in place to make things work the way I want (excluding the fetch to the server even with navigating between WASM pages). So, I am prepared if I do decide to go that route.

Please post your findings. I, for one, would be grateful for any additional findings by others, so I know more about what I would be facing depending on the project selection.

Hope my findings are of some use.

I do no have points to allow a comment so I have had to add another answer to clarify a couple of things for @epoch and the OP.

As far as I know (currently), if you want to have mixed modes (SSR and WASM, SSR, WASM and Server), then auto per component/page project (currently) is most likely the best way to go, with the router on the server side. Again, as far as I understand, route discovery is determined by AddAdditionalAssemblies(typeof(Client._Imports).Assembly) in the server program.cs file and from the router, either on the server or client.

Currently (it may change, or it may be bugs, I do not know), if you have the router on the client and, say, a server interactive page on the server, going from the client to server runs the server component/page; it displays, then immediately goes to the 'page not found' text. Ironically, having the server component on the client works fine.

Other quirks: when you have mixed interactive components, if there is a WebSocket open to a server page/component and you navigate to a client component (that is cached on the client and has run on the client), if the WebSocket is open, the interactive WebAssembly component will run as a server component unless the prerender for the WebAssembly component has been set to false.

Regarding my first post, as it was probably not clear and you should know if you go that route, global WASM with SSR (the Blazor template/code) is that when I pointed out going from WASM to SSR and back to WASM, the call goes to the server and then runs on the client, I should have said RE-RUNS on the client, i.e., the client-side program.cs is re-run despite it already being on run and cached. I have not checked if this is just a debug runtime behavior (or bug) or happens after publishing; I suspect it is both.

This behavior may be fine for some apps/sites where there is not a lot of transition from SSR to WASM. Another thing to check, if going this route, would be client-side local browser session cache (if you use it for, say, storing validation rules); I have not checked yet, would this get wiped out or remain as you have not changed tabs?

My final thoughts and just my opinions based on my usages of Blazor to date: Blazor WASM with Server API works great (excluding initial download); the new auto per component works well if you embrace the quirks (bugs?) and you do not need the app to work (for prolonged periods) without the internet. If you embrace the new way, just remember that any component running on the client that you may want prerendering will require a couple of extra steps, i.e., a shared interface that you can register on both the client and server to provide the concrete implementations of code for when the code first runs on the server and then subsequently runs on the client (plenty of posts on that). And the code if you want to share/download the prerendered state (again lots of posts on that as well). Or turn off prerendering for the component.

Sorry for the additional post, but hope it helps.

I've run into this recently as well starting from an Interactive Auto template with per page/component interactivity. code-dispenser's suggestion will probably suffice for my own needs. I was originally taking the same approach as OP with having the router and layout on the server but ran into the issue described here:

https://github.com/dotnet/aspnetcore/issues/50518

With the router on the server, there just doesn't seem to be a way to get the @Body content down to the WASM components on the client. I tried placing a PortalLayout.razor (in the client project, interactivewebassembly rendermode) layout component with its own layout pointing to another MainLayout.razor layout component (also in the client project, no render mode specified) that simply emitted the PortalLayout component, but the @body content of the page would not show up inside PortalLayout.razor.

It'll be interesting to see if a solution for this surfaces.