Add styling and Shell to Blazor Hybrid template

[jfversluis]

Description of Change

This PR adds the styling of the "regular" .NET MAUI app to the Blazor Hybrid template.

This styling does not apply anything implicit like the old styling to a page background where it became all purple so it shouldn't look weird or show up at all if you're building a Blazor Hybrid app.

However, if you do want to venture into .NET MAUI, you will now get a nice look out of the box consistent with the regular .NET MAUI template. This should make it easier to make a start with styling your app without having to learn the whole thing from scratch.

Additionally, this will introduce Shell to the Blazor Hybrid template. This should have no implications if you're just using Blazor Hybrid. However, again, if you want to venture into .NET MAUI, this gives you easy navigation and other things. Also consistent with the regular .NET MAUI template. For the MainPage.xaml I set the Shell.NavBarIsVisible to false so that it doesn't show up weird.

With these new changes applied, the Blazor Hybrid part still looks the same

And here is the "native" MAUI app page added to this Blazor Hybrid app which also applies the styling as it should

[Eilon]

I like the idea, but I think we should run this by @BethMassi to see if it's worth adding more stuff to the templates. If really most apps stick to Blazor and almost never need anything more, then I would leave the template as-is. But if it's reasonably common to add more things to a Blazor Hybrid app using MAUI controls, then I'd say we go for it.

[jfversluis]

@jamesmontemagno I think you have some data on Blazor Hybrid usage too? Any opinions here?

[jfversluis]

Converting to draft while we gather some data

[jamesmontemagno]

Yes! This makes 100% sense to me. Especially with MainPage going away and our drive towards multi-window type applications.

With Shell being there will give more opportunity to use some native stuff, but still can use 100% hybrid and it is basically the same as before.

Approved

[javiercn]

@Eilon I defer to you on a call here 😄

[Eilon]

Yes! This makes 100% sense to me. Especially with MainPage going away and our drive towards multi-window type applications.

With Shell being there will give more opportunity to use some native stuff, but still can use 100% hybrid and it is basically the same as before.

Approved

My question is what are people actually doing. I like being consistent, but we have competing consistencies 😁

[jamesmontemagno]

Yes! This makes 100% sense to me. Especially with MainPage going away and our drive towards multi-window type applications.
With Shell being there will give more opportunity to use some native stuff, but still can use 100% hybrid and it is basically the same as before.
Approved

My question is what are people actually doing. I like being consistent, but we have competing consistencies 😁

It is a good question and from folks that I talk to, it is 60/40 i would say. 60 being ones that just use 100% blazor and nothing else, and the 40 blending in a few native elements such as tabs and items like that.

I think consistency and messaging around building a .NET MAUI application with Shell as the root is something that helps education across the wire. It means the same navigation, DI, etc all work when reading the documentation.

[Felix-Dev]

My question is what are people actually doing. I like being consistent, but we have competing consistencies 😁

@Eilon We are working on a Blazor Hybrid app where we use the MAUI Shell to power native app navigations. Most of those pages currently host a BlazorWebView as their top element - we do have a few "MAUI XAML-only" pages already, however. We consider our web-based pages as a workaround for current MAUI XAML limitations and will strive to implement more and more pages natively (using MAUI XAML) in the longer run. So for our use case, it makes sense to add both styling and the Shell to the template.

Why do we go with the MAUI Shell paired with web-based page content? A couple of reasons:

1. Flexibility: For each page we can decide anew if native controls or web-based controls better fit the requirements of our customers.
2. Native app navigation: Our users can use swipe gestures on both Android and iOS for page-back navigation, for example.
3. Native titlebar: This way, we can incorprate native context menus like a UIContextMenuInteraction to get native platform features for free without having to re-invent the wheel with web-based menu/popup controls.

[BethMassi]

@jfversluis thanks for this PR. I'm inclined to agree with @Eilon here. I'd prefer not introducing a new concept to the template when we don't have customer requests for it and according to telemetry less than a third of Blazor hybrid apps mix xaml and razor (beyond the three files required by the project). Also, we'd want to keep this project template consistent with the new Blazor hybrid + web solution template and I think it's too late in the cycle to do all that work + testing. Let's wait until the next update to consider this one again.

[jfversluis]

Thanks Beth! Lets revisit later!