microsoft-ui-reactor

---

What Reactor is — and isn't

Reactor is not a new UI platform. It is a new way to describe WinUI content. Every control you render is a real WinUI control — Button, TextBox, NavigationView, TreeView — just authored differently. Apps built with Reactor interop freely with XAML, MVVM, existing controls, and the rest of the WinUI ecosystem.

What Reactor adds on top of WinUI:

• A virtual element tree and reconciler that diff old vs. new descriptions and patch only what changed on real WinUI controls
• Hooks-based state (UseState, UseEffect, UseReducer, …) co-located with render logic
• A C# DSL that replaces XAML markup with typed factory methods and fluent modifiers
• Higher-level building blocks — flex layout, charting, commanding, navigation, data grid, theming, localization — many of which are candidates to migrate back into WinUI itself

using Microsoft.UI.Reactor;
using Microsoft.UI.Reactor.Core;
using static Microsoft.UI.Reactor.Factories;

ReactorApp.Run<MyApp>("Hello Reactor");

class MyApp : Component
{
    public override Element Render()
    {
        var (count, setCount) = UseState(0);

        return VStack(
            Heading($"Count: {count}"),
            HStack(8,
                Button("-", () => setCount(count - 1)),
                Button("+", () => setCount(count + 1))
            )
        );
    }
}

No App.xaml. No MainWindow.xaml. No code-behind. No ViewModels. Just C# with full IntelliSense, refactoring, and compile-time type safety.

---

XAML and MVVM are not going anywhere

WinUI is a powerful native platform, and the XAML + MVVM programming model is a great fit for a large portion of the WinUI user base. Tooling, designer support, templating, data binding, and years of guidance, samples, and third-party controls are built around it. Reactor does not try to replace any of that.

What Reactor does target is a specific gap: developers coming from React, SwiftUI, or Jetpack Compose expect co-located state, declarative composition, and type-safe UI construction. Reactor brings those patterns to WinUI without asking anyone to abandon the platform they already ship on. The two models coexist:

• If you're shipping XAML/MVVM today, keep shipping XAML/MVVM. The investments we're making in Reactor — improved accessibility APIs, richer theming, better commanding, a stronger data stack — are designed to flow back into WinUI so you benefit too.
• If you want a functional MVU model with no XAML and no ViewModels, Reactor is a path to get there on the same runtime, with the same controls, in the same process.
• If you want both, you can host Reactor content inside a XAML app, or drop XAML content inside a Reactor app. They share the visual tree.

Many of the experiments in this repo — the charting stack, accessibility validators, commanding, flex layout, theming tokens — are likely to land in WinUI directly, where they'll work for XAML and MVVM users too. Others may continue to ship through Reactor. Either way, WinUI is the foundation.

---

Quick start

Reactor ships the public preview package Microsoft.UI.Reactor on NuGet.org; see the NuGet page or GitHub Releases for the current version. The project templates ship in the official Windows App SDK dotnet new pack, so building an app needs no source checkout:

# `winapp` is the Windows App SDK CLI; `winapp new` installs the template pack
# on demand, so there's no separate install step and no version to pin.
winget install Microsoft.WinAppCli
winapp new -t reactor -n MyApp
cd MyApp
dotnet run

Scaffolded apps are packaged (single-project MSIX) by default, so dotnet run launches them with full package identity — the F5 equivalent. That requires Developer Mode (Settings → System → For developers); dotnet new reactor -n MyApp --packaging Unpackaged scaffolds a plain unpackaged .exe instead. reactor-mvu, reactor-navview, and reactor-tabview start from richer shells, and reactor-singlefile is a single .cs file with no project (winapp new --list prints them all).

Prefer plain .NET tooling? dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates::<version> followed by dotnet new reactor -n MyApp does the same thing. The pack is prerelease-only today and dotnet new install resolves stable versions unless you pin one explicitly, which is the step winapp new removes.

Contributing to Reactor itself

git clone https://github.com/microsoft/microsoft-ui-reactor.git
cd microsoft-ui-reactor

# calling the bootstrap system under the correct PowerShell version you're on
& (Get-Process -Id $PID).Path -ExecutionPolicy Bypass -File .\bootstrap.ps1

dotnet new reactor -n MyApp
cd MyApp
dotnet run -p:Platform=x64

⚠️ Clone to a short path: Clone into a short root directory such as C:\src\ (e.g. C:\src\microsoft-ui-reactor), not a deeply nested or OneDrive-synced folder. The Windows App SDK's XAML and resource compilers are 32-bit tools with no long-path support, so a long checkout path can push a project's generated obj/bin output past the Windows 260-character MAX_PATH limit and break the build (MSB3073 / PRI210) — most often on ARM64 dev boxes, where those tools run under emulation. See #678.

⚠️ Platform flag required: Always build with an explicit platform: dotnet build -p:Platform=x64 (or ARM64). Omitting -p:Platform=... causes WindowsAppSDKSelfContained errors. This applies to dotnet build, dotnet run, and mur check invocations alike.

This is the beginning of the README. Read the rest at the original. Read the full README ↗