MAUI Blazor sidebar and fluent ui base design

[btiteux]

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• New feature or enhancement
• UI change (please include screenshot!)
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Internationalization and localization
• Other (please describe):

What is the current behavior?

Devtoy 2.0 doesn't have blazor component and fluent design

Issue Number: N/A

What is the new behavior?

Added a blazor Navbar component for .net MAUI.

Other information

Remaining TODO:

• Use Event from ViewModel.
• Some CSS adjustment
• Search form

Quality check

Before creating this PR:

• Did you follow the code style guideline as described in CONTRIBUTING.md
• Did you build the app and test your changes?
• Did you check for accessibility? On Windows, you can use Accessibility Insights for this.
• Did you verify that the change work in Release build configuration
• Did you verify that all unit tests pass
• If necessary and if possible, did you verify your changes on:
  • Windows
  • macOS (DevToys 2.0)
  • Linux (DevToys 2.0)

[veler]

The WASDK app also use this TTF. Could we move the TTF, WOFF, WOFF2 to a shared folder to avoid having copies in the repository? This would also ensure we use the same font everywhere.

[veler]

You set _hrefAbsolute to null but _hrefAbsolute isn't marked as nullable. Should this be string.Empty instead?

[veler]

I'm playing a bit with the code to try to make the components for the tools. I notice that for now we only have Index and it uses the URI to determine the tool name to display.

Thinking about it, I thought OK but we don't have only tools, sometimes we also display a group of tools (like when we select "All Tools") in this area, which isn't a tool itself. I dislike the idea of having the UI for tools and UI for groups in the same page (Index.razor), so I naively I started making a page ToolPage.razor and ToolGroupPage.razor, exactly like in the WASDK app. One page would have the URI tool/{Name} and the other group/{Name} but then I quickly realized that you did it this way because when clicking on a menu item, the whole page would refresh when navigating to a different URL, which is a problem indeed....
In addition of this, I feel like passing the {Name} to the page and using only this to determine what the hell we need to display in the page is a little bit of a pain to maintain (first sign that it's a future pain to maintain is that you have to URL encode/decode it...). We better pass the whole GuiToolViewItem or GroupViewItem instead of just its internal name if possible.

So how about the following:

Instead of navigating to a page, we listen to a MainWindowViewModel.SelectedMenuItem (which I know you will do in a future PR) and when it change, depending on whether it's a GuiToolViewItem or GroupViewItem, we show here a ToolPage component or a ToolGroupPage component instead of @Body (or leave Index totally empty). This way we never navigate anywhere and just replace the body on the fly. In addition, this way we can pass the whole GuiToolViewItem to the ToolPage as a component parameter instead of relying on the internal name to find which tool / group we're trying to display.

Would this work? Would this have any performance impact compared to navigating (which, if I understood well, isn't really navigating at the moment since we don't refresh the whole page, right?) ?
What do you think? :)

[veler]

PS: This could be done in a different PR by the way. Happy to do it myself too if you want, since I kind of need a minimal navigation working in order to show the tool's UI.