-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blazor Web App template should enable server interactivity by default #49314
Comments
Hopefully this changes in near future maybe add an option to the template so that interactivity is enabled or not? (on by default would be prefererred) |
I had a discussion with @mkArtakMSFT and @javiercn about this:
I think we want the default options for the template in VS and on the CLI to be the same. We have Blazor onboarding tutorials for both VS and CLI based users on the .NET website and we want both sets of users to have a good default experience. So, the main question here is whether we also want WebAssembly interactivity and the auto rendering mode to be enabled by default in .NET 8. Enabling the WebAssembly render mode in .NET 8 will require adding a separate project for the WebAssembly content (see #49079 for the related discussion). We still aspire to get to a single project mode Blazor and WebAssembly, but not for .NET 8 due to the complexities involved. If both interactivity modes are on by default then we can flip the current options to opt-out of individual render modes. If we don't want WebAssembly enabled by default to avoid starting new users with a multi-project solution, then we'd need to make server opt-out and WebAssembly opt-in. We haven't finished implementing the WebAssembly support and auto render mode, so perhaps should wait to see what that feels like before making this call. |
Despite being a big fan of WebAssembly and planning to make as many components as possible WebAssembly capable (being switched to by the auto mode - soon) I would recommend WebAssembly to be opt-in as long as the companion project is required. I am teaching programming classes as well and can say that for beginners a simple project (with good defaults so the CLI command is concise) with as few moving parts as possible, that can be F5'd and tried right away, is important to get them excited and on-board. |
There should be a different way of communicating than the blazor server side, not a long connection mode, just to support the need for onclick. |
I agree with having a default interactivity mode, the main selling point of blazor (for me atleast) is the ease-of-use with state and events like
I agree with the server opt-out and WebAssembly opt-in, i think its a good choice. This because WebAssembly requires you have to work with HttpClient to get all data, that in turn requires to have an api in place. Server interactivity on the other hand is so much simpler to write. You can directly use EF core (or other data access) in the components. Starting with a single project instead of 2 is also a benefit.
I agree with that. I dont expect to use it myself but the option should be there.
Im not sure if i agree with this, like i said before, WebAssembly requires to have to work with HttpClient and an API, With auto mode you are still using WebAssembly just not on the first load. meaning you still have to write your code as if it was with WebAssembly interactivity. However This is only a problem for data access you can always change the render mode for data access components, and having the auto mode as default when both are selected is a great way to show what's possible. This is something to consider, All the other proposals i agree with. And yes, a snake game in the template would be a cool addition |
which in turn would be beneficial. i.e. your page is server-side rendered but your card/table/chart/whatever component is client rendered. I can see it improving performance even if slightly |
This is done with #49801 |
The default Blazor Web App template is only setup for server-side rendering. It doesn't enable any interactivity modes. The means that commonly used Blazor features, like registering UI event handlers (
@onclick
,@bind
, etc) simply don't work and nothing will tell you why. Defaults should reflect the most common use cases. It seems reasonable to expect that most Blazor users will want some form of interactivity, so the current default creates an initial pit of failure.Proposal:
AddServerComponents()
.The text was updated successfully, but these errors were encountered: