Add collapsible category submenus to navigation sidebar

[magmoe]

Summary

• Group the flat 52-item Core nav list into 7 collapsible categories (Maps & Scenes, Layers, Visualization, Widgets,
  Queries, Interaction, Location) with animated expand/collapse chevrons
• Pro NavMenu inherits the same grouping, with all 24 Pro pages slotted into the matching categories alongside Core pages
• Active page's group auto-expands on load; search auto-expands all groups with matching results
• Restyle active item indicator: gradient left border + subtle hover-style background instead of solid gray box
• Pinned Home link at top with divider separator
• Fix UniqueValueRenderers build error (missing ToUpperFirstChar extension)

Code quality

• Category lives on the PageLink record itself (not a separate dictionary), so new pages can't be added without a
  category assignment
• Category names use compile-time constants (Categories.Layers, etc.) to prevent typos
• Pro uses p with { Href = href } to preserve base page data, avoiding per-access dictionary allocation
• Shared RenderNavLink RenderFragment eliminates duplicated NavLink markup across templates

Files Changed

• NavMenu.razor.cs — PageLink record with Category field, Categories constants, expand/collapse state, grouping
  logic
• NavMenu.razor — Grouped rendering with collapsible headers, pinned items, shared RenderFragment
• site.css — Group header, sublist, pinned item, and active item styles
• ProNavMenu.razor.cs — Pro pages with category assignments, with expression for base page remapping
• ProNavMenu.razor — Matching grouped template with shared RenderFragment
• UniqueValueRenderers.razor.cs — Build fix

[Copilot]

Pull request overview

This PR refactors the sample navigation sidebar from a long flat list into collapsible category submenus (shared between Core and Pro samples), adds pinned top-level links, updates active-item styling, and includes a small build fix in a sample page.

Changes:

• Add Category to PageLink + grouping/expand-collapse state management in NavMenu.
• Update Core/Pro nav menu Razor templates to render grouped, collapsible sections with shared link rendering.
• Update sidebar CSS for group headers, nested lists, pinned items, and the new active indicator style.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
samples/pro/dymaptic.GeoBlazor.Pro.Sample.Shared/Shared/ProNavMenu.razor.cs	Assign categories to Pro pages and reuse base PageLink via with when rewriting Href.
samples/pro/dymaptic.GeoBlazor.Pro.Sample.Shared/Shared/ProNavMenu.razor	Render pinned items + grouped collapsible sections for Pro menu.
samples/core/dymaptic.GeoBlazor.Core.Sample.Shared/wwwroot/css/site.css	Add styles for group headers/submenus/pinned item and update active item indicator styling.
samples/core/dymaptic.GeoBlazor.Core.Sample.Shared/Shared/NavMenu.razor.cs	Introduce category constants, grouping order, expanded-group state, and auto-expand active group on load/search.
samples/core/dymaptic.GeoBlazor.Core.Sample.Shared/Shared/NavMenu.razor	Render pinned items + grouped collapsible sections for Core menu.
samples/core/dymaptic.GeoBlazor.Core.Sample.Shared/Pages/UniqueValueRenderers.razor.cs	Replace missing ToUpperFirstChar usage with an inline capitalization expression.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[TimPurdum]

Code Review — PR #13: Collapsible nav categories

Overview

Refactors the flat 52-item Core nav + 24-item Pro nav into 7 collapsible category groups, with a pinned Home link and a shared RenderNavLink fragment. Clean refactor overall.

🟢 What's done well

• Category lives on the PageLink record itself — new pages can't be added without a category (enforced by GroupOrder iteration).
• Categories.Layers etc. as compile-time string constants — typo-proof.
• ProNavMenu uses p with { Href = href } instead of rebuilding the record — preserves Category and ImageFile from the base, which was a latent bug in the previous code (the old new PageLink(href, p.Title, p.IconClass, p.ImageFile) would have dropped any future field additions).
• Categories is public static nested in NavMenu, correctly accessible from ProNavMenu.

🟡 Concerns

1. Inline RenderFragment at the bottom of the .razor file.

   @{
       RenderFragment RenderNavLink(PageLink page)
       {
           ...
           return@<NavLink ...>...</NavLink>;
       }
   }

   The return@<...> is valid Razor but unusual and easy to misread. Two alternatives worth considering:

   • Extract to a real child component (NavLinkItem.razor) — gives proper parameter typing and testability.
   • Move the fragment to the .razor.cs partial as a field: private RenderFragment<PageLink> RenderNavLink => page => @<NavLink ...>...</NavLink>;

   Either makes the shared-between-Core-and-Pro story clearer (today the identical fragment is duplicated in NavMenu.razor and ProNavMenu.razor).

2. CSS :has() selector.

   .nav-list .nav-list-item:has(> .nav-list-link.active)

   Fine for modern browsers (Chrome 105+, Safari 15.4+, Firefox 121+), but the sample gallery has historically been broadly compatible. Worth confirming this is acceptable for the target audience, otherwise fall back to JS-driven active class.

3. Group auto-expand logic only runs on first render.

   if (group is not null) { ExpandedGroups.Add(group); }

   If a user navigates to another page via the sidebar after collapsing its group, the new group won't auto-expand. Consider hooking NavigationManager.LocationChanged to re-run the expansion. Low priority.

4. Pro property no longer needed on PageLink? With groups, the pro class is only used on anchors. Not changed here — fine to leave for this PR, flag for future cleanup.

5. Missing newline at EOF on NavMenu.razor.cs and ProNavMenu.razor.cs. Minor editor hygiene.

6. Pinned-vs-grouped is detected by p.Category is null. Works fine for the single Home link, but if more pinned items are ever needed (e.g., "What's New"), an explicit bool IsPinned flag would be clearer than abusing a null category. Not blocking — worth a note in a TODO.

🟢 Categorization choices look sensible

• "Compass Widget", "Locate Widget", "Basemap Toggle", "Scale Bar" from PR Add dedicated sample pages for Compass, Locate, BasemapToggle, and ScaleBar widgets #14 would slot cleanly into Widgets.
• "Legend", "GeoJSON Layers" from PR Add Legend and GeoJSON samples #12 would slot into Widgets / Layers respectively.

Merge ordering

Merges #12 and #14 will touch the same Pages list. If this PR merges last, the new entries from #12/#14 will be flat (no category) and show up in the pinned/ungrouped section — you'll need a follow-up commit to assign Category: on them. Probably best to merge #12 → #14 → #13 in that order and handle categorization for the new pages in this PR's last commit.

---

Generated by Claude Code