You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Blazor Web project interactive options improvements. Rename render modes. (#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).

AutoRenderMode=>thrownewNotImplementedException("TODO: To be able to support AutoRenderMode, we have to serialize persisted state in both WebAssembly and Server formats, or unify the two formats."),
InteractiveAutoRenderMode=>thrownewNotImplementedException("TODO: To be able to support InteractiveAutoRenderMode, we have to serialize persisted state in both WebAssembly and Server formats, or unify the two formats."),
0 commit comments