From a25b5e6bc47a081292e380d2337b8615095a8fd7 Mon Sep 17 00:00:00 2001
From: Copilot App <223556219+Copilot@users.noreply.github.com>
Date: Mon, 5 Oct 2026 15:16:34 -0700
Subject: [PATCH 1/2] Build Reactor's DataTemplates from code instead of
 parsing markup

Reactor built two DataTemplates at runtime by handing XamlReader.Load a markup
string: the ContentControl shell every items control mounts
(ListView/GridView/FlipView), and the legacy text-node TreeView template. Both
existed only because DataTemplate could not be constructed from code.

WinUI now offers `new DataTemplate(DataTemplateElementFactory)`, which takes a
callback returning the subtree. This ports both templates onto it, so Reactor
no longer parses XAML at runtime for item templates.

Beyond removing the parse, the TreeView template loses its
`{Binding Content.Content}`. A classic Binding resolves that path by string
through CsWinRT's ICustomPropertyProvider -- reflection, which NativeAOT trims
unless the source type is annotated, and which costs a reflective lookup per
realized row even when it works. Reading the same chain in a
DataContextChanged handler is strongly typed: no annotation, no lookup, and the
event re-fires on recycling so reused rows retext correctly.

Windows App SDK versions move to the public experimental channel. The API is on
nuget.org but still carries [feature(Feature_ExperimentalApi)], so it exists
only there: it landed in Microsoft.WindowsAppSDK.WinUI 2.3.10-experimental and
is absent from 2.3.9 stable. The 2.5.4-experimental metapackage is the aggregate
that pairs with it (its nuspec names WinUI 2.3.10-experimental and pins Runtime
[2.5.4-experimental]), so the pairing rule in spec 063 section 3 is satisfied
and no package-reference workaround is needed.

Two incidental fixes this SDK requires:

  * CS8305 is demoted from error to warning. The XAML compiler's *generated*
    XamlTypeInfo.g.cs references the SDK's own experimental metadata providers
    (XamlControlsCharts/XamlControlsTabular), so every WinUI project emits it
    from code we do not own. WarningsNotAsErrors rather than NoWarn, so a
    newly-introduced experimental dependency is still reported.
  * The IElementFactory cref in IItemsRepeaterFactorySource is disambiguated.
    This SDK adds Microsoft.UI.Xaml.IElementFactory alongside the existing
    Microsoft.UI.Xaml.Controls.IElementFactory, making the bare cref ambiguous
    (CS0419) and failing the warnings-as-errors Release build. Verified still
    required: restoring the bare cref reproduces the error.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 17bce8bb-d57a-4f76-a55d-27c9029fc9a3
---
 Directory.Build.props                         | 36 ++++++++++++-
 .../Core/IItemsRepeaterFactorySource.cs       |  2 +-
 src/Reactor/Core/Reconciler.cs                | 50 ++++++++++++++-----
 3 files changed, 73 insertions(+), 15 deletions(-)

diff --git a/Directory.Build.props b/Directory.Build.props
index 3772db8ed..e5666e748 100644
--- a/Directory.Build.props
+++ b/Directory.Build.props
@@ -21,7 +21,19 @@
     shape here.
   -->
   <PropertyGroup>
-    <WindowsAppSDKVersion>2.2.0</WindowsAppSDKVersion>
+    <!--
+      EXPERIMENTAL (public preview) VERSIONS — see the pull request description.
+
+      This branch consumes the code-based DataTemplate constructor
+      (`new DataTemplate(DataTemplateElementFactory)`). The API is on nuget.org
+      but still carries `[feature(Feature_ExperimentalApi)]`, so it exists only on
+      the `-experimental` channel: it landed in Microsoft.WindowsAppSDK.WinUI
+      2.3.10-experimental and is absent from the 2.3.9 stable release.
+
+      Move both values back onto the stable channel once the API graduates; the
+      pairing rule below still applies when you do.
+    -->
+    <WindowsAppSDKVersion>2.5.4-experimental</WindowsAppSDKVersion>
     <!--
       Windows App SDK 2.0 split the monolithic Microsoft.WindowsAppSDK metapackage
       into independently-versioned sub-packages. Framework-dependent projects
@@ -33,7 +45,7 @@
       nuspec dependency on Microsoft.WindowsAppSDK.WinUI for the target version and
       pin that exact value here. (spec 063 §3)
     -->
-    <WindowsAppSDKWinUIVersion>2.2.1</WindowsAppSDKWinUIVersion>
+    <WindowsAppSDKWinUIVersion>2.3.10-experimental</WindowsAppSDKWinUIVersion>
     <Win2DVersion>1.4.0</Win2DVersion>
     <WindowsAppSDKSelfContained>false</WindowsAppSDKSelfContained>
 
@@ -71,6 +83,25 @@
     <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
   </PropertyGroup>
 
+  <!--
+    EXPERIMENTAL CHANNEL ONLY — remove together with the experimental Windows App
+    SDK versions above.
+
+    CS8305 is "this API is for evaluation purposes only" ([Experimental]). This
+    branch opts into one such API deliberately (the code-based DataTemplate
+    constructor), but that is not what trips the Release build: the XAML compiler's
+    *generated* XamlTypeInfo.g.cs references the SDK's own experimental metadata
+    providers (XamlControlsCharts/XamlControlsTabular), so every WinUI project in
+    the repo emits CS8305 from code we do not own and cannot annotate.
+
+    Demoted rather than silenced — WarningsNotAsErrors keeps the diagnostic
+    visible in build output, so a newly-introduced experimental dependency is
+    still reported; it just stops generated SDK code from breaking the build.
+  -->
+  <PropertyGroup>
+    <WarningsNotAsErrors>$(WarningsNotAsErrors);CS8305</WarningsNotAsErrors>
+  </PropertyGroup>
+
   <!--
     Repository / project URL metadata for every packable project. NuGet.org's
     Microsoft compliance policy (https://aka.ms/Microsoft-NuGet-Compliance)
@@ -156,3 +187,4 @@
           Condition="Exists('$(MSBuildThisFileDirectory)src\Reactor\build\Reactor.targets')" />
 
 </Project>
+
diff --git a/src/Reactor/Core/IItemsRepeaterFactorySource.cs b/src/Reactor/Core/IItemsRepeaterFactorySource.cs
index 8eb42fec4..ed1d79a02 100644
--- a/src/Reactor/Core/IItemsRepeaterFactorySource.cs
+++ b/src/Reactor/Core/IItemsRepeaterFactorySource.cs
@@ -36,7 +36,7 @@ internal interface IItemsRepeaterFactorySource
     void ConfigureLayout(WinUI.ItemsRepeater repeater);
 
     /// <summary>
-    /// Produce a fresh <see cref="IElementFactory"/> closure that knows
+    /// Produce a fresh <see cref="WinUI.IElementFactory"/> closure that knows
     /// how to realize element index N into a UIElement subtree. Called on
     /// first mount AND whenever the existing factory's type no longer
     /// matches (e.g. element re-keyed to a different TItem).
diff --git a/src/Reactor/Core/Reconciler.cs b/src/Reactor/Core/Reconciler.cs
index d7ca34d13..76427e8b1 100644
--- a/src/Reactor/Core/Reconciler.cs
+++ b/src/Reactor/Core/Reconciler.cs
@@ -409,27 +409,53 @@ internal bool TryResolveFromControlRegistry(Type elementType, out IV1HandlerEntr
     /// </summary>
     /// <summary>
     /// A shared DataTemplate containing a ContentControl shell.
-    /// Parsed once via XamlReader.Load, reused across all items controls (ListView, GridView, FlipView).
+    /// Built once from code via <c>new DataTemplate(factory)</c> and reused across
+    /// all items controls (ListView, GridView, FlipView). The factory overload
+    /// replaces a <c>XamlReader.Load</c> of an equivalent markup string — see the
+    /// PR description for why parsing markup at runtime was a problem here.
     /// </summary>
     internal static readonly Lazy<DataTemplate> SharedContentControlTemplate = new(() =>
-        (DataTemplate)Microsoft.UI.Xaml.Markup.XamlReader.Load(
-            "<DataTemplate xmlns='http://schemas.microsoft.com/winfx/2006/xaml/presentation'>" +
-            "<ContentControl HorizontalContentAlignment='Stretch' VerticalContentAlignment='Stretch'/>" +
-            "</DataTemplate>"));
+        new DataTemplate(() => new Microsoft.UI.Xaml.Controls.ContentControl
+        {
+            HorizontalContentAlignment = Microsoft.UI.Xaml.HorizontalAlignment.Stretch,
+            VerticalContentAlignment = Microsoft.UI.Xaml.VerticalAlignment.Stretch,
+        }));
 
     /// <summary>
     /// Spec 047 §14 Phase 3 finish — text-bound TreeView item template
     /// shared between the legacy <c>MountTreeView</c> arm and the
     /// <see cref="V1Protocol.TreeChildren{TElement,TControl}"/> strategy.
-    /// In node mode the template's DataContext is <c>TreeViewNode</c>, so
-    /// <c>{Binding Content.Content}</c> resolves <c>TreeViewNode.Content</c>
-    /// (a <c>TreeViewNodeData</c>) → its <c>Content</c> (the display string).
+    /// In node mode the template's DataContext is <c>TreeViewNode</c>, so the
+    /// handler reads <c>TreeViewNode.Content</c> (a <c>TreeViewNodeData</c>) →
+    /// its <c>Content</c> (the display string).
     /// </summary>
     internal static readonly Lazy<DataTemplate> TreeViewTextItemTemplate = new(() =>
-        (DataTemplate)Microsoft.UI.Xaml.Markup.XamlReader.Load(
-            "<DataTemplate xmlns='http://schemas.microsoft.com/winfx/2006/xaml/presentation'>" +
-            "<TextBlock Text='{Binding Content.Content}'/>" +
-            "</DataTemplate>"));
+        new DataTemplate(() =>
+        {
+            var tb = new Microsoft.UI.Xaml.Controls.TextBlock();
+
+            // Strongly-typed replacement for {Binding Content.Content}. A classic
+            // Binding resolves that path by string through CsWinRT's
+            // ICustomPropertyProvider, i.e. by reflection — which NativeAOT trims
+            // unless the source type is annotated, and which costs a reflective
+            // lookup per realized row even when it works. Reading the same chain in
+            // a DataContextChanged handler is reflection-free, so it needs no
+            // annotation and does no lookup. The event re-fires when a virtualized
+            // row is recycled onto new data, so reused rows retext correctly.
+            tb.DataContextChanged += static (sender, args) =>
+            {
+                if (sender is not Microsoft.UI.Xaml.Controls.TextBlock text) return;
+                text.Text = args.NewValue switch
+                {
+                    Microsoft.UI.Xaml.Controls.TreeViewNode { Content: TreeViewNodeData d } => d.Content,
+                    Microsoft.UI.Xaml.Controls.TreeViewNode { Content: string s } => s,
+                    TreeViewNodeData d => d.Content,
+                    _ => string.Empty,
+                };
+            };
+
+            return tb;
+        }));
 
     // ════════════════════════════════════════════════════════════════════
     //  ReactorAttached.StateProperty  (ReactorState)

