Remove workaround from the Blazor Web App template when WebAssembly is enabled #50646
Assignees
Labels
area-blazor
Includes: Blazor, Razor Components
bug
This issue describes a behavior which is not expected - a bug.
Milestone
Comments
dotnet-issue-labeler
bot
added
the
area-blazor
mkArtakMSFT
pushed a commit
that referenced
this issue
Sep 15, 2023
…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 |
danroth27
added
the
bug
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The following workaround in the Blazor Web App template is no longer needed and should be removed. The Counter page component can now live in the Client project and the Client project can be configured for component discovery as an additional assembly.
The text was updated successfully, but these errors were encountered: