Split up the Microsoft.ReactNative.dll into two DLLs: Core and UWP

[vmoroz]

Task: Split up the Microsoft.ReactNative.dll into two DLLs: Core and UWP

Summary

Introduce a new Microsoft.ReactNative.Uwp.dll that has all the UWP specific code. It includes the ReactApplication, native modules, ViewManagers and any other XAML-based code. The Microsoft.ReactNative.dll is kept as a relatively thin wrapper around the ReactNative code and exposes it through the ABI-safe API.

Motivation

There are several scenarios we would like to address:

• Use Microsoft.ReactNative.dll for non-XAML based UI.
• Use Microsoft.ReactNative.dll for UWP and Win32 applications.
• Write internal and external NativeModules and TurboModules using the same ABI-safe API.

Basic examples

• Generate TurboModules based on ReactNative spec files that have the same shape for internal and external code that use the same ABI-safe API.
• Microsoft Office applications require to define its own UI ViewManages based on non-XAML components.

Open Questions

• Where should we have the UI shadow tree: in Microsoft.ReactNative.dll or Microsoft.ReactNative.Uwp.dll? Ideally it should be in the common shared core Microsoft.ReactNative.dll.
• Should the the new "Core DLL" Microsoft.ReactNative.dll support plugable JavaScript engines (Hermes, V8, Chakra) or it must wrap only one of them?

[chrisglein]

Sounds great, @vmoroz. Do you have an idea of timeline for when we should do this? Is there overlap with what @htpiv is doing with Win32?

[NickGerleman]

Introduce a new Microsoft.ReactNative.Uwp.dll that has all the UWP specific code. It includes the ReactApplication, native modules, ViewManagers and any other XAML-based code.

@vmoroz I think this came up in discussion before, but whatever design we come up with should also account for shared native modules between UWP and win32. We've historically had a lot of duplication there, but there are some we're sharing even right now.

[vmoroz]

@NickGerleman the plan is to have them shared as source code for both UWP and Win32 specific DLLs. Hopefully the exact implementation pattern will emerge as we work on this task.

[vmoroz]

@chrisglein we currently plan to do this work in Q2 of CY (calendar year) 2020. It means that we target most of this work to be done by end of May or mid-June 2020. We must understand the Build conference presentation demo requirements to schedule the most critical work to be completed by the end of April 2020.

[vmoroz]

@chrisglein as for the connection with the work done by @htpiv, we hope to provide a foundation for what he builds for Win32 platforms. Our work mostly focuses on the 'low level' APIs concerning ReactNative instance management and native modules / TurboModules support, while @htpiv focuses on enabling ReactNative for Win32 based on the new XAML implementation.

[JunielKatarn]

I suspect shared (Desktop and Universal) Modules, Executors, etc, could be implemented in a Shared Library, which would ultimately be linked into the Desktop modules DLL and Universal modules DLL respectively.

This project would have the same role as ReactWindowsCore.

[asklar]

re: JS engine - we should try to limit complexity and target one engine at a time. We don't want to force projects to pay the disk cost for engines they won't use. See #4820