Xaml support prototype #14811

JesseCol · 2025-06-19T20:05:15Z

Here's the idea:

The react-native-windows package now contains a Microsoft.ReactNative.Xaml.dll to help with Xaml hosting.
RNW exposes a type named XamlApplication in IDL to help coordinate Xaml work and metadata.
RNW exposes a native component named XamlHost that knows how to host Xaml (using a XamlIsland). Native components that want to be Xaml-based can implement IXamlControl to allow their object to be parented to a XamlHost.
There's a new package for testing, called xaml-calendar-view, which shows a sample implementation of a Xaml control.
sample-app-fabric now uses a CalendarView from the xaml-calendar-view package.

Microsoft Reviewers: Open in CodeFlow

JesseCol · 2025-06-19T20:07:34Z

packages/sample-app-fabric/windows/SampleAppFabric.Package/packages.lock.json

@@ -83,6 +83,17 @@
          "boost": "[1.83.0, )"
        }
      },
+      "microsoft.reactnative.xaml": {


I'm not sure why this entry is here -- "microsoft.reactnative.xaml" isn't a package, is it?

lock files include project dependencies

OK, this should go away when we remove the m.rn.xaml.vcxproj then.

JesseCol · 2025-06-19T20:09:07Z

packages/sample-app-fabric/windows/SampleAppFabric/SampleAppFabric.cpp

@@ -39,6 +41,9 @@ _Use_decl_annotations_ int CALLBACK WinMain(HINSTANCE instance, HINSTANCE, PSTR
  RegisterAutolinkedNativeModulePackages(settings.PackageProviders());
  // Register any native modules defined within this app project
  settings.PackageProviders().Append(winrt::make<CompReactPackageProvider>());
+  // TODO: Can we make apps register this automatically?  (e.g. with autolinking)
+  // TODO: But ideally we don't load the M.RN.Xaml.dll at all if we're not using Xaml.
+  settings.PackageProviders().Append(winrt::Microsoft::ReactNative::Xaml::ReactPackageProvider());


TODO: I don't know how to make this automatically happen with autolinking or whatever. Can the xaml-calendar-view package do this somehow? OTOH, if the app's not using Xaml, I don't want it to load Microsoft.ReactNative.Xaml.dll. Not sure the best way to handle this.

We would probably want to update autolinking to conditionally add the winrt::Microsoft::ReactNative::Xaml::ReactPackageProvider() to be loaded in the generated AutoLinkedNativeModules.g.cpp file.

We can either detect it needs to be there during autolinking (modules might register that they need it) and inject it there, OR we could just always put it in, behind a #ifdef RNW_NEW_ARCH_XAML_SUPPORT, powered by an aforementioned RnwNewArchXamlSupport variable.

Another solution: if XamlHost were in its own package, the existing autolinking logic should make this work.

DECISION: We decided to remove the Microsoft.ReactNative.Xaml.dll and move XamlHost into Microsoft.ReactNative.dll. This should resolve this problem.

JesseCol · 2025-06-19T20:11:57Z

packages/xaml-calendar-view/src/CalendarView.tsx

+  );
+}
+
+export { CalendarView, RawCalendarView };


The idea here is that the CalendarView object is already wrapped in a XamlHost, so is all ready to be put into a JSX tree. RawCalendarView is not. In the future maybe we make it possible to group multiple "Raw" elements under the same XamlHost.

If you had a tree of Xaml elements, would you expect something like this? (maybe not supporting layout panels with multiple children, but other controls that have 1 child)

<XamlHost> <RawStackPanel> <RawButton /> </RawStackPanel> </XamlHost>

I think we could support this without too much work if we want to. I haven't spent a lot of time exploring that though.

JesseCol · 2025-06-19T20:13:35Z

vnext/Microsoft.ReactNative.Xaml/ReactPackageProvider.idl

+  };
+
+  [webhosthidden]
+  interface IXamlControl


Implement this if your wrapping a Xaml object and want to be hostable in a XamlHost.

jonthysell · 2025-06-19T21:14:55Z

packages/sample-app-fabric/windows/SampleAppFabric.Package/packages.lock.json

@@ -83,6 +83,17 @@
          "boost": "[1.83.0, )"
        }
      },
