Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37459
changelog: [internal]
Let's try to dissable manual `[CATransaction commit]`. This may reduce UI thrash in case several Fabric transactions are committed within single UIRunLoop tick.
While working on [the new architecture benchmarks](https://github.com/reactwg/react-native-new-architecture/discussions/123), with the help of instrumentation I noticed two paints on some occasions. This was happening around 50% of the time I executed a scenario. It dropped the rendering time on 5k of <Text /> from ~800ms down to ~600ms.
Also, the original reason why `[CATransaction commit]` was added has passed. It was added to make Screenshot tests less flaky but we no longer use screenshot tests.
Reviewed By: javache
Differential Revision: D45870408
fbshipit-source-id: 23112c2d92451aba40ad770ffd34f4d5f0ea585f
Summary:
[Codegen 104] This PR introduces `getResolvedTypeAnnotation` to the Parser class and implements this function in Typescript and Flow Parsers.
We also get rid of usages `resolveTypeAnnotation` from :
- `packages/react-native-codegen/src/parsers/typescript/utils.js`
- `packages/react-native-codegen/src/parsers/flow/utils.js`
and replace it with `parsers.getResolvedTypeAnnotation` as requested on https://github.com/facebook/react-native/issues/34872
bypass-github-export-checks
## Changelog:
[Internal] [Changed] - Add `getResolvedTypeAnnotation ` to Parsers and update usages.
Pull Request resolved: https://github.com/facebook/react-native/pull/37373
Test Plan: Run yarn jest react-native-codegen and ensure CI is green
Reviewed By: dmytrorykun
Differential Revision: D45865651
Pulled By: cipolleschi
fbshipit-source-id: fdce6e5059306ebe67121aa1b212e67de864bf84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37362
Changelog: [Internal]
this class should not be instantiated without its dependencies
Reviewed By: RSNara
Differential Revision: D45747779
fbshipit-source-id: ac2869858ad0ee67fbf9c04c58ff0a2bdf98c224
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37444
Changelog: [Internal]
In this change, I'm removing these public notification strings that are used to listen to CMD + R reload by replacing them with a more general, lifecycle callback. Consumers can use this if there's anything in userland that they need to do once React is ready, such as doing some work with any native modules.
Reviewed By: sammy-SC
Differential Revision: D45760847
fbshipit-source-id: 2601ce083df827f79ea3f888f13fff1fc53c9564
Summary:
## Summary
Initially reported in https://github.com/facebook/react/issues/26797.
Was not able to reproduce the exact same problem, but found this case:
1. Open corresponding codepen from the issue in debug mode
2. Open components tab of the extension
3. Refresh the page
Received multiple errors:
- Warning in the Console tab: Invalid renderer id "2".
- Error in the Components tab: Uncaught Error: Cannot add node "3"
because a node with that id is already in the Store.
This problem has occurred after landing a fix in
https://github.com/facebook/react/pull/26779. Looks like Chrome is
keeping the injected scripts (the backend in this case) and we start
backend twice.
DiffTrain build for commit https://github.com/facebook/react/commit/67a05d03e38b9837e27c9fe0a673557e63ff03c5.
Reviewed By: javache
Differential Revision: D45815160
Pulled By: hoxyq
fbshipit-source-id: 99f3c45009b07a0fb89f0674ccfb24f170cdb29d
Summary:
For these values we're not using dynamic values. We can statically
compile in the values we're running.
DiffTrain build for commit https://github.com/facebook/react/commit/df12d7eac40c87bd5fdde0aa5a739bce9e7dce27.
Reviewed By: tyao1
Differential Revision: D45751304
Pulled By: kassens
fbshipit-source-id: d00e441ab75bf8fe038bb0e80eeb392421344657
Summary:
When I was renaming the next channel to canary, I updated the
`publish_preleases` workflow correctly, but I skipped over
`publish_preleases_nightly`. Oops.
DiffTrain build for commit https://github.com/facebook/react/commit/7cd98ef2bcbc10f164f778bade86a4daeb821011.
Reviewed By: mofeiZ
Differential Revision: D45720403
fbshipit-source-id: 13ab5d0d0af6cc899944507249b39b03adbcb994
Summary:
The idea is that the default `yarn test` command should be the one that
includes the most bleeding edge features, because during development you
probably want as many features enabled as possible.
That used to be `www-modern` but nowadays it's `experimental` because
we've landed a bunch of async actions stuff in experimental but it isn't
yet being tested at Meta.
So this switches the default to `experimental`.
DiffTrain build for commit https://github.com/facebook/react/commit/b5810163e913e8c95a7a0a6dee039bc102e3c987.
Reviewed By: mofeiZ
Differential Revision: D45719891
fbshipit-source-id: 7c820b8b546f1c90bb3d77993befde86e42d399b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37349
X-link: https://github.com/facebook/yoga/pull/1288
Fixes https://github.com/facebook/yoga/issues/1283
New versions of CMake add "policies" which control how the build system acts wrt breaking changes. By default, CMake will emulate the behavior of the version specified in `cmake_minimum_required`.
Setting a policy to true (to opt into new behavior where `cmake_minimum_required` is lower than the current version) seems actually just error out on the old versions.
Googling around, apparently the way I should be doing this is to specify `<policy_max>` as part of `cmake_minimum_required `. https://gitlab.kitware.com/cmake/cmake/-/issues/20392
This should I think use new policies introduced up to 3.26 (what we test on right now), while letting 3.13 be the minimum.
Reviewed By: cortinico
Differential Revision: D45724864
fbshipit-source-id: 120cc2015a043605e7c07ef0459667643a4284b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37441
Changelog: [Internal]
i just noticed that `[_delegate createContextContainer]` can be null because it returns `shared_ptr`, we should protect against that!
Reviewed By: javache
Differential Revision: D45805196
fbshipit-source-id: 645815812da1718e1025c7e6b2763e698d86b59a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37442
Changelog: [Internal]
this better describes what's going on and is more standard obj-c
Reviewed By: javache
Differential Revision: D45805034
fbshipit-source-id: d8e5938c856f356ce96a3f6d393eaddbb02aa555
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37396
Pull Request resolved: https://github.com/facebook/react-native/pull/37368
## Changes
This diff hooks up global.nativeModuleProxy to the TurboModule interop layer.
Now, when you call NativeModules.Foo, the TurboModule system will create the Foo legacy module, and return it to JavaScript.
## Example
global.nativeModuleProxy.Foo:
- ObjC++: Use RCTTurboModuleManager to create the ObjC legacy module for Foo
- C++: Use the ObjC legacy modules to create and return a ObjCInteropTurboModule object to JavaScript.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D45781152
fbshipit-source-id: 9059cd0de294aa17dcbf120322d7e86e7c7a83ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37395
Pull Request resolved: https://github.com/facebook/react-native/pull/37364
When the TurboModule interop layer is enabled, it should create modules that conform to RCTBridgeModule (i.e: legacy and turbo modules).
When the TurboModule interop layer is disabled, it should only create modules that conform to RCTTurboModule (i.e: turbo modules).
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D45781155
fbshipit-source-id: 2bf2c6cdbe0db99a57fce0d0c21c66aee3465e0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37391
This was accidentally set to true by default.
This resulted in the TurboModule interop layer being enabled on Standalone apps.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D45783832
fbshipit-source-id: e88f2bc8cba06356b9caab2ba25bcdd9da82b37e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37415
Previously, when focusing on an unchecked checkbox in React Native Paper with VoiceOver, it was announcing as "not selected". iOS voiceover uses "unselected" instead ("not selected" is used on Android Talkback). Update code to use "unselected".
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D45799922
fbshipit-source-id: 30f7813ed9f1fdad817e18b28c4fcf99cb4b884f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37414
Previously, when focusing on a checkbox or radio button in React Native Fabric with VoiceOver, it wasn't announcing the role, e.g. "checkbox". Instead it would just say [label][state], e.g. "Automatically check for updates, unchecked". This is an extremely confusing experience for screen reader users because they don't know what kind of element they are focusing, including how to interact with it.
"checkbox" and "radio button" aren't recognized as [Apple iOS traits](https://developer.apple.com/documentation/uikit/uiaccessibilitytraits?language=objc), but we'd like to have consistency with the mobile safari experience.
Reviewed By: cipolleschi
Differential Revision: D45797554
fbshipit-source-id: 418e73342aaa8d0986e330bfd54078be27d3491f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37272
This change enables some tests on RNTester and on the Template to verify that we won't be breaking `use_frameworks!` again in the future.
## Changelog:
[iOS][Added] - Add tests to check use frameworks with dynamic linking.
Reviewed By: cortinico
Differential Revision: D45605977
fbshipit-source-id: 06f05aba427e78a7bb1d8dc835fa83d8550586db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37273
When using dynamic frameworks, we can't rely on Codegen to register all the components into the renderer. That's because, we would have to codegen a new target, which depends on ALL the 3rd party dependencies that expose a UI component.
The previous PR adds support for distributed automatic registration when components are loaded in memory.
However, not to slow down the adoption of the New Architecture, there could be apps that need to register a component that does not support the distributed approach yet. Thanks to this method, apps can register those components.
## Changelog:
[iOS][Added] - Added a mechanism to register components into the renderer from the user app.
Reviewed By: dmytrorykun
Differential Revision: D45605688
fbshipit-source-id: 3583913f2700be4d6cb33a862429486aca675acf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37274
With dynamic frameworks, we can't use floating C functions.
The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies.
Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building.
The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded.
**This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks.
This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a
```
+ (void)load
{
[super load];
}
```
method in their ComponentView.
Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules.
## Changelog:
[iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries.
Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual.
Reviewed By: dmytrorykun
Differential Revision: D45605441
fbshipit-source-id: e609fbf6f92fddfbaa676227fde60962d6b0faa4
Summary:
Fix the logic error when setPadding int ReactTextView.
## 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
Pull Request resolved: https://github.com/facebook/react-native/pull/36999
Reviewed By: NickGerleman
Differential Revision: D45773288
Pulled By: javache
fbshipit-source-id: ed4681aeab58ed4c3d2e04edb2d096b50932c088
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37306
### Stack
ARIA roles in React Native are implemented on top of accessibilityRole. This is lossy because there are many more ARIA roles than accessibilityRole. This is especially true for RN on desktop where accessibilityRole was designed around accessibility APIs only available on mobile.
This series of changes aims to change this implementation to instead pass the ARIA role to native, alongside any existing accessibilityRole. This gives the platform more control in exactly how to map an ARIA role to native behavior.
As an example, this would allow mapping any ARIA role to AutomationControlType on Windows without needing to fork to add new options to accessibilityRole.
It also allows greater implementation flexibility for other platforms down the line, but for now, iOS and Android behave the same as before (though with their implementation living in native).
### Diff
This replicates the roles to Java. When using MapBuffer we pass the role by ordinal, assuming they keep in sync. We otherwise still pass by string matching the JS side.
Previous implementation kept `accessibilityRole` on a view tag of the native view. This adds `role` as a view tag as well.
For now, to reuse the existing code, we then expose a single function to query `AccessibilityRole` from the combined view tags. This will do the same mapping previously done in JS, so that any code previously reading for an `AccessibilityRole` will now get one derived from the role view tag if present.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D45431381
fbshipit-source-id: a72c7880d41b5cf2c4e1c1f3ebfa6832ce8b4250
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37305
### Stack
ARIA roles in React Native are implemented on top of `accessibilityRole`. This is lossy because there are many more ARIA roles than `accessibilityRole`. This is especially true for RN on desktop where `accessibilityRole` was designed around accessibility APIs only available on mobile.
This series of changes aims to change this implementation to instead pass the ARIA role to native, alongside any existing `accessibilityRole`. This gives the platform more control in exactly how to map an ARIA role to native behavior.
As an example, this would allow mapping any ARIA role to [`AutomationControlType`](https://learn.microsoft.com/en-us/dotnet/api/system.windows.automation.peers.automationcontroltype?view=windowsdesktop-7.0&viewFallbackFrom=dotnet-uwp-10.0) on Windows without needing to fork to add new options to `accessibilityRole`.
It also allows greater implementation flexibility for other platforms down the line, but for now, iOS and Android behave the same as before (though with their implementation living in native).
### Diff
This syncs the Fabric representations of Roles to the current state of the world in JS, and adds usage to the view configs.
1. `Role` enum for the View `role` prop (ARIA role)
2. Sync enums and conversions to JS `AccessibilityRole`
1. This parsing is done for `TextAttributes` only. `View` uses the string directly
2. Add ARIA roles, and parse those to their enum form.
3. Move enums from attributedstring primitves to accessibility primitives
3. Add to viewconfig to allow it to be passed
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D45431372
fbshipit-source-id: 0150538345bbb6cb4d9426c4eebd0f67c2a33f3d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37377
For 0.72 I enabled `moduleResolution: "nodenext"` which allows some package exports support, but this is imperfect. E.g. RN will typecheck against the `node` condition and there are some more restrictions than we need.
D45720238 bumped TypeScript to 5.0 for RN 0.73, along with D45721088 which brought the tsconfig inline. This lets us switch to the new [`moduleResolution: "bundler"`](https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#moduleresolution-bundler) and instructs `tsc` to follow the `react-native` export condition.
See even more context at: https://github.com/microsoft/TypeScript/pull/51669
Changelog:
[General][Added] - Better TypeScript support for package.json exports field
Reviewed By: christophpurrer
Differential Revision: D45769740
fbshipit-source-id: 1ad450b8157bfd0d539289835bed097fd950cf78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37422
Changelog: [Internal]
in this simple change, i renamed the `preload` API, which triggers all the rct instance / javascript runtime creation to `start`. `preload` is a confusing API on the host because the host should be agnostic of when the timing to create its dependencies are, and the consumer should determine when initialization is lazy, early, etc.
Reviewed By: cipolleschi
Differential Revision: D45760583
fbshipit-source-id: bea26d21f950474352280292426a5facbe52b60f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37327
Changelog: [Internal]
in this diff, we enforce at the API level that the `RCTHostDelegate` is not responsible for creating the js engine instance.
Reviewed By: cipolleschi
Differential Revision: D45596321
fbshipit-source-id: 7862344d8b42e9d70e7fb7c7e9980953f0d66a8b
Summary:
The core implementation for ShadowNode's `getDebugProps` lives in ConcreteViewShadowNode, but is not actually specific to that class. Additionally, `LayoutableShadowNode` overrides `getDebugProps` in a way that doesn't concat props from its base class. Instead, override the method properly so we only need the implementation in `LayoutableShadowNode`.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D45729105
fbshipit-source-id: 946d8d97b86fde0488527ce00db5a019c95e31af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37328
Changelog: [Internal]
in this diff, i introduced a C function to be used to create RCTHost that obfuscates away all the C++ arguments. i expect this to be the API that the vast majority of the community will use to create `RCTHost`.
Reviewed By: cipolleschi
Differential Revision: D45678970
fbshipit-source-id: e3479db1bb68d93b3ee2f02598413d2080bb5ea9
Adam Cmiel
Samuel Susla
Antoine Doubovetzky
Kyaw Thura
shubham0142
tarunrajput
Siddarth Kumar
Philip Heinser
Phillip Pan
Luna Wei
javache (Meta Employee)
hoxyq (Meta Employee)
kassens (Meta Employee)
acdlite
Pieter De Baets
Nick Gerleman
Ramanpreet Nara
Patryk Ozga
Carmen Krol
Riccardo Cipolleschi
jcdhlzq
Intl Scheduler
Junfeng Li
Pieter Vanderwerff
