Summary:
Adding a new github workflow script, which will run as part of the existing triage job that is triggered when an issue is labeled with the "Needs: Triage" label (this typically happens automatically when the issue is created).
This script will add an extensive list of possible labels corresponding to APIs, components, and topics (see the code for the full list).
The motivation for this change is to replace the last bit of meaningful functionality performed by react-native-bot, which will allow us to decommission that bot in favor of using github workflows for all issue and PR automation.
## Changelog:
[INTERNAL] [CHANGED] - Updated API, topic, component labeling on issues to run from a GH workflow rather than an external bot action
Pull Request resolved: https://github.com/facebook/react-native/pull/36712
Test Plan:
For examples of issues being labeled by this new script, see the open issues here: https://github.com/SlyCaptainFlint/react-native/issues
I did not test every possible label, but I tested at least one from each category (API, component, topic), and a combination of one or two of each.
Reviewed By: cortinico, cipolleschi
Differential Revision: D44593658
Pulled By: SlyCaptainFlint
fbshipit-source-id: 93758d05a70d02bed76ab0b6149271e757e0a12f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36791
This is a re-land of D44635949. It was reverted as it was a suspected cause of CircleCI fails. It turned out the diff was unrelated, and the cause was something else.
## Changelog
[Internal][Security] - Use execFileSync over exec for cases with uncontrolled absolute paths
Reviewed By: cortinico
Differential Revision: D44663132
fbshipit-source-id: dfb3d09dbfbe3312ef54bcbbc43c8b4062d787a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36781
----
Add support to msggen for types like:
* Runtime.CustomPreview
* Runtime.EntryPreview
* Runtime.ObjectPreview
* Runtime.PropertyPreview
And their related use as properties.
There was quite a gap here. The work involves:
* Upgrade devtools-protocol to 0.0.1107588 even pick up the schema definitions in the first place.
* Next problem: all the preview stuff is experimental. Had to add support to --include-experimental flag for targeting types AND properties.
* Next problem: the protocol schema for previews is cyclical. ObjectPreview refers to PropertyPreview and EntryPreview, which both refer back to ObjectPreview. msggen only allowed for DAGs. Added support for allowing cycles.
* Next problem: Forward declarations are not enough to compensate for the cyclical references, because of the incomplete type definitions. This breaks optional, vector, and simple containment. To address this:
* In the graph traversal code, where before we would error if the graph had a cycle, we allow for the cycle, but record the cyclical reference from a property on Type B's to Type A.
* Whenever we emit the definition of Type B, its references to Type A are not naked, they are now wrapped in a unique_ptr.
* However, because the unique_ptr only has a forward declaration, and not a complete type, we need to specify a custom deleter.
* Next problem: There are lots of cases where these types that now contain unique_ptrs were being copied, which no longer works. So, make all these codegen'd types move-only, and change a few places where were copying root objects, to move them instead.
* Many tests required changes to avoid copy construction/assignment that were occuring. MessageTypes are not copyable construcrtible/assignable now.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D43553742
fbshipit-source-id: 1e4c495aa600feb6f1901e6bc013d517ba8d8a2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36778
Changelog: [Internal]
we can just use mockito for this suite
Reviewed By: mdvacca
Differential Revision: D44603023
fbshipit-source-id: b8f6f37fccba38990fe498d8f5e479f174ff93af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36779
Deprecate and mark for removal com.facebook.react.common.StandardCharsets, this class was originally created because java.nio.charset.StandardCharsets only exists in Android API level 19+
As part of this diff I also migrate all internal usages of com.facebook.react.common.StandardCharsets
Changelog:
[Android][Deprecated] - Deprecate and mark for removal com.facebook.react.common.StandardCharsets, please use java.nio.charset.StandardCharsets instead
Reviewed By: rshest
Differential Revision: D44592721
fbshipit-source-id: c3f4286766209a733b466d19dc36891f12d69be1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36796
As the title says, this fixes a instacrash on template when `createRootView` is invoked with
a bundle being null. The crash was happening as the parameter, despite being not used, is
specified as `Bundle` and is not nullable. When the Java caller passes `null`, the app crashes.
Changelog:
[Android] [Fixed] - Fix a crash new app template when `createRootView` is invoked with null bundle
Reviewed By: cipolleschi
Differential Revision: D44668305
fbshipit-source-id: 1150ddac26f19765e7340878c8850d8462c6f3fd
Summary:
Adds changelog for new patches.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.71.6, 0.70.8 and 0.69.9
Pull Request resolved: https://github.com/facebook/react-native/pull/36792
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D44663440
Pulled By: cipolleschi
fbshipit-source-id: d84e997784c1ecfb02968fecf147b2ef558d4381
Summary:
This exposes a new method in the private interface used by React so we can merge https://github.com/facebook/react/pull/26516
We're adding support for text instances in React Native (as defined in https://github.com/react-native-community/discussions-and-proposals/pull/607). See D44632362 for the full implementation.
Changelog: [internal]
bypass-github-export-checks
Reviewed By: sammy-SC
Differential Revision: D44663223
fbshipit-source-id: 70ca3ca9d2edefaa73a396f43c2d560c6d1422f1
Summary:
Yesterday, CLI published version 11.1.1 which has a strong dependency on `react-native/metro-config` 0.72.
On `main`, all the packages we publish to test the template have version 0.73.
So, when running tests on the template, the cli was looking for a `metro-config` version 0.72, but it could not find it as verdaccio
only has version 0.73.
Together with Callstack, we released a version 12.0.0-alpha.0 of the CLI which have the right dependency on metro-config v0.73, so that
our CI can be green again.
bypass-github-export-checks
## Changelog:
[General][Fixed] - Bumped CLI dependency on main to 12.0.0-alpha.0
Pull Request resolved: https://github.com/facebook/react-native/pull/36793
Test Plan: CircleCI must be green
Reviewed By: huntie
Differential Revision: D44663381
Pulled By: cipolleschi
fbshipit-source-id: 30d341d55243318ce278a6e67a9e77ccfb90cafd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36780
Original commit changeset: 8e0ebb070768
Original Phabricator Diff: D44131032
Changelog: [Internal]
all the circleCI template tests started failing after this commit, revert!
Reviewed By: jacdebug, cortinico
Differential Revision: D44635949
fbshipit-source-id: 429167acdbee3ebf6d81491ac65896c534c18fd0
Summary:
This PR is adding examples of Turbo Modules functions throwing runtime exceptions and asserts. This should make it easier to collaborate and develop the error reporting for a new architecture that is being discussed in the React Native New Architecture Working Group -> https://github.com/reactwg/react-native-new-architecture/discussions/122.
I'm not sure what return type should be used for the JS function returning `Promise<void>` in Cxx, I used [`AsyncPromise<jsi::Value>`](https://github.com/facebook/react-native/pull/36729/files#diff-9cebc75f48fd35fd6fef71138f98dfd0ba28a754b2aab0d6fe44fd685f74ce16R135), what would you use, I've not found `void` type to use?
### Added functions
The table shows the current behavior.
<table>
<tr>
<td> Function
<td> Description
<td> Turbo Module
<td> Cxx Module
<tr>
<td> voidFuncThrows
<td> function with return type void throws a runtime exception
<td> platform error no JS stack trace
<td> JS error no native stack trace
<tr>
<td> getObjectThrows
<td> function with return type object throws a runtime exception
<td> JS error no platform stack trace
<td> JS error no native stack trace
<tr>
<td> promiseThrows
<td> function with return type promise throws a runtime exception before settling the promise
<td> platform error no JS stack trace
<td> JS error no native stack trace
<tr>
<td> voidFuncAssert
<td> function with return type void asserts
<td> platform error no JS stack trace
<td> native error no JS stack trace
<tr>
<td> getObjectAssert
<td> function with return type object asserts
<td> JS error no platform stack trace
<td> native error no JS stack trace
<tr>
<td> promiseAssert
<td> function with return type promise asserts before settling the promise
<td> platform error no JS stack trace
<td> native error no JS stack trace
</table>
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [ADDED] - Error reporting examples in rn-tester turbo modules
Pull Request resolved: https://github.com/facebook/react-native/pull/36729
Test Plan:
This PR doesn't change any RN behavior. Only shows the current state by adding an example to rn-tester.
I'm happy to add these examples to the unit/integration test, just point me to where would be a good place.
Reviewed By: rshest
Differential Revision: D44623027
Pulled By: javache
fbshipit-source-id: d9cc04852b05d810ed11d7a94f1b2d455ef554a5
Summary:
In our fork React Native macOS, we run [Github's CodeQL ](https://codeql.github.com) to analyze for vulnerabilities. One common one that comes up is the use of `exec` with an uncontrolled absolute path (Example: https://github.com/microsoft/react-native-macos/security/code-scanning/14). The very simple fix to this is to replace calls to `exec` with `execFileSync`, which more or less does the same thing (but more securely!).
## Changelog
[INTERNAL] [SECURITY] - Use `execFileSync` over `exec` for cases with uncontrolled absolute paths
Pull Request resolved: https://github.com/facebook/react-native/pull/36491
Test Plan: CI should pass
Reviewed By: cipolleschi
Differential Revision: D44131032
Pulled By: dmytrorykun
fbshipit-source-id: 8e0ebb07076838216f878f802ec937d2df44f33a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36737
## Changelog:
[Internal] - Use `BoundedConsumableBuffer` in WebPerformance
This makes use of the `BoundedConsumableBuffer` container type, introduced in D44544057, for buffering/observing arbitrary performance entry types in `WebPerformance/PerformanceEntryReporter`, thus generalizing what was earlier done in an ad-hoc way for marks and measures, and also allowing to have both observable/retrievable/buffered property for arbitrary performance entry type (with the ultimate goal of adding custom entry types, related to e.g. startup timing, something that we currently have an ad hoc API for).
Reviewed By: sammy-SC
Differential Revision: D44574241
fbshipit-source-id: a858712ff1cf468914a80c99f6b82d060cb0b702
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36726
## Changelog:
[Internal] -
This implements (together with unit tests) a generic container type, `BoundedConsumableBuffer` with the following properties:
* It can only grow up to a specified max size
* It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element)
* The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer
* Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times
The buffer effectively wraps around when adding new elements. Once an element added, it becomes "consumable" (or "observable") and remains such, until all of the current outstanding elements are explicitly "consumed". It doesn't get immediately removed from the buffer, however (if max buffer size allows), and can be later retrieved via the `getEntries` API, until eventually overwritten.
{F928241747}
The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not).
In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type.
Reviewed By: sammy-SC
Differential Revision: D44544057
fbshipit-source-id: 5b7d055a6fc813ebb0fb30f9b346723161774260
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36771
Changelog: [internal]
Previously, when `NSTextStorage` was cached, we were not accounting for case where text which was aligned to centre or left, was used to size its container.
The result was that it was painted outside of its container, therefore invisible. To fix this, we adjust the offset to make sure text is painted correctly.
This bug only happens if:
- Text is not aligned to left in right to left writing system.
- The canvas where text is drawn is not stretched to full width of its parent.
- The offset needs to be large enough for this to matter, otherwise the text is just slightly off.
- Because of the caching mechanism, it had to be a piece of text that was rendered before. Otherwise it would work.
This complexity is worth the trouble to avoid invalidation of layout inside NSTextContainer, which is expensive.
Reviewed By: cipolleschi
Differential Revision: D44624085
fbshipit-source-id: 1bb8ef88933a49b478a2606dba6bf16b4e728b2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36773
Changelog: [internal]
Do not construct `NSAttributedString` if `NSTextStorage` exists. Creating `NSAttributedString` is expensive and it isn't needed to measure text if `NSTextStorage` `exists`
Reviewed By: cipolleschi
Differential Revision: D44620292
fbshipit-source-id: 0827c514e40fcbd9626d2b7d7b6d28a3332d9aa1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36759
On Thursday the 30th, Apple Released Xcode 14.3.0.
This Version of Xcode enforce some version checks for which React-Codegen, which supported iOS 11 as minimum supported version, could not be build anymore.
This change ensue that React-Codegen is always aligned to the min version supported by React Native.
Plus, it moves CircleCI's Xcode to 14.3.0, to keep this problem in Check.
While working on this, I figured that, with the monorepo, Ruby tests stopped working because they were in the wrong folder: I moved them in the right one.
## Changelog:
[iOS][Fixed] - Make React Native build with Xcode 14.3.0 and fix tests
Reviewed By: blakef
Differential Revision: D44605617
fbshipit-source-id: 3ec1f5b36858ef07d9f713d74eb411a1edcccd45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36756
This diff is reverting D44153451
Depends on D44602279
D44153451: [Fabric][Android] Reduce visibility of FabricSoLoader by mdvacca has been identified to be causing the following test or build failures:
Tests affected:
- [xplat/endtoend/jest-e2e/apps/fb4a/__tests__/consumerwifi/venice/fb4aVeniceAddressSearch-e2e.js](https://www.internalfb.com/intern/test/281475007251570/)
Here's the Multisect link:
https://www.internalfb.com/multisect/1799601
Here are the tasks that are relevant to this breakage:
We're generating a revert to back out the changes in this diff, please note the backout may land if someone accepts it.
Reviewed By: mdvacca
Differential Revision: D44602284
fbshipit-source-id: 50b3b0f131c6c8c1eec3c23156b33559ffc3931e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36752
Changelog: [Internal]
as title! i'm not actually familiar enough with junit as to why the test infra cannot find `Arguments.java` since it is part of our framework, not something externally linked or an under the hood library, so if someone wants to explain that to me that'd be great
Reviewed By: cortinico, mdvacca
Differential Revision: D44527486
fbshipit-source-id: d94f4eebdb6b7cdf7e40e44bfec8703615b96963
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36747
Introduce NO_SURFACE constant to specify the lack of surfaces used by legacy system
changelog: [internal] internal
Reviewed By: sshic
Differential Revision: D44563649
fbshipit-source-id: 99c7028c5ee508c2982cefc9b3199a332c2346c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36749
Reduce visibility of FabricSoLoader
This is a breaking change, but nobody should be using this class
Changelog: [internal] internal
Reviewed By: javache, cortinico
Differential Revision: D44153451
fbshipit-source-id: 942c80da3987d3639b055804c24fc34543a99907
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36733
Changelog:
[Android][Added] - Added testing shadow helpers for robolectric
in this change, i'm creating a centralized place for test writers to add their shadows in robolectric. as we start deprecating powermock, we can expect that common infra classes will be needed to be stubbed out, so we can leverage this library in order to do so.
Reviewed By: javache
Differential Revision: D44565806
fbshipit-source-id: 2e322861e8e2f49ede21e4a000495d5f06b911d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36741
AnimatedObject is a more generic version of AnimatedTransform, able to handle animated values within arrays and objects. This is useful for props of native components that may need to be animated per field.
This diff hooks up AnimatedObject to AnimatedProps and AnimatedStyle for values that are arrays or objects.
Changelog:
[Internal][Added] - Modify AnimatedProps and AnimatedStyle to use AnimatedObject
Reviewed By: rshest
Differential Revision: D44315336
fbshipit-source-id: 4d543550f24adbfc2ce4b15640df03f260da6106
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36688
AnimatedObject is a more generic version of AnimatedTransform, able to handle animated values within arrays and objects. This is useful for props of native components that may need to be animated per field.
I considered flattening the node graph by removing AnimatedStyle and AnimatedTransform. However, this would add significant complexity in AnimatedProps because prop and style values depend on being submitted together on an animation tick (such as transform) using native driver; also, we'll have to special case style anyway.
Changelog:
[Internal][Added] - Introduce AnimatedObject JS node for handling array and object prop values
Reviewed By: rshest
Differential Revision: D44279594
fbshipit-source-id: 9504d841dc9196e51d09a0247601de4d4f991a49
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36718
`EventEmitterWrapper` uses "invoke", while the event is still being queued and the event handler will only actually be "invoked" in another async step. Instead, align with the wrapped object and use "dispatch".
Also small optimization to construct the EventEmitterWrapper object fully in C++, without Java having to call back into C++ again by using `newObjectCxxArgs`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D44536400
fbshipit-source-id: 7b14acf3629944f4a20ab4f509fbae7f58de98e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36728
This diff refactors the creation and visibility of IntBufferBatchMountItem
This is not a breaking compatibility change because nobody should be using this class
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D44115916
fbshipit-source-id: f0b0464483cafe55ffaf661b18c692be0df41199
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36606
This diff refactors the preallocation of views to minimize visibility of PreAllocateViewMountItem
this is not a backward compatible change because nobody should be using this class
Changelog: [Internal] Internal
Reviewed By: javache
Differential Revision: D44115487
fbshipit-source-id: 2d00f9f5edbe0517c3c5fcef94290180fa418fb3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36607
In this I'm refactoring the creation of SendAccessibilityEventMountItem to reduce visibility of classes
Changelog: [Internal] Internal
Reviewed By: javache
Differential Revision: D44115052
fbshipit-source-id: 021f59a65aed152324a13947609e23c0191ca0e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36605
This diff introduces the class MountItemFactory that will be used to create MountItems in Fabric.
The purpose of this refactor is to reduce visibility for custom implementations of MountItems
This should not be a breaking change, because nobody should be using these classes
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D44115053
fbshipit-source-id: a62d0a42239d29380aa10d5eab428af90c313d00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36603
Small refactor to log state data during development for preallocation of items
Changelog: [Internal] Internal
Reviewed By: javache
Differential Revision: D44112419
fbshipit-source-id: 290fbf0db3ea3f9863e7c86249dd1e6943556baa
Summary:
Changelog: [Internal]
Publishing to check CI if bumping and aligning in the same commit will work, since these new versions are not available on npm yet, but maybe our new monorepo setup will resolve this
**Adding back `react-native/virtualized-lists` as a workspace to `xplat/js` so that it won't be resolved from npm**
#publish-packages-to-npm
Pull Request resolved: https://github.com/facebook/react-native/pull/36556
Reviewed By: cipolleschi
Differential Revision: D44255353
Pulled By: hoxyq
fbshipit-source-id: 21372487d6e9c0b2382b7cd9af835beed46b8ce1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36711
Changelog: [Internal]
minimizing callsites to the react context, which has turned into a bloated toolbox class
Reviewed By: javache
Differential Revision: D44493500
fbshipit-source-id: 7272b18af96103dee3658d151fd8e9f03846bd09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36602
This diff refactors and reduces visibility of the legacy class FabricComponents. This should not be a breaking change because nobody should be using it (there is no purpose to be used externally)
changelog: [internal] internal change on the APIs
Reviewed By: javache
Differential Revision: D44112418
fbshipit-source-id: 5608d682ca4fddb8e50db82ff23668fd82dccfb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36724
Similarly to iOS, this adds some examples of direct manipulation on Android using
all the various methods.
Changelog:
[Internal] [Changed] - Add examples of Direct Manipulation in Fabric Intrerop
Reviewed By: cipolleschi
Differential Revision: D44541437
fbshipit-source-id: b6e10ac0a815f41ff3c980236b7d8c6937e92065
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36725
This diff adds an example of using `dispatchViewManagerCommand` for the Fabric Intreop on Android.
Changelog:
[Android] [Added] - Add example for dispatchViewManagerCommand on Fabric Interop
Reviewed By: cipolleschi
Differential Revision: D44540951
fbshipit-source-id: 85bc65ad0eb3a951fbb37d61ca26532ec3cc53b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36623
Changelog:
[General][Changed] - The default `metro.config.js` in apps now extends `react-native/metro-config`, and should be updated in existing apps.
~~`react-native/rn-get-polyfills.js` is removed and should be updated to `react-native/js-polyfills` in existing apps (this is part of the new default config).~~
#publish-packages-to-npm
## Context
### React Native Metro config → React Native repo (https://github.com/facebook/react-native/pull/36502)
We (the React Native team) are aiming to relocate the default Metro config for React Native out of `react-native-community/cli-plugin-metro` and **into the React Native repo + app template** as a new `react-native/metro-config` package.
This is the first (and minimum viable) phase we can ship to separate the release process of Metro from RN CLI in order to reduce coupling and iterate faster for our users.
**See full motivation, design, and test plan (which previewed the CLI bump) here: https://github.com/facebook/react-native/pull/36502**
## Changes
NOTE: This PR is pending the inclusion of a bump to `react-native-community/cli`, and will be sequenced after https://github.com/react-native-community/cli/pull/1875 is merged.
- Upgrade `react-native-community/cli` to `11.0.0`, upgrade all `metro` packages to `0.76.0` (version distributed in this CLI release).
- Update the `metro.config.js` file in `packages/react-native/template/`.
- Now merges defaults from `react-native/metro-config`, and can be used with CLI >= 11.0.0.
- Update the `metro.config.js` files for `packages/react-native/` and `packages/rn-tester/` (these are integration test locations).
- Now merges defaults from `react-native/metro-config`, and can be used with CLI >= 11.0.0.
Changes to `react-native/metro-config` — `0.72.1` (prepared but not depended on yet):
- Export `mergeConfig` util (removing direct `metro-config` dependency in consuming projects).
- Explicitly depend on `metro-react-native-babel-transformer` and `metro-runtime` (transitively included today).
Reviewed By: cortinico, blakef
Differential Revision: D44099691
fbshipit-source-id: 405635dd69fd50a1e9548279eaeda3c932b5b167
Summary:
`setJSEngineResolutionAlgorithm` is marked as private while it looks like it was intended to be public.
While the current implementation does not cause any issues as such, but in brownfield we will have the option to explicitly set the JS engine to hermes or jsc when initialising the ReactInstanceBuilder.
Right now, we look if the engine is set and if unset we look for the jsc engine. If jsc is not present we select hermes and this process unnecessary throws a warning.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID][FIXED] - Changed the scope of `setJSEngineResolutionAlgorithm` to public from private. Brownfield apps should be able to setup the JSResolutionAlgorithm before hand.
Pull Request resolved: https://github.com/facebook/react-native/pull/36715
Reviewed By: cortinico
Differential Revision: D44535444
Pulled By: javache
fbshipit-source-id: ae91e50de10c993c80ed4bba6f2fece64af178c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36717
After D43711737 landed, it turns out that Fabric is always disabled for both
RN-Tester and new app from template (so for 0.72 also RC0).
The reason is that a new method `createRootView(Bundle)` was introduced inside
`ReactActivityDelegate`. Both RN Tester and the template were using the
old `createRootView()` method which is not called anymore at this stage
(should potentially be deprecated?).
This diff fixes it by overriding both method inside `DefaultReactActivityDelegate`
so that both methods are setting the Fabric renderer.
Changelog:
[Android] [Fixed] - Re-enable Fabric in the default app template/RN-Tester
Reviewed By: cipolleschi
Differential Revision: D44536222
fbshipit-source-id: d22a0c522f011a8fe4d27b5d8f2fcf5dd13c3058
