Root-level interactivity option for the new Blazor Web project template #50433
Comments
mkArtakMSFT
added
enhancement
…des. (#50684) Fixes #50433 (Add root level interactivity option) Fixes #50646 (Remove workaround for Counter component) Fixes #50636 (Clarify the names of the interactive render modes) In terms of the code we now emit, there should be nothing controversial here. The template just has to do quite a bit of if/else in many places to account for all these options and how rendermodes are used and not used based on them. The PR is big because the renames have really wide impact, but almost all the "files changes" are just due to renames. The only real code changes are in the project templates. # Testing impact Adding this option, the BlazorWeb template now has **so many** possible combinations of options, including: - Whether or not to enable Server interactivity - Whether or not to enable WebAssembly interactivity - Whether or not to be interactive from the root - Whether or not to include sample content - Whether or not to use ProgramMain So that's around 32 combinations of output - without even accounting for auth options! We don't currently have E2E verification of any of them, as those tests are skipped due to unreliability. We're going to have to lean hard on CTI validations for this, and make sure all the important combinations are covered - cc @mkArtakMSFT. # Options design update Having a list of 6 separate checkboxes in VS is pretty unpleasant and hard to understand: <img src="https://github.com/dotnet/aspnetcore/assets/1101362/93713e83-0793-4140-82e1-95ca63580e3d" width="500" /> So, in this PR I'm proposing (and have implemented, but we can still change it), a change to use dropdowns for the interactivity type and location options. This reduces the number of inputs by one, and means they can be more self-describing: <img src="https://github.com/dotnet/aspnetcore/assets/1101362/649c93fd-d464-499c-b1f2-36436ebf4e3c" width="500" /> * The "interactivity type" choices are: * **None** * **Server** (default) * **WebAssembly** * **Auto (Server and WebAssembly)**. * The "interactivity location" choices are: * **Per page/component** (default) * **Global** Note that "interactivity location" is disabled if interactivity type == "None", but [only CLI honors that right now](dotnet/templating#5648) (VS should add support later, and until then, location will have no effect if there's no interactivity). I think this is much easier to understand, since you no longer have to infer that enabling both Server and WebAssembly means you're going to get Auto. It's also much better in the CLI, since it was completely ridiculous before that `--use-server` defaulted to true but `--use-wasm` defaulted to false, so to get WebAssembly you needed to set `--use-server false --use wasm`. Now you would say `--interactivity webassembly` (and not `wasm` - that was weird too). 
|
Done in #50684 |
|
The new/updated template parameters for CLI are: The |
|
I really wish you hadn't closed #49798 in favor of this. I have several teams and we are heavily invested in Blazor WASM applications. Those require a WebApi backend, and the hosted template made this incredibly easy. This is a bit convoluted and ignores the very valid reasons expressed in #49798 to continue having the hosted template. Also, there are some of us that like to create projects using VS and not with the CLI. |
|
Can you clarify more what you think is insufficient or convoluted with these template changes for your scenarios? The new template still lets you create a multiproject solution that includes a WebAssembly project that is hosted by an ASP.NET Core server. You can still add WebApi endpoints on the host server and make requests to them from WebAssembly.
The options added here are also exposed via the VS project creation wizard UI.
If you pick "interactivity mode: WebAssembly" and "interactivity location: Global", that leads to a project that's very similar to the earlier WebAssembly Hosted project. |
ghost
locked as resolved and limited conversation to collaborators
We should make sure that the new Blazor Web project template enables a scenario similar to what Blazor Server template would offer out of the box. To achieve this, we should add a new option for the Blazor Web App template that will make the root level component interactive out of the box.
The list below represents all the options we will have for the Blazor Web App project template:
With all these options, enabling interactivity like the Blazor Server template would support would mean enabling the following set of options:
As for getting to what Blazor Web Assembly Hosted template option would produce, you would have to use the following set of options:
The text was updated successfully, but these errors were encountered: