DRAFT: Prototype of exposing hooks for core view manager providers

[rozele]

For apps that don't require ABI, expose an API to create IViewManager instances (including those that derive from ViewManagerBase) directly.

Microsoft Reviewers: Open in CodeFlow

[asklar]

For apps that don't require ABI, expose an API to create IViewManager instances (including those that derive from ViewManagerBase) directly.

Microsoft Reviewers: Open in CodeFlow

note that we want to actively discommend using the C++ APIs directly and instead have everyone one the ABI, as this will enable apps/modules/framework to be distributed in binary form. We should be moving more stuff towards ABI not the opposite :)

[rozele]

note that we want to actively discommend using the C++ APIs directly and instead have everyone one the ABI, as this will enable apps/modules/framework to be distributed in binary form. We should be moving more stuff towards ABI not the opposite :)

Totally get it, but this will dramatically reduce the number of differences we have in our fork of RNW native code. The main limitation of the ABIViewManager is it's based off FrameworkElement and not DependencyObject (see #5539). Agree that we should move forward towards this, but this solves a very immediate need for us.

[NickGerleman]

This change does not seem to affect our own DLL surface, so I'm okay with it.

Plugging directly into internal APIs has the potential to be a footgun, but long term forks kind of pay into that already.

[asklar]

we're having active discussions with you all on how to best enable this scenario in an ABI safe manner, so blocking until we resolve that

[rozele]

Closing for now, we've hopefully worked around all the cases where we needed non-ABI view managers at this time.