Summary:
updated type for activeThumbColor prop for Switch component
To help community users with all possible properties
## 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
--> GENERAL CHANGED - added new prop in type of switch component
Pull Request resolved: https://github.com/facebook/react-native/pull/38636
Reviewed By: cortinico
Differential Revision: D47800523
Pulled By: lunaleaps
fbshipit-source-id: 25b22a97a3c02ad01c8100fdd1f3e808f296c14c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38759
As part of refactoring the `ReactSurface`, moving the `SurfaceHandler` interface to `react.interfaces.fabric`.
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D48006184
fbshipit-source-id: 09297fccc2b405a5e807d35bfa9eb2a9a4c52a16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38756
In order to expose getSurfaceHandler() from an interface ReactSurface we need this to be public. All methods in an interface are public and the implementing class can not have a restricted visibility than the interface.
Reviewed By: christophpurrer
Differential Revision: D48003816
fbshipit-source-id: 7f0d0bd91cc9cde9c2430fd8dcde7a94966fd217
Summary:
This PR aims to fix an issue where installing iOS pods from a different directory causes the `hermes-engine` `:tag:` not to be properly resolved.
Ever since https://github.com/facebook/react-native/issues/37148 was merged, the `setup_hermes` script tries to resolve the `node_modules/react-native/sdks/.hermesversion` file and use its content to generate the pod tag, in order to verify when it changes over time.
This works perfectly when installing pods within the `ios` folder, as the `react_native_path` should point to the correct relative folder (`../node_modules/react-native` by default).
However, when installing pods from a different directory (the project root, for example) and leveraging the `--project-directory` flag, the file fails to resolve, as the current working directory is considered when resolving the `.hermesversion` file.
### Quick Example:
- `react_native_path`: `../node_modules/react-native` (the default config)
**Installing pods from the `ios` folder:**
- `cd ios`
- `bundle exec pod install`
- `hermestag_file` resolved path: `$project_root/node_modules/react-native` ✅
- `hermes-engine` `:tag:`: `hermes-2023-03-20-RNv0.72.0-49794cfc7c81fb8f69fd60c3bbf85a7480cc5a77` ✅
**Installing pods from the `$project_root` folder**
- `bundle exec pod install --project-directory=ios`
- `hermestag_file` resolved path: `$parent_folder/$project_root/node_modules/react-native` ❌
- `hermes-engine` `:tag:`: `''` ❌
### The fix
Turns out that the same file had a resolved reference to the `react-native` folder, assigned to the `react_native_dir` variable:
```ruby
react_native_dir = Pod::Config.instance.installation_root.join(react_native_path)
```
By resolving the `.hermesversion` using that folder, we guarantee that the relative path will always reference the directory where the `Podfile` is defined, which is the expected behaviour.
## Changelog:
[Internal] - Fix an issue where installing pods from a different directory would fail to resolve `hermes-engine` tags correctly.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/38754
Test Plan:
- Init a new `react-native` repo
- Remove the generated `Podfile.lock` file
- Navigate to the project root folder
- `bundle exec pod install -project-directory=ios`
- Check that the `hermes-engine` entry has a properly populated `:tag:` attribute:
**Before:**
```
hermes-engine:
:podspec: "../node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec"
:tag: ''
```
**After:**
```
hermes-engine:
:podspec: "../node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec"
:tag: hermes-2023-03-20-RNv0.72.0-49794cfc7c81fb8f69fd60c3bbf85a7480cc5a77
```
Reviewed By: cortinico
Differential Revision: D48029413
Pulled By: cipolleschi
fbshipit-source-id: 82d465abd5c888eeb9eacd32858fa4ecf4f8c217
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38718
> NOTE: Replaces https://github.com/facebook/react-native/pull/38240
## Context
RFC: Decoupling Flipper from React Native core: https://github.com/react-native-community/discussions-and-proposals/pull/641
## Changes
To support incoming new React Native packages around debugging (including migrating over [`react-native-community/cli-plugin-metro`](https://github.com/react-native-community/cli/tree/main/packages/cli-plugin-metro)) — which target Node.js and require a build step, this PR adds a minimal shared build setup across the `react-native` monorepo.
The setup is closely inspired/based on the build scripts in Jest, Metro, and React Native CLI — and is a simple set of script wrappers around Babel. These are available as build commands at the root of the repo:
- `yarn build` — Builds all configured packages. Functionally, this:
- Outputs a `dist/` directory with built files.
- Rewrites package.json `"exports"` to update every `./src/*` reference to `./dist/*` (source of truth).
- `scripts/build/babel-register.js` — Allows running all Node.js entry points from source, similar to the current setup in [facebook/metro](https://github.com/facebook/metro). (Example entry point file in this PR: `packages/dev-middleware/src/index.js`)
Build configuration (i.e. Babel config) is shared as a set standard across the monorepo, and **packages are opted-in to requiring a build**, configured in `scripts/build.config.js`.
```
const buildConfig /*: BuildConfig */ = {
// The packages to include for build and their build options
packages: {
'dev-middleware': {target: 'node'},
},
};
```
For now, there is a single `target: 'node'` option — this is necessary as `react-native`, unlike the above other projects, is a repository with packages targeting several runtimes. We may, in future, introduce a build step for other, non-Node, packages — which may be useful for things such as auto-generated TypeScript definitions.
{F1043312771}
**Differences from the Metro setup**
- References (and compiles out) repo-local `scripts/build/babel-register.js` — removing need for an npm-published dependency.
## Current integration points
- **CircleCI** — `yarn build` is added to the `build_npm_package` and `find_and_publish_bumped_packages` jobs.
**New Node.js package(s) are not load bearing quite yet**: There are not yet any built packages added to the dependencies of `packages/react-native/`, so this will be further tested in a later PR (and is actively being done in an internal commit stack).
### Alternative designs
**Per-package config file**
Replace `scripts/build/config.js` with a package-defined key in in `package.json`, similar to Jest's [`publishConfig`](https://github.com/jestjs/jest/blob/1f019afdcdfc54a6664908bb45f343db4e3d0848/packages/jest-cli/package.json#L87C3-L89C4).
```
"buildConfig": {
"type": "node"
},
```
This would be the only customisation required, with a single Babel config still standardised. Another option this might receive in future is `enableTypeScriptCodgeen`.
**Rollup**
More sophisticated build tool for Node.js, used by the React codebase (albeit within a custom script setup as well).
**Lerna and Nx**
- Most sophisticated setup enabling caching and optimised cloud runs.
- Probably the most likely thing we'll move towards at a later stage.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D47760330
fbshipit-source-id: 38ec94708ce3d9946a197d80885781e9707c5841
Summary:
## Changelog:
[Internal] -
This must be some new thing coming from the C++ language service provider (from the VSCode plugins?..), but this keeps popping up since recently as untracked files in the yoga subfolder.
Add it to .gitignore.
Reviewed By: NickGerleman
Differential Revision: D48022954
fbshipit-source-id: dad608f303f3d50b701d776795f6e25f007811b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38765
## Changelog:
[Internal] -
The `RN_DEBUG_STRING_CONVERTIBLE` was interchangeably used via both `#if` and `#ifdef` (the latter being incorrect), which led to both inconsistency, or even the code plain not compiling it `RN_DEBUG_STRING_CONVERTIBLE=0` explicitly.
Furthermore there was no guarantee it's defined, which can generate warnings with `-Wundef`/`-Wall` (or even errors with `-Werror` on top of that).
This fixes all the usages to be uniform and makes sure the flag is defined when it's used to prevent compiler warnings.
Reviewed By: christophpurrer
Differential Revision: D48021565
fbshipit-source-id: 653b6af96bb0361e6f1d62c1b545ec01309760e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38736
`scrollToIndex` relies on cached layout information, so we should cache the results from `onContentSizeChange` before attempting the scroll. Otherwise we will fail to scroll in RTL.
Changelog:
[General][Fixed] Cache ScrollView content length before calling `scrollToIndex`
Reviewed By: lenaic
Differential Revision: D47978635
fbshipit-source-id: 27f2a4702650e8a73e8812128821ca03f36216dd
Summary:
`butter::small_vector` is backed by a `folly:small_vector` on non-Android platforms in release mode.
It uses the small vector optimization, keeping a fixed size buffer, then falling back to heap allocation.
When I was debugging through props parsing code to figure out a prop not getting passed to Fabric (was being filtered in ViewConfig), I noticed this vector is filled with 199 elements for ViewProps. So It always overflows the current capacity and falls back to heap allocation. This bumps the capacity basde on what I observed with some more headroom.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D47981105
fbshipit-source-id: 3870d8e4fee9748c487d01cc82284de865ea370d
Summary:
This PR splits the build of Hermes for iOS in multiple jobs.
Before, we were building all the slices of Hermes serially. So, we were:
- building the hermesc
- building hermes for iPhone
- building hermes for iPhonesimulator
- building hermes for Macos
- building hermes for Catalyst
- packaging the framework
This job was taking up to 45-50 minutes.
The the four slices (iPhone, iPhonesimulator, Macos, Catalyst) can be parallelized to harvest a speedup in execution.
The following tables contains the executions before and after this change.
- Full Clean Build -> Before: 51' 35" | After: 17'33" ( 3x improvement)
| BEFORE | AFTER |
| --- | --- |
| <img width="1164" alt="Screenshot 2023-07-28 at 11 48 24" src="https://github.com/facebook/react-native/assets/11162307/49cc519c-16f0-4868-b847-602b1cb21f3e"> | <img width="1120" alt="Screenshot 2023-07-28 at 11 16 32" src="https://github.com/facebook/react-native/assets/11162307/85034cd7-751e-4056-ae4f-ed09ac8343e8"> |
| Total time (critical path): `build_hermes_macos-Debug` = 51' 35" | Total time (critical path): `build_hermesc_apple` (2' 56") + `build_apple_slices_hermes-Debug-macosx` (9'23") + `build_hermes_macos-Debug` (5'14") = 17'33" |
- Fully Cached Build -> Before: 4'35" | After: 32" ( 9x improvement)
| BEFORE | AFTER |
| --- | --- |
| <img width="497" alt="Screenshot 2023-07-28 at 14 38 12" src="https://github.com/facebook/react-native/assets/11162307/978eba4d-3524-45ab-bfa5-d9cb9ba63df1"> | <img width="1099" alt="Screenshot 2023-07-28 at 16 12 17" src="https://github.com/facebook/react-native/assets/11162307/f2a8f0bb-545c-4d6f-9b81-cda87151bb62"> |
| Total Time (critical path): `build_hermes_macos-Debug` (4'35") | Total Time (critical path): `build_hermesc_apple` (7") + `build_apple_slices_hermes-Debug-macosx` (7") + `build_hermes_macos-Debug` (32") = 46" |
## Changelog:
[Internal] - Split hermes build to speedup CI and Release
Pull Request resolved: https://github.com/facebook/react-native/pull/38619
Test Plan:
- CircleCI stays green
- Hermes artifact still works for RNTester and app from the template
Reviewed By: cortinico, dmytrorykun
Differential Revision: D47896833
Pulled By: cipolleschi
fbshipit-source-id: 3b9e8d5de9b2a6fb6671444fda09d77b96123ac2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38749
changelog: [internal]
# Request for comment
I'll gate this and extend this to TextInput if we think this is appropriate solution.
## Problem
Paragraph and TextInput have custom measure functions. They outsource measurements to the host platform. On Android, this means going through JNI (expensive).
When we architected YogaLayoutableShadowNode, we made intentional decision to dirty those nodes on every clone. This was to lower the complexity.
## Solution
One possible to solution is to just check if children, props or textAttributes have changed. If not, nothing has affected the layout and it is safe to mark the node as clean.
Reviewed By: NickGerleman
Differential Revision: D47914641
fbshipit-source-id: ab448fa18599eb2266984eba9f5d935caad1caed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38748
changelog: [internal]
Android was setting flag `swapLeftAndRightInRTL` to true regardless if the context was RTL or LTR. This causes unnecessary tree traversal + invalidation of all yoga nodes. This is a completely unnecessary work when layout direction is left to right.
To fix this, I made sure Android not longer sets `swapLeftAndRightInRTL` to true and in Fabric we only check the flag for RTL context.
Reviewed By: NickGerleman
Differential Revision: D47913605
fbshipit-source-id: 1d938b0dc9ba16a73b076f626055055162e3495f
Summary:
This job is now unnecessary and we can safely remove it as its work is effectively already
executed by the `test_android` job and is causing us just to spent more CI credits.
Changelog:
[Internal] [Changed] - Remove test_android_docker_image
Reviewed By: cipolleschi
Differential Revision: D47716008
fbshipit-source-id: 68ff2b28da8cfb69e013476f84e903cf3001d5d3
Summary:
This PR is small cleanup in scripts in `rn-tester-e2e` package, it creates unified script so that we can easily pass platform as an argument. Context: https://github.com/facebook/react-native/pull/36267#discussion_r1269378065
## Changelog:
[INTERNAL] [CHANGED] - Unify `test-e2e` command in `rn-tester-e2e` package
Pull Request resolved: https://github.com/facebook/react-native/pull/38701
Test Plan: CI Green ✅
Reviewed By: NickGerleman, cipolleschi
Differential Revision: D47949821
Pulled By: cortinico
fbshipit-source-id: 90bbc96281e89dec505999ff5e51db7ca78da6dc
Summary:
If another pod wants to depend on `React-RCTAppDelegate` and is written in Swift, the user needs to enable modular headers for this pod in the Podfile. This is not very convenient as this cannot be changed as part of the podspec, thus requires additional steps from the user. In Expo, our autolinking just fixes that automatically for all pods that require it (not only for RN's pods).
## Changelog:
[IOS] [CHANGED] - Set DEFINES_MODULE xcconfig in React-RCTAppDelegate to generate a module map for this pod
Pull Request resolved: https://github.com/facebook/react-native/pull/38717
Test Plan:
- rn-tester builds
- `pod install` with a dependency containing Swift code and depending on `React-RCTAppDelegate` no longer requires the user to use modular headers for this pod
Reviewed By: NickGerleman
Differential Revision: D47955835
Pulled By: cipolleschi
fbshipit-source-id: 779516a8396925e52c28b87d6fcf096357333bf5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38673
This diff adds performance comparison examples to RNTester. In each of the comparison we have bad and good examples, which could be used for the following purposes:
- Collect common performance pitfalls
- Use as testbed on performance tools and metrics for validation hypothesis
Changelog:
[Internal] - Add performance comparison example in RNTester
Reviewed By: rshest
Differential Revision: D47821109
fbshipit-source-id: ea0242ea50724d27c7713bb116335a465e24d1a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38659
Run JSI tests against all the Hermes implementations exposed by
`APITestFactory`. To build with the older version of gtest available in
Hermes, the test needed to be slightly modified.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D47373805
fbshipit-source-id: 58958b4a60dac25f1b7defa490b888f21a665b0c
Summary:
Match the `react` dependency minor of `18.2` and specify a min version of `18.2.6`, which is the first version which includes `React.JSX` namespace. This enables usage of `React.JSX.Element`, now default as part of the template.
Note that `18.2.6` satisfied the previous semver, so new templates are already pulling in a version even newer than this, but updating projects may not do this automatically.
Changelog:
[General][Fixed] - Bump template types/react to 18.2.6
Pull Request resolved: https://github.com/facebook/react-native/pull/38713
Test Plan: CircleCI will build and typecheck a new template app.
Reviewed By: yungsters
Differential Revision: D47943524
Pulled By: NickGerleman
fbshipit-source-id: 49e587f8c2ebfce9fd1f00793a858d72ac0aa09e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38710
Fix a race condition when multiple consumers try to access ReactMarker and trigger calls to native module. Even though ReactMarker uses `ConcurrentLinkedQueue`, the loop itself could race and cause NPE.
Changelog:
[Android][Fixed] - Fix race condition with ReactMarker calls to its native module
Reviewed By: rshest
Differential Revision: D47933993
fbshipit-source-id: a56e5e4f3564922d534235991da5b6842248bf24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38699
Reduce visibility of ReactHost.prerenderSurface since this is only used from ReactSurface
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D47915588
fbshipit-source-id: 953b04b531d718434170d63e9f66d22758d26ddf
Summary:
[Codegen 131] This PR add a function `emitUnionProp` to the parser-primitives, as requested on https://github.com/facebook/react-native/issues/34872
## Changelog:
[INTERNAL] [ADDED] - Add `emitUnionProp` function to parser-primitives
Pull Request resolved: https://github.com/facebook/react-native/pull/38705
Test Plan: `yarn test react-native-codegen`
Reviewed By: christophpurrer
Differential Revision: D47921708
Pulled By: rshest
fbshipit-source-id: c2c081c6317928e5eb8b0c1d0640c7b7f40a4b0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38680
Upgrades to the recently published versions of `deprecated-react-native-listview` and `deprecated-react-native-prop-types`.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D47893357
fbshipit-source-id: 430cbb51086cfd1c346a6a5c15b2e90358ab6565
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38648https://github.com/facebook/react-native/pull/38475 made this code no longer no-op on Android, which caused regressions documented in https://github.com/facebook/react-native/issues/38470#issuecomment-1639620459 due to VirtualizedList having more out-of-date information.
We are already coalescing scroll events on both Android and iOS, which will ensure we are not flooded with events. VirtualizedList also already inserts an artificial 50ms delay to new renders by default when high priority work is not happening (see `updateCellsBatchingPeriod`). This limits the heavy work done by VirtualizedList (no new renders or expensive math on scroll events), while letting the list still have the most recent events.
We can eventually remove this once VirtualizedList is able to use OffScreen universally.
Changelog:
[General][Changed] - Remove default 50ms Scroll Event Throttling in VirtualizedList
Reviewed By: ryancat
Differential Revision: D47823772
fbshipit-source-id: 55d22a1074235ccc1b2cf167f6b1758640c79edb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38703
This change consolidates the pattern for setting up out-of-tree platform options for core classes like ViewProps and ViewEventEmitter. A similar pattern was used for Touch.h. As we move towards documenting how to build an out-of-tree platform, it would be nice to specify a set of HostPlatformX classes that need to be implemented and made resolvable from specific header paths.
At this point, there is:
- HostPlatformViewProps
- HostPlatformViewEventEmitter
- HostPlatformViewTraitsInitializer
- HostPlatformTouch
- HostPlatformColor
The other benefit of this pattern is to DRY helper aliases like SharedViewEventEmitter and SharedViewProps.
## Changelog:
[General] [Added] - Use more consistent pattern for out-of-tree platform Fabric C++ class extensions
Reviewed By: christophpurrer
Differential Revision: D47917598
fbshipit-source-id: 58ee9677eefd34eb0bc2d321103314642c457cd8
Arushi Kesarwani
Vicky Ahuja
Sam Zhou
Guil Varandas
Alex Hunt
Ruslan Shestopalyuk
Intl Scheduler
Nick Gerleman
Riccardo Cipolleschi
Samuel Susla
Nicola Corti
szymonrybczak
zhuwencheng
Andrea Cassani
Tomasz Sapeta
Xin Chen
Neil Dhar
David Vacca
Phillip Pan
Dmitry Rykun
Denis
Cao Doan
Tim Yung
Eric Rozell