From e2c19e1caa9b0e7c57fd58589721a95734965ea1 Mon Sep 17 00:00:00 2001
From: Copilot App <223556219+Copilot@users.noreply.github.com>
Date: Mon, 5 Oct 2026 15:16:53 -0700
Subject: [PATCH 2/2] Drop the TreeViewNodeData binding-metadata attribute, now
 unused

#1108 annotated TreeViewNodeData with [WinRT.GeneratedBindableCustomProperty]
for exactly one reason: Reactor's own text-node TreeView template bound
"Content.Content", and that string path is resolved by reflection, which
NativeAOT trims. The preceding commit replaces that binding with a
DataContextChanged handler, so the reason is gone -- there is now no {Binding}
anywhere in src/ and no SetBinding call site.

The attribute never shipped: every tag to date predates #1108, so no released
build has it, and binding to TreeViewNodeData from a consumer-supplied template
was already broken under NativeAOT in all of them. Removing it therefore takes
away nothing that ever worked in a release; it declines to keep a side effect of
an internal fix. Keeping it would carry a workaround, plus `partial` on a public
record, for a scenario Reactor does not use and does not document.

The limitation is written down instead: docs/aot-support.md gains a row
explaining that a classic {Binding} in a hand-supplied DataTemplate is not
trim-safe, that Reactor's own templates avoid it by populating content in a
DataContextChanged handler, and that a consumer installing their own template
through an escape hatch should do the same or annotate their own type.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 17bce8bb-d57a-4f76-a55d-27c9029fc9a3
---
 docs/aot-support.md         |  1 +
 src/Reactor/Core/Element.cs | 13 +------------
 2 files changed, 2 insertions(+), 12 deletions(-)

