Serializing IInspectable to RNW

[asklar]

Context

I'm working on react-native-xaml which allows projecting XAML types for use in RNW apps via the ViewManager API, and allows apps to use these XAML types directly in their JSX markup.

One of the features that is important to support is setting up event handlers from JS; these event handlers need to be able to get event args. Currently the support in react-native-xaml for event args is fairly limited. Basically the way this works is we try to serialize what we consider important properties on every relevant type. For example, for every UIElement we will serialize the Name and Tag properties, for every object we will serialize the runtime class name, for MenuFlyoutItem we would serialize the Text properties, for SelectionChangedEventArgs we serialize what things were added and removed to the selection, etc.

Feature request

I'd like to eventually get out of the business of having to do this serialization manually, and instead rely on jswinrt for it. Basically I'd like to have a native API from jswinrt that looks like:

void JSWinRT::Serialize(
    const winrt::Microsoft::ReactNative::JSValueWriter& writer, 
    const winrt::Windows::Foundation::IInspectable& obj)

[nichamp]

JsWinRT wouldn't really work for your scenario I suspect because you would still want to support web browser debugging but projections require using the built-in JS engine. Additionally, JS runs on a different thread than XAML, so JS cannot interact directly with XAML through projections without changing this or inventing some adapter layer or other hacks like I had been contemplating in the past.

I suspect what you need is similar to how the codegen works for events and delegates but specific to the rest of how you are using conventional Native Modules. You could probably use the x:lang winmd parser like jswinrt does.

[asklar]

Web browsing is likely going away soon so I'm not concerned about that aspect. The threading is something that'd need to be looked at though.

[nichamp]

With Chakra at least, the debugging experience using something like VS was much poorer than F12 tools. Perhaps I was using it wrong but it was certainly not nice (e.g. mapping not working) what little I tried it.

[asklar]

Probably off-topic, but yes I hear that. We're likely to need to work with VS to improve this scenario.