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
Summary:
[Codegen 81] This PR expands the `emitCommonTypes` function adding support for the remaining basic types and adding
a `convertKeywordToTypeannotation` function to the codegen Parser class and implementing it in the Flow and TypeScript parsers as requested on https://github.com/facebook/react-native/issues/34872
## Changelog:
[Internal] [Added] - Expand Codegen emitCommonTypes function adding the remaining basic types
Pull Request resolved: https://github.com/facebook/react-native/pull/36706
Test Plan: Run `yarn jest react-native-codegen` and ensure CI is green
Reviewed By: christophpurrer
Differential Revision: D44504571
Pulled By: cipolleschi
fbshipit-source-id: 220d9bc0cc39614002a67dafd626e5a4878a1447
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36610
This change add to RNTester examples of a legacy Native Component, loaded in the New Architecture through the Interop Layer, that uses the APIs described in the [Direct Manipulation](https://reactnative.dev/docs/direct-manipulation) sectioon of the website.
## Changelog:
[iOS][Added] - Added examples of direct manipulation
Reviewed By: sammy-SC
Differential Revision: D43978674
fbshipit-source-id: 1cbc56f28034f84f309166e3e392ad97a8164e64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36578
This change brings to the Fabric Interop Layer the possibility to directly call native methods on the View Manager, something that was not possible before and that we can use to simplify the migration to the New Architecture.
## Changelog:
[iOS][Added] - Native Components can now call native methods in Fabric when they are loaded through the Interop Layer
Reviewed By: sammy-SC
Differential Revision: D43945278
fbshipit-source-id: fe67ac85a5d0db3747105f56700d1dbba7ada5f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36704
Following up to #36696, I accidentally failed a rebase and had files
commited on the wrong folder. I'm updating them here to use `packages/react-native/template`.
Changelog:
[Internal] [Changed] - Move from from accidental template/ folder on root
Reviewed By: cipolleschi
Differential Revision: D44502966
fbshipit-source-id: d408f38884444c4ecc03852b1d145bf2e89df672
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36673
Changelog: [Android][Deprecated]
in this change, we deprecate ReactModuleWithSpec because it can be replaced with the TurboModule interface which better describes our generated modules.
Reviewed By: cortinico
Differential Revision: D44450959
fbshipit-source-id: adab192593843926f35bdbeb346ef374dd80e615
Summary:
Recently, we changed the logic to verify the body of a PR so that it is more compatible internally and externally, in both ways. But we forgot to update the template, so right
now, all the created PR are incompatible with the internal PR checker.
The required change is to have `:` after the Changelog title.
For consistency, I added the `:` after ALL the titles.
## Changelog:
[Internal] - Changed the PR template to align it to the new rules
Pull Request resolved: https://github.com/facebook/react-native/pull/36705
Test Plan: No danger errors nor internal linter errors
Reviewed By: christophpurrer
Differential Revision: D44503519
Pulled By: cipolleschi
fbshipit-source-id: 43963c3cf774d19d6de8e86b18b684e76dd0fe87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36699
Changelog: [internal]
This fixes a crash introduced in D43692171 where `jsi::Pointer` outlives `jsi::Runtime` in which it was created. This leads to a crash.
The diff changed ownership model, retaining `TextLayoutManager` strongly from `ParagraphState`.
To resolve this, in this diff we change how `StateWrapperImpl` owns state, moving from shared_ptr to weak_ptr. We have tried to do it previously in D26815275 but it had to be reverted because it broke end to end tests. I made sure the tests are fine. However it is the right ownership model. Java objects should not strongly hold onto anything in ShadowTree. If ShadowTree is destroyed, Java calls should noop, not keep objects in memory and have them handle the case when runtime was destroyed.
jest_e2e[run_all_tests]
Reviewed By: cipolleschi
Differential Revision: D44472121
fbshipit-source-id: 83b79329440ac1211902ea9511c0dde9a77ab9e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36702
With the monorepo changes we broke the build from source for users.
This fixes it so that folks can just follow the guide:
https://reactnative.dev/contributing/how-to-build-from-source
Changelog:
[Android] [Fixed] - Fix the setup to allow the build-from-source on host projects
Reviewed By: cipolleschi
Differential Revision: D44502428
fbshipit-source-id: 3ad8fb114f5e2f7ffdf6fffa617ceaa45334f5f3
Summary:
Adds changelog for new patch.
## 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.5
Pull Request resolved: https://github.com/facebook/react-native/pull/36698
Test Plan: N/A
Reviewed By: christophpurrer
Differential Revision: D44502179
Pulled By: cipolleschi
fbshipit-source-id: fe0470ccc067966af3a98e6959702ca26c7af6db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36696
As the title says, we're converting the new app template to Kotlin.
This will reduce the template size and make it more aligned to market standards.
Changelog:
[Android] [Changed] - Convert the app template to Kotlin
Reviewed By: mdvacca
Differential Revision: D44142081
fbshipit-source-id: 6111360b6580460eba0341e47c55704cc673e444
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36692
Similar to the iOS counterpart,
this changes adds an example to RNTester to verify that the Interop Layer can process bubbling events in Fabric as it used to do in Paper.
Changelog:
[Internal] [Changed] - Add Fabric Interop event example
Reviewed By: cipolleschi
Differential Revision: D44467555
fbshipit-source-id: 1f1af27583c402641c549bc2926a64469dcd7b3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36693
Similar to #36417, this changes adds an example to RNTester to verify that the Interop Layer can process constants in Fabric as it used to do in Paper for Android.
Changelog:
[Android] [Added] - Add Fabric Interop constants example
Reviewed By: cipolleschi
Differential Revision: D44466391
fbshipit-source-id: 74e654319b93e60b415297dcdddc98eb100913df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36672
Changelog: [Internal]
if we look at usages of ReactModuleWithSpec, we see that it's existence was to simply identify generated native modules since the inheritance graph of native modules was different if they were generated.
this was introduced before we created the TurboModule interface, which all codegenned native modules also conform to. since that exists now, there's no need for both of these. this is the only callsite in our code where ReactModuleWithSpec triggers any logic, so i'm updating it.
bypass-github-export-checks
Reviewed By: javache
Differential Revision: D44450687
fbshipit-source-id: f9c26fce8e360b6e319153aad83fc788079bac91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36671
Changelog: [Internal]
BaseJavaModuleTest tests the reflection of the native module methods wrapped by the JavaModuleWrapper abstraction, this abstraction is used by JNI in the C++ layer.
however, though we already have logic that supports the reflection of our codegenned modules (turbomodules), we didn't have a test for it yet, so i'm adding it in this change.
Reviewed By: javache, cortinico
Differential Revision: D44450433
fbshipit-source-id: 44abcf188d4b0559c684a95b058bd55e082b5531
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36614
Changelog: [Internal] - Ensure Pressability doesn't forward onClick to onPress when it receives a click via pointer events.
This is a better version of D43128801 which ensures that click events which are triggered by the new pointer events event emitter don't trigger onPress in Pressability — avoiding the double onPress issue while ensuring all existing usecases of onClick continue to work.
Reviewed By: yungsters
Differential Revision: D44031433
fbshipit-source-id: 5ecdd132f7f91338c5a3632c05510f96495b512e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36670
Changelog: [Internal]
so powermock doesn't have compatibility with JDK 18 (not sure what RN is on), but regardless my understanding is that we should be moving away from powermock since it's not maintained anymore.
this test was disabled because of that so this should allow it to run again.
Reviewed By: javache, cortinico
Differential Revision: D44445586
fbshipit-source-id: f9cabe80332a9ef11df690ac2af20bd60bb61641
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36687
## Changelog:
This apparently fell into the cracks during the recent (awesome! :)) monorepo migration, as the result the tests set for `WebPerformance` became empty.
Reviewed By: hoxyq
Differential Revision: D44466070
fbshipit-source-id: b13a696e73b18823f975946e8bc2e99d800d8891
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36686
After the recent changes of Metro and Metro-Config, we need to update the path used to load the bundle in RNTester
## Changelog:
[General][Fixed] - Use the right path to load RNTester bundle
Reviewed By: cortinico
Differential Revision: D44465418
fbshipit-source-id: 96170194579792f9a5d8a141328d43e45a4db973
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36681
This change is needed to add some E2E tests on the Hermes repo so that we can test Hermes against iOS other than android.
## Changelog:
[Internal][Added] - Add possibility to download Hermes from a specific commit
Reviewed By: cortinico
Differential Revision: D44460479
fbshipit-source-id: 89c196aa7c38533e4904444f7f17eb3236fc6356
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36677
## Changelog:
[Internal] - Don't cache UIManager type inside the Event data structure
A follow up to https://github.com/facebook/react-native/pull/36659
It's redundant, and it's good to have fewer "sources of truth" and keep the notion of UIManagerType separate from Event data structures.
Reviewed By: javache
Differential Revision: D44453812
fbshipit-source-id: 4efc0bb115bb4750e27afb2390afc9736ae67469
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36682
## Changelog:
[Internal][Fix] - Fix hashing function in event name mapping in PerformanceEntryReporter
A textbook mistake, when mapping event names via the constant lookup table, only the first 8 characters were effectively taken into account, thus mixing names of some events.
Reviewed By: rubennorte
Differential Revision: D44462195
fbshipit-source-id: 273891d92251014661af731618d8a549627b2983
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36669
The test: Route all TurboModules in Fb4a through the interop layer.
So now, instead of using the C++ codegen for method dispatch, TurboModules will instead be using JavaInteropTurboModule, which uses the ReactMethod annotations for method dispatch.
MobileConfig actualization diff: D44405316.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D44405336
fbshipit-source-id: 3b00028e26cdcd229e64630eef73409a3264636a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36667
## Context
TurboModuleManagerDelegate exposes two methods that create TurboModules:
- TurboModule getModule()
- CxxModuleWrapper getLegacyCxxModule()
## Problem
TurboModuleManagerDelegate.getLegacyCxxModule() is redundant: getModule() could just return all the modules that getLegacyCxxModule() returns: getLegacyCxxModule returns modules that implement TurboModule.
## Changes
So, let's deprecate getLegacyCxxModule(). This will simplify the implementation of TurboModuleManager.
Changelog: [Android][Deprecated] - Deprecate TurboModuleManager.getLegacyCxxModule
Reviewed By: cortinico
Differential Revision: D44407802
fbshipit-source-id: 88a6cf6597db76d8a74fd777d68ccf4f43aa6811
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36629
The scope of TurboModuleManager is increasing:
- Eventually, it'll be capable of creating interop NativeModules (i.e: NativeModules that don't implement TurboModule).
So, instead of creating duplicate methods for NativeModules on the TurboModuleManager, this diff changes the APIs of TurboModuleManager to work with the NativeModule interface.
Thoughts?
## Questions
**Question:** Is this a breaking change for open source?
- Technically, yes. This diff changes the public interface of TurboModuleManager.
**Question:** How large of a thrash will this cause for open source apps?
- The thrash should be minimal. People in open source shouldn't be creating their own TurboModuleManager. They also shouldn't be directly accessing the TurboModuleManager object either.
**Question:** Is this change safe?
- Yeah. All the code that calls into TurboModuleRegistry converts TurboModules it returns into NativeModules.
**Question:** Is this change move us in the right direction?
- Long term, the TurboModule system will support legacy modules as well as TurboModules.
- I think it makes a lot of sense to have one Java-facing registry: after all, Java will just treat these NativeModules/TurboModules as regular Java objects, and call public methods on them. It doesn't care if the module is TurboModule-compatible or not.
- As for the TurboModuleRegistry abstraction, I think we should eventually rename this to NativeModuleRegistry after we delete the current NativeModuleRegistry.
- Still thinking about this though. I will leave this diff in review to welcome comments.
Changelog: [Android][Deprecated] - Deprecate TurboModuleRegistry.getModule(), getModules(), hasModule(),
Reviewed By: mdvacca
Differential Revision: D43801531
fbshipit-source-id: 4af7cbc2e2dc7c1d664acbd38c83aa93aae23c9f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36628
The legacy NativeModule system supports integer and float in NativeModule method arguments and returns. This diff extends the TurboModule system for the same functionality. T
his is necessary because the TurboModule system will now need to dispatch method calls to legacy NativeModules.
NOTE: We can't actually test these changes until we run interop modules.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D44000389
fbshipit-source-id: 92282d582a0f98fcb88d83e460d4860a64fe1117