Support custom native components that are not FrameworkElement

[aschultz]

Summary

Microsoft.ReactNative exposes the IViewManager interface to enable export of custom native UI components into the React environment. However, the interface has the notable restriction that the views it creates and manages must be based on FrameworkElement. This prevents its use with a number of unique XAML elements, such as those derived from TextElement or FlyoutBase.

The IViewManager interfaces should instead use DependencyObject as the common "view" type.

Example

I wish to create a block of text with a stylized and clickable inline link embedded in it. My React might look like:

render() {
    return <Text>This sentence includes a <Link url={...}>link</Link></Text>
}

Here the Text element is built-in to RNW as a XAML TextBlock control. The Link element would ideally be a XAML Hyperlink element that gets added as a child. Since Link is not built-in to RNW, we might create a custom view manager to provide this functionality. However, Hyperlink is not derived from FrameworkElement, so we cannot currently surface it through an IViewManager implementation.

Details

Some of the changes I expect will be needed:

• IViewManager, IReactContext, and XamlUIService should switch to using DependencyObject instead of FrameworkElement/UIElement
• ABIViewManager stops deriving from FrameworkViewManager and instead applies base logic depending on the views being managed.
  • View managers for FrameworkElement-derived views should get access to the same rich defaults as before (handling of layout, accessibility, and input event props).
  • View managers for other views should probably be marked as not affecting layout. FlyoutBase may need a special case here that allows it to register and host a root Yoga node.
• Address RNW shouldn't use Tag property internally. #4187, as Tag is specific to FrameworkElement

[chrisglein]

Should this go all the way to IInspectable? What has us stop specifically at DependencyObject? If we're no longer looking at what's in the XAML tree, it doesn't need to be a XAML type (outside of some root that links up). Is there a scenario for that? Not saying this is a requirement, but worth exploring the needs here. Not needed for the TextElement scenario, since that's a DO.

Some design work needed here to figure out what's the minimal set of operations needed. But seems like we can unblock the Text scenario.

[chrisglein]

@aschultz Do you have a timeline for when you'd need this?

[aschultz]

@chrisglein One advantage of stopping at DependencyObject is that it provides an easy means to stash/retrieve the React tag value as an attached property (instead of using FrameworkElement.Tag). If you go up to IInspectable you'd have to find another solution.

As for timeline -- I'm in the process of upgrading our app to 0.62 and just ran into this as a blocker for upgrading a Hyperlink component that's used in chat messages. It appears to be used in only that one place, so we might be able to craft a workaround in the short term. Otherwise, I was hoping to have us upgraded by the end of this month.

[ladebo]

@chrisglein Hello! From @aschultz 's last comment -- we're now using inline links in more locations (like FAQs and descriptions that are controlled content). Having this functionality to create a link, surrounded by plain text, moving forward would really help us. We've been running into issues with our workaround control and updating it to new scenarios.

Wanted to note in case this bug could be bumped up in priority.

[asklar]

@ladebo @aschultz I wanted to reach out and let you know about a module that has some intersection with the work described here: https://github.com/asklar/react-native-xaml/

We added a IViewManagerCreateWithProperties interface in 0.64 which is IInspectable-based, but the framework still expects objects returned by the view manager to be framework elements. react-native-xaml works around this by wrapping non-FrameworkElements into a ContentControl, then unwrapping them when they're added to the tree and doing the right thing to attach them to a parent (e.g. setting the flyout property if the child is a flyout, etc.).

The main purpose of the react-native-xaml module is to allow using XAML controls directly from a React Native Windows app. Let me know if this is useful to you guys, maybe the wrapping/unwrapping technique works for you too : )

[asklar]

Renaming issue since we'll want to avoid repeating the same mistake of tying the API surface to a xaml dialectal type

[rozele]

We discussed offline recently that it likely makes sense to continue tying interfaces for Paper to a XAML dialect type until Fabric (cc @acoates-ms). Here is a proposal for what interfaces we would need:

interface IDependencyObjectViewManager {
  String Name { get; };
  DependencyObject CreateView(int tag, int rootTag, IJSValueReader propertyReaderMap);
}

interface IDependencyObjectViewManagerWithUnmount {
  void DropView(DependencyObject view);
}

interface IDependencyObjectViewManagerWithChildren {
  IMapView<String, ViewManagerPropertyType> NativeProps { get; };
  void UpdateProperties(DependencyObject view, IJSValueReader propertyMapReader);
}

interface IDependencyObjectViewManagerWithCommands {
  IVectorView<String> Commands { get; };
  void DispatchCommand(DependencyObject view, String commandId, IJSValueReader commandArgsReader);
}

interface IDependencyObjectViewManagerWithChildren {
  void AddView((DependencyObject parent, DependencyObject child, Int64 index);
  void RemoveAllChildren(DependencyObject parent);
  void RemoveChildAt(DependencyObject  parent, Int64 index);
  void ReplaceChild(DependencyObject parent, DependencyObject oldChild, DependencyObject newChild);
}

[asklar]

I have a strong preference for not tying any new API to a xaml dialect/version.

[chrisglein]

Investment focus is on Fabric where this consideration is no longer relevant. Won't fix for Paper.