+      "microsoft.reactnative.xaml": {


lock files include project dependencies

jonthysell · 2025-06-19T21:23:25Z

vnext/PropertySheets/External/Microsoft.ReactNative.Cpp.ProjectReferences.props

@@ -18,5 +18,13 @@
      <Name>Microsoft.ReactNative</Name>
      <Private Condition="'$(ConfigurationType)' != 'Application'">false</Private>
    </ProjectReference>
+
+    <!-- TODO: Should we only include this project ref conditionally? -->


This files is used by any external app/lib that tries to build RNW from source - and for NewArch we're trying to get everyone to build on the NuGets by default. The only apps that are building NewArch from source should be the ones inside this repo.

I would definitely put this in a conditional behind a new variable, maybe RnwNewArchXamlSupport? We could also use that variable to control a package reference (depending on if we publish this as a separate nuget or just as part of the existing nuget)

jonthysell · 2025-06-19T21:27:15Z

vnext/Microsoft.ReactNative.Xaml/App.idl

peferably XamlApplication.idl?

jonthysell · 2025-06-19T21:48:08Z

packages/sample-app-fabric/windows/SampleAppFabric/SampleAppFabric.cpp

@@ -39,6 +41,9 @@ _Use_decl_annotations_ int CALLBACK WinMain(HINSTANCE instance, HINSTANCE, PSTR
  RegisterAutolinkedNativeModulePackages(settings.PackageProviders());
  // Register any native modules defined within this app project
  settings.PackageProviders().Append(winrt::make<CompReactPackageProvider>());
+  // TODO: Can we make apps register this automatically?  (e.g. with autolinking)
+  // TODO: But ideally we don't load the M.RN.Xaml.dll at all if we're not using Xaml.
+  settings.PackageProviders().Append(winrt::Microsoft::ReactNative::Xaml::ReactPackageProvider());


We would probably want to update autolinking to conditionally add the winrt::Microsoft::ReactNative::Xaml::ReactPackageProvider() to be loaded in the generated AutoLinkedNativeModules.g.cpp file.

We can either detect it needs to be there during autolinking (modules might register that they need it) and inject it there, OR we could just always put it in, behind a #ifdef RNW_NEW_ARCH_XAML_SUPPORT, powered by an aforementioned RnwNewArchXamlSupport variable.

jonthysell · 2025-06-19T21:56:31Z

packages/xaml-calendar-view/NuGet.config

We don't want another file here, we already have one at the repo root to keep all of the projects aligned.

jonthysell · 2025-06-19T22:30:13Z

vnext/Microsoft.ReactNative.Xaml/Microsoft.ReactNative.Xaml.vcxproj.filters

+    <ClInclude Include="pch.h" />
+  </ItemGroup>
+  <ItemGroup>
+    <Midl Include="Class.idl" />


Out of date files

jonthysell · 2025-06-19T22:32:42Z

vnext/Microsoft.ReactNative.Xaml.sln

Not sure if we need this to be it's own solution - maybe fine for now, will depend on how we want to package the dll

DECISION: We decided to remove Microosft.ReactNative.Xaml.dll entirely. So this sln will go away too.

jonthysell · 2025-06-19T22:35:56Z

packages/xaml-calendar-view/windows/XamlCalendarView/XamlCalendarView.h

If XamlCalendarView doesn't have any non-UI functionality, you can probably remove the struct here.

jonthysell · 2025-06-19T22:40:38Z

vnext/Microsoft.ReactNative.Xaml/Microsoft.ReactNative.Xaml.vcxproj

+    <AppContainerApplication>false</AppContainerApplication>
+    <ApplicationType>Windows Store</ApplicationType>
+    <ApplicationTypeRevision>10.0</ApplicationTypeRevision>
+    <WindowsTargetPlatformVersion Condition=" '$(WindowsTargetPlatformVersion)' == '' ">10.0.22621.0</WindowsTargetPlatformVersion>


Don't want to hardcode the SDK versions.

jonthysell · 2025-06-19T22:42:52Z

vnext/Microsoft.ReactNative.Xaml/XamlApplication.cpp

Does having this type here preclude app authors from having their own Xaml app? I.e. A classic WinAppSDK app with it's own App, using a ReactNativeIsland, to put RNW in just part of the UI, then have that RNW also load Xaml?

I think this is possible, but the app would need to have its own Application object subclass the RNW XamlApplication. WinAppSDK also only supports one version in the process at a time.

JesseCol · 2025-07-01T18:55:58Z

packages/xaml-calendar-view/src/CalendarView.tsx

+import * as React from 'react';
+import RawCalendarView from './CalendarViewNativeComponent';
+
+import XamlHost from 'react-native-windows/Libraries/Components/Xaml/XamlHost';


This is an awkward import into a deep path. Should XamlHost be a separate package?

JesseCol · 2025-07-01T19:15:31Z

vnext/Microsoft.ReactNative.Xaml/Microsoft.ReactNative.Xaml.vcxproj

DECISION: Let's fold the Xaml logic into the M.RN.dll. We still want to be careful that Xaml-specific code doesn't get mixed in with the core logic.

JesseCollins added 3 commits June 17, 2025 10:12

Checkpoint 1

01e4966

It builds/works

36d3116

A little cleanup

068bb1d

JesseCol commented Jun 19, 2025

View reviewed changes

jonthysell reviewed Jun 19, 2025

View reviewed changes

Add a prop and event

205e51d

JesseCol commented Jul 1, 2025

View reviewed changes

Xaml support prototype #14811

Are you sure you want to change the base?

Xaml support prototype #14811

Uh oh!

Conversation

JesseCol commented Jun 19, 2025 • edited by microsoft-github-policy-service bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Microsoft Reviewers: Open in CodeFlow

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

JesseCol commented Jun 19, 2025 •

edited by microsoft-github-policy-service bot

Loading