diff --git a/docs/aot-support.md b/docs/aot-support.md
index b2d6e8870..0601bd5d1 100644
--- a/docs/aot-support.md
+++ b/docs/aot-support.md
@@ -31,6 +31,7 @@ These subsystems compile cleanly with `IsAotCompatible=true` (the warnings are s
 | **DataGrid `AutoColumns<T>`** | Reflects over `T`'s public properties via `TypeRegistry`. The `T` parameter is annotated `[DynamicallyAccessedMembers(PublicProperties)]` so the trimmer keeps the members, but `AutoColumns` ultimately funnels into `TypeRegistry.Resolve`, which is `RequiresUnreferencedCode`. Use explicit `Column<T,V>(…)` definitions instead. | Issue #70 |
 | **`UseObservable` on POCOs** | `ObservableTreeTracker` walks public properties via reflection to subscribe to INPC. Observables built explicitly (`Observable<T>`, `IObservableCollection`) are fine; the implicit-INPC path is not. | Issue #70 |
 | **Form validation** | `FormField`'s default editor resolution goes through `TypeRegistry`. Same caveat as PropertyGrid. | Issue #70 |
+| **Classic `{Binding}` in a hand-supplied `DataTemplate`** | A `{Binding Some.Path}` resolves the path *by string* through CsWinRT's `ICustomPropertyProvider`, i.e. reflection, so the trimmer drops it and the target renders blank — with no build-time warning, because the reflection happens across the WinRT ABI where the IL analyzers cannot see it. Reactor itself contains no bindings: item templates are built from code and populated in a `DataContextChanged` handler, which is strongly typed and needs no metadata. If you install your own template through an escape hatch such as `TreeView(...).Set(tv => tv.ItemTemplate = ...)`, do the same — or annotate your data type with `[WinRT.GeneratedBindableCustomProperty]`. Note `{x:Bind}` is not an option from code: it is a XAML-compiler feature. | Issue #70 |
 | **Component discovery (`ReactorApp.Run<TApp>` reflection paths)** | The instantiation of `TApp` itself is annotated and works. Devtools component enumeration is available only when the app opts into `Reactor.DevtoolsSupport` at build time and launches with `--devtools`; leave the switch off for retail/AOT builds. | Issue #70 |
 | **Devtools `properties` / `setProperty` DP discovery** | The tools locate `DependencyProperty` statics by reflection, and the trimmer keeps no reflection metadata for them unless something roots the members — so under AOT the lookups find nothing. Not specific to WinUI's CsWinRT-projected static properties: a C#-authored DP *field* on a custom control is equally undiscoverable. Works under JIT, which is where the devtools inner loop lives. The tool reports the likely cause rather than an empty result. See [Devtools DependencyProperty discovery](#devtools-dependencyproperty-discovery) for the measured cost of fixing it. Affected fixture: `Devtools_PropertyToolsDpDiscovery`. | Issue #1109 |
 | **Theme resource lookup (`Theme.X`, `ThemeRef.Resolve`)** | Works once the WindowsAppSDK#6394 workaround target ships the project `.pri` into the publish output (see [Required publish-time workarounds](#required-publish-time-workarounds)). Reactor's library itself is AOT-clean here. | WindowsAppSDK#6394 |
diff --git a/src/Reactor/Core/Element.cs b/src/Reactor/Core/Element.cs
index e3d706593..aaf74663a 100644
--- a/src/Reactor/Core/Element.cs
+++ b/src/Reactor/Core/Element.cs
@@ -2781,18 +2781,7 @@ public record PivotItemData(string Header, Element Content);
 
 public record BreadcrumbBarItemData(string Label, object? Tag = null);
 
-// The legacy node-mode TreeView renders node text through a classic {Binding}
-// (Reconciler.TreeViewTextItemTemplate resolves "Content.Content"). That path
-// goes through CsWinRT's ICustomPropertyProvider, which is reflection-based and
-// gets trimmed under NativeAOT — the TextBlock then silently renders empty, with
-// no build-time warning. This attribute makes the CsWinRT source generator emit
-// strongly-typed binding metadata for this type so the hop survives trimming.
-//
-// Scoped to just "Content": that is the only member the template binds, and the
-// parameterless overload would also emit an accessor for the [Obsolete]
-// ContentElement, which fails the warnings-as-errors Release build (CS0618).
-[WinRT.GeneratedBindableCustomProperty(["Content"], [])]
-public partial record TreeViewNodeData(string Content, TreeViewNodeData[]? Children = null)
+public record TreeViewNodeData(string Content, TreeViewNodeData[]? Children = null)
 {
     public bool IsExpanded { get; init; }