[Bug] TreeView does not render per-node `ContentElement` (ListView/GridView do) -

[ReneeGA2020]

What happened?

A TreeView whose TreeViewNodeData nodes carry a ContentElement shows
blank rows — the per-node content (Button / TextBlock / CheckBox / …)
is never displayed. A ListView given the same element content renders it
correctly, so the defect is specific to TreeView.

Minimal self-verifying repro: https://github.com/ReneeGA2020/ReactorTreeViewContentBug

Steps to reproduce

// TreeView — per-node ContentElement (renders BLANK)
TreeView(new[]
{
    new TreeViewNodeData("n1") { ContentElement = Button("TreeView: I am a Button"), IsExpanded = true },
    new TreeViewNodeData("n2") { ContentElement = TextBlock("TreeView: I am a TextBlock") },
    new TreeViewNodeData("n3") { ContentElement = CheckBox(true, label: "TreeView: I am a CheckBox") },
})

// ListView — same element content (renders correctly)
ListView(
    Button("ListView: I am a Button"),
    TextBlock("ListView: I am a TextBlock"),
    CheckBox(true, label: "ListView: I am a CheckBox"))

dotnet build -c Debug -p:Platform=x64
.\bin\x64\Debug\net10.0-windows10.0.22621.0\win-x64\ReactorTreeViewContentBug.exe -- --check

Expected vs. actual

Control	Same content	Expected	Actual
TreeView	Button / TextBlock / CheckBox	visible	all rows blank
ListView	Button / TextBlock / CheckBox	visible	visible ✅

The bundled --check walks the live visual tree and detects each item by its
unique label text (robust because the TreeView's internal TreeViewList derives
from ListView):

[check] ListView element-item content rendered:  True  (expected True)
[check] TreeView ContentElement content rendered: False  (expected True)
[check] BUG: TreeView ContentElement not rendered — a ListView with the same element content does render.

Reactor version / commit

c14d172

Platform

x64

.NET SDK version

10/11

Windows version

Windows 11 10.0.26100.1

Windows App SDK version

2.0.1

Logs / stack trace

[check] ListView element-item content rendered:  True  (expected True)
[check] TreeView ContentElement content rendered: False  (expected True)
[check] BUG: TreeView ContentElement not rendered — a ListView with the same element content does render.

Confirmation

• I have searched existing issues and this isn't a duplicate.
• This bug reproduces against the current main branch (or I've noted otherwise above).

[codemonkeychris]

This is a great issue... on the surface it looked pretty trivial, but it highlighted an area that we got wrong in the Reactor mapping - and highlighted a bad recollection on my part of the delta between WPF and WinUI3 :D

Fix should be here in a couple hours, I want to do the right thing here, and we will align with the WinUI model, which may make some of this a bit more cumbersome

[ReneeGA2020]

Looks like this is still a work in progress, so I wanted to add one related data point.

I previously ran into a long-standing issue with heterogeneous templates in WinUI XAML:
https://github.com/ReneeGA2020/WinUIItemTemplateSelectorBug

My understanding of that issue is that, under fast scrolling / control recycling, WinUI XAML could reuse a realized container without reliably matching the selected template back to the current item type. With typed templates using x:DataType and x:Bind, that could lead to generated binding code casting the current data item to the wrong type and crashing. With classic {Binding}, it would usually fail less visibly, but the wrong template could still be used and the content would render incorrectly or blank.

I am not suggesting that the same bug applies to Reactor. Reactor's rendering and hosting model is different from XAML, and this PR already seems to handle realized containers explicitly. I only wanted to mention it because the failure mode is in the same general area: heterogeneous item visuals plus container recycling.

From an API-design point of view, I personally do prefer the WinUI-style data-to-view/template-selector model over storing pre-built UI elements on the nodes. It feels more modern and type-friendly. It's just seems that the winui xaml version template selecting never worked properly, while the wpf ones were at least production proven. Perhaps that the Reactor implementation can add some coverage for heterogeneous node types under recycling/virtualization scenarios, so it does not inherit the class of issues that WinUI XAML had.

[ReneeGA2020]

I pulled the fix branch (fix/447-treeview-typed-tree) locally and ran it through a
scenario equivalent to the XAML recycling bug I linked earlier, to check whether
that failure mode carries over to Reactor. Setup:

• A TreeView<T> and a ListView<T> side by side, both fed the same ~1000
  heterogeneous nodes (two record shapes alternating, each with a couple of
  nested children).
• The viewBuilder is a switch on the runtime node type — the direct
  analogue of the XAML ItemTemplateSelector + x:DataType/x:Bind templates
  that triggered the original crash.
• Stressed it the same way as the XAML repro: fast scrolling to force heavy
  container recycling, plus repeated expand/collapse on the top rows.

Result: no crash, and no blank or mismatched rows (e.g. an "A" visual rendering
where a "B" should be). The ListView<T> baseline behaved identically, so I couldn't reproduce the XAML failure mode.