microsoft / microsoft/winappCli

find-ui: add common control-combination patterns to core patterns

Open
#679 0 comments 0 reactions 1 assignee Claimed by @Jaylyn-Barbee View on GitHub
enhancement
Dominant language
C#
Stars
1.3k
Forks
80
Avg merge
3d 6h
Merged PRs (30d)
51

Description

## Summary

Add a small, high-value set of **UI-composition patterns** ("common control combinations") to find-ui's curated core patterns (`src/winapp-CLI/WinApp.Cli/Services/Controls/Data/core-patterns.json`, surfaced via `winapp find-ui --source core`).

Today all 6 core patterns cover **platform integration** (JumpList, Share, system tray, file picker, charts, drag-drop). There are **zero UI-composition combos** — no "control nested in control" layout patterns.

## Motivation

In an agent benchmark run building a WinUI 3 settings dashboard, the agent used `winapp find-ui` exactly as intended — it front-loaded 8 focused searches and batched `--id` fetches across Gallery, Toolkit, and Reactor, and the app **built successfully**. But it then **crashed on launch** (build ✅, run ❌, score 0) with:

```
XamlParseException: Failed to create a 'Microsoft.UI.Xaml.Controls.IconElement' from the text 'Brush'
→ Crash: Exception (0xC000027B) (unhandled-exception fail-fast, "no window")
```

The failure was at an **assembly seam** — wiring a `NavigationViewItem.Icon` — not inside any single control. find-ui returns correct *per-control* snippets, but it doesn't show how controls **nest and wire together**, which is exactly where agents introduce runtime XAML errors that compile fine but crash on load.

Composite core patterns directly target this class of error by showing the correct assembled markup (nesting + icon/resource wiring) for the most common WinUI layouts.

## Proposed patterns (3)

Modeled on the existing `CorePattern` schema (`id`, `scenario`, `tags`, `description`, `prerequisites`, `xaml`, `csharp`, `notes`).

### 1. `navigationview-app-shell` — NavigationView shell with icon'd items + Frame paging
The canonical app skeleton. Shows the correct `NavigationViewItem.Icon` wiring
(`` or `FontIcon`),
`SelectionChanged` → `ContentFrame.Navigate(typeof(Page))`, and Settings-item handling.
**Directly prevents the IconElement/'Brush' crash above.**

### 2. `settings-page-cards` — Settings page with CommunityToolkit SettingsExpander / SettingsCard
The idiomatic settings layout: a `SettingsExpander` containing `SettingsCard`s, each with
`Header`, `Description`, a `HeaderIcon` (`FontIcon`), and a control (`ToggleSwitch`/`ComboBox`)
in the card content/footer. Includes the Toolkit prerequisites (NuGet package + `xmlns`).

### 3. `listview-master-detail` — ListView + DataTemplate master–detail
A 2-column `Grid`: a `ListView` with an `ItemTemplate` `DataTemplate` (using `x:Bind` + `x:DataType`)
on the left, a detail pane bound to `SelectedItem` on the right. Covers the tabular/list + detail
pattern and the `DataTemplate` `x:Bind`/`x:DataType` gotcha.

(Runner-up worth considering: `itemsrepeater-of-expanders` — an `ItemsControl`/`ItemsRepeater` of
`Expander`s, another common "list of expandable sections" seam.)

## Cheap complement: a seam-level pitfall Note

Independent of the combos, add a pitfall to `Notes.cs` (already surfaced as **Important:** in find-ui output; there's already a TreeViewItem icon note, but none for this case):

> `Icon` properties take an `IconElement` (`SymbolIcon` / `FontIcon` / `BitmapIcon`) — never a string or Brush. Use ``.

## Validation

This is data-only (no code changes). The hypothesis — "composite patterns + seam pitfall notes reduce runtime-crash-on-launch" — is directly measurable via the agent benchmark's binary `runs` metric: add the patterns/notes, re-run, and see whether the runtime-crash rate drops.

## Files

- `src/winapp-CLI/WinApp.Cli/Services/Controls/Data/core-patterns.json`
- `src/winapp-CLI/WinApp.Cli/Services/Controls/Notes.cs`

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.