Manual Blazor start updates 8.0

[guardrex]

Fixes #30812
Fixes #30580
Fixes #30862

Mackinnon ... You might want to expand the entire Startup doc on the diff to confirm that nothing else needs to change.

Also, confirm if the brace blocks ({...}) passed to ssr, circuit, and webAssembly are called "functions" in this context. If not, what should they be called? You'll see on the DIFF (Lines 51-53) where we need to change the word if I made a poor choice.

The bit that I added on an earlier PR for disableDomPreservation is versioned for 8.0+ at the end of the doc.

---

Internal previews

Toggle expand/collapse

📄 File	🔗 Preview link
aspnetcore/blazor/fundamentals/environments.md	ASP.NET Core Blazor environments
aspnetcore/blazor/fundamentals/logging.md	ASP.NET Core Blazor logging
aspnetcore/blazor/fundamentals/signalr.md	ASP.NET Core Blazor SignalR guidance
aspnetcore/blazor/fundamentals/startup.md	aspnetcore/blazor/fundamentals/startup
aspnetcore/blazor/globalization-localization.md	ASP.NET Core Blazor globalization and localization
aspnetcore/blazor/host-and-deploy/server.md	Host and deploy ASP.NET Core server-side Blazor apps
aspnetcore/blazor/host-and-deploy/webassembly.md	Host and deploy ASP.NET Core Blazor WebAssembly
aspnetcore/blazor/project-structure.md	aspnetcore/blazor/project-structure
aspnetcore/migration/70-80.md	Migrate from ASP.NET Core 7.0 to 8.0
aspnetcore/release-notes/aspnetcore-8.0.md	What's new in ASP.NET Core 8.0
aspnetcore/tutorials/signalr-typescript-webpack.md	Tutorial: Get started with ASP.NET Core SignalR using TypeScript and Webpack

[guardrex]

@Rick-Anderson @tdykstra @wadepickett ... Sébastien Sougnez's Twitter link in an article byline broke and appears in the build report. I'm fixing it on this PR, but it will go in later today because this needs a PU review from Mackinnon.

[MackinnonBuck]

I'm a bit worried that our change in structure to the Blazor.start() 'options' parameter is going to create a pit of failure for customers, especially if they're doing a Blazor WebAssembly Standalone application. If a customer gets it wrong by accident and adds the webAssembly property rather than defining these options on the top level, there's no clear indication when they run their app that they did anything wrong. It just appears to "not work" silently.

In hindsight, it would have been great if we adjusted blazor.server.js and blazor.webassembly.js to also accept the new 'options' format and normalize it to the old one. It would have made docs a little easier too, because we wouldn't have to worry about distinguishing between the two cases. Perhaps that's something we can change in .NET 9 (or a servicing release?).

[MackinnonBuck]

[me] In hindsight, it would have been great if we adjusted blazor.server.js and blazor.webassembly.js to also accept the new 'options' format and normalize it to the old one. It would have made docs a little easier too, because we wouldn't have to worry about distinguishing between the two cases. Perhaps that's something we can change in .NET 9 (or a servicing release?).

Filed dotnet/aspnetcore#51611 to track this.

[guardrex]

@MackinnonBuck @danroth27 ... I went with showing both standalone WASM and Blazor Server in a SxS format with BWA scripts for >=8.0, and I leave WASM/Server code to appear for <8.0. I didn't use pivots ... just vanilla versioning.

🛑 NOTE TO SELF ✋

If we show Blazor Server scripts >=8.0, I'll need to UN-version the _Host.cshtml/_Layout.cshtml content for >=8.0 for these Blazor.start scenarios because all of the _Host/_Layout content was 🔪 out for general BWA coverage in >=8.0 content.

UPDATE: It took a few more commits, but I think it's good for a look now. If this approach is ok for the code, I'll just need to circle back for _Host.cshtml/_Layout.cshtml updates so that Blazor Server folks can find where the script lives and where to add their Blazor.start code.

UPDATE: There's a new Blazor script location section now in the Project Structure article. I'll be linking to it from across the doc set for Blazor script location.

[guardrex]

@MackinnonBuck ... The last commit:

• Adds a section to the Project Structure article explaining the location of the Blazor script.
• Refactors the lead-in remarks of the Fundamentals > Startup article to refer to the new location section for location information.
• I'll cross-link the new location section around the docs soon where the script is mentioned on PR later. I opened Cross-link new Blazor script location section #30866 to track that work separately.

I think we can leave the remaining references (placeholder remarks) in the Fundamentals > Startup article as they are.

[MackinnonBuck]

Looks great 🙂

I left an additional comment here, but don't feel obligated to make any changes if you like things the way they are!