We set out to address this since a lot of applications won’t need to customize their native code (e.g. by having XAML UI that isn’t rendered by RNW); these greenfield<\/em> applications consist of the bare-bones native UWP app, and all of their app logic is confined to their JavaScript (and whatever native modules they require).<\/p>\n To solve this issue, we came up with a very lean, yet flexible, API that enables a UWP Core Application (the kind that doesn’t require XAML, or any interface definition) to host these greenfield<\/em> apps. We call this API This is a new, experimental<\/em> C API that comes in two flavors:<\/p>\n This API starts a This API is similar to the previous one but it takes a path to a JSON configuration file. The callback is optional in this case, since more often than not, the configuration file will have all the necessary information.<\/p>\n The The contents of the Below are the properties you can set in your app.config.json, with their default values.\nThese properties correspond to properties on the ReactInstanceSettings type.<\/p>\n For building in Debug mode, your app will usually only need to set a few properties: There are a couple of ways that a The simplest way is using the This snippet will declare a plain C function (this is important so that C++ name mangling mechanism doesn’t come into play, which is required to be able to use the function name in the JSON file), and export it from the DLL (or the application’s EXE). It takes no parameters, and simply return a pointer to the package provider for the module.<\/p>\n If using where For a sample, take a look at the Calculator CoreApp NuGet project in \/samples\/CalculatorCoreAppNuGet<\/a>.<\/p>\n With the Compare the calculator sample app (C++\/WinRT, not using NuGet, not using CoreApp), takes almost 15 minutes to build:\n The same app built using NuGet (but not CoreApp), slashes this to 3.5 minutes:\n Meanwhile the CoreApp calculator sample clocks in at a speedy 1:49!\n Look for this new API to make its debut in our 0.70 release, or try it today in our canary builds.<\/p>\n If you have any feedback, please don’t hesitate to start a conversation on the GitHub repo<\/a>!<\/p>\n If you\u2019re interested in getting started with React Native for Windows, check out our website at aka.ms\/reactnative<\/a>.<\/p>\nEnter
CoreApp<\/code><\/h2>\nCoreApp<\/code>.\nWhen using the CoreApp<\/code> API, the React Native for Windows framework provides the required XamlApplication<\/code> object as well as a simple XAML Page<\/code> object, which contains a React root view.<\/p>\nRNCoreAppStart<\/code><\/h3>\nvoid RNCoreAppStart(RNCoreAppCallback launched, void *data)<\/code><\/pre>\nCoreApp<\/code>, and upon launch, it will call your app back and pass some optional custom data to it as a parameter. The callback enables you to customize a number of parameters, like your bundle name, app name, etc. See CoreApp Schema below for more info.<\/p>\nRNCoreAppStartFromConfigJson<\/code><\/h3>\nvoid RNCoreAppStartFromConfigJson(wchar_t const *configJson,\n RNCoreAppCallback launched,\n void *data)<\/code><\/pre>\nlaunched<\/code> callback above gives you an output RNCoreApp<\/code> structure, where you can set a number of parameters, as well as the data<\/code> parameter that you passed in when you called the CoreApp<\/code> API.<\/p>\nRNCoreApp<\/code> structure can be fully set via the JSON configuration file, so next we’ll take a look at what is in this JSON configuration file.<\/p>\nCoreApp<\/code> schema<\/h2>\n{\n \"jsBundleFile\": \"index.windows\",\n \"bundleRootPath\": \"ms-appx:\/\/\/Bundle\/\",\n \"componentName\": null, \/\/ Required, this is your App's component name\n \"useWebDebugger\": true,\n \"useFastRefresh\": true,\n \"useDeveloperSupport\": true,\n \"useDirectDebugger\": false,\n \"requestInlineSourceMap\": true,\n \"enableDefaultCrashHandler\": false,\n \"debuggerPort\": 9229,\n \"sourceBundlePort\": 8081,\n \"sourceBundleHost\": \"localhost\",\n \"jsEngine\": \"chakra\", \/\/ possible values: \"chakra\", \"hermes\"\n \"viewName\": null, \/\/ adds an optional title to the window\n \"nativeModules\": [\n {\n \/\/ this corresponds to the DLL that hosts the native module,\n \/\/ or the name of the app's exe (or null) if the module is locally defined\n \"moduleContainer\": null,\n\n \/\/ the name of the factory function to call to produce a ReactPackageProvider for\n \/\/ the module; see Using native modules below.\n \"factory\": null\n }\n ],\n \"properties\": {\n \/\/ these are all optional. They correspond to properties that will get set in the\n \/\/ ReactPropertyBag for the instance. Some examples:\n \"someString\": \"string value\",\n \"someNumber\": 42.5,\n \"someBoolean\": true,\n \"namespace1.namespace2.foo\": 22\n }\n}<\/code><\/pre>\ncomponentName<\/code>, and the native modules it uses.<\/p>\nUsing native modules<\/h2>\n
CoreApp<\/code> can load native modules.<\/p>\nRNCoreAppStartFromConfigJson<\/code> API. As we saw above, this API allows us to pass an optional DLL name to load and a plain C function to call in that DLL, to produce the ReactPackageProvider<\/code> for the module.\nHere’s what this function would look like:<\/p>\nextern \"C\" __declspec(dllexport) void *__cdecl MySpecialPackageProvider() {\n auto provider = winrt::make<MyModulePackageProvider>();\n void *abi{nullptr};\n winrt::copy_to_abi(provider, abi);\n return abi;\n}<\/code><\/pre>\nRNCoreAppStart<\/code>, you can create each the ReactPackageProvider<\/code> for each native module you use, and pass it in the packageProvidersAbi<\/code> and packageProvidersAbiCount<\/code> members of the RNCoreApp<\/code> structure:<\/p>\napp->packageProvidersAbiCount = 1;\napp->packageProvidersAbi =\n reinterpret_cast<void **>(CoTaskMemAlloc(sizeof(void *) * app->packageProvidersAbiCount));\napp->packageProvidersAbi[0] = MySpecialPackageProvider();<\/code><\/pre>\nMySpecialPackageProvider<\/code> is the same as above, only that the extern \"C\" __declspec(dllexport)<\/code> part is not required since we don’t care about the name, or exporting the function.<\/p>\nGet Started<\/h2>\n
Wrapping up<\/h2>\n
RNCoreApp<\/code> approach – combined with NuGet distribution – we are seeing extremely fast native builds; builds that used to take 15-30 minutes now are down to 10-15 seconds. Because your application actually has very little native code to build, and all of the native logic is encapsulated for you in the React Native for Windows framework, you can get back to being productive in JavaScript, avoid hard-to-diagnose native code errors, and ship your app more quickly!<\/p>\n![\"Calculator](\"https:\/\/devblogs.microsoft.com\/react-native\/wp-content\/uploads\/sites\/76\/2022\/11\/Calculator.png\")
<\/p>\n![\"Calculator](\"https:\/\/devblogs.microsoft.com\/react-native\/wp-content\/uploads\/sites\/76\/2022\/11\/CalculatorNuGet.png\")
<\/p>\n![\"Calculator](\"https:\/\/devblogs.microsoft.com\/react-native\/wp-content\/uploads\/sites\/76\/2022\/11\/CalculatorCoreAppNuGet.png\")
<\/p>\n