Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41575
We currently do not validate the incoming native exception message
before passing it to the char* constructor of TwineChar16.
Treat it as UTF-8 and convert it to UTF-16 before creating the
JavaScript exception.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D49551640
fbshipit-source-id: 762f8038b29818d804bda5a7f3b4762621c94336
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41680
Just like how React Native can have n ReactPackages, it will support n CxxReactPackages.
This way, many applications can share common CxxReactPackages.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51484844
fbshipit-source-id: b9b70cab719e80a7ff7e635057d710f1a86fb1c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41679
This fixes a bug in the original implementation of image attached callbacks (still experimental). The problem was that we were unconditionally caching the ref passed to the underlying image component, which meant that whenever users passed new ref setters we wouldn't call them again.
This fixes that by forcing the creation of a new ref value whenever a new ref is passed to the image component.
Changelog: [internal]
Reviewed By: jehartzog
Differential Revision: D51618512
fbshipit-source-id: ac15160c528563c2131e8b3444dea4a6096f20bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41673
## The Problem
The cxxReactPackage property isn't initialized by the time initHybrid was executed. So, initHybrid was being called with null as the cxxReactPackage.
Why;
1. The default turbomodule manager delegate receives cxxReactPackage as a constructor param.
2. Java then executes all the constructors of the class hierarchy. This executes initHybrid.
3. Java finally initializes the properties of the derived class: default tmmd.cxxReactPackage (i.e: the parameter to initHybrid). **This is too late**
## The Fix
Refactor the code such that hybrid data creation doesn't depend on property initialization:
1. Create a static initHybrid method in default tmmd.
2. Call this static method with the cxxReactPackage, and assign the resultant HybridData to mHybridData (in tmmd).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51550623
fbshipit-source-id: ed2b7587351cfca408cda3c8cef4dcf7547e5f1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41674
The problem: The Java runtime couldn't find CatalystCxxReactPackage.initHybrid.
Why: I think is because CxxReactPackage loads CatalystCxxReactPackage's so in its constructor. This might be too late to load the derived class's so.
So, I just switched derived delegates to load the so in the static initializer (i.e: the recomended approch for so loading):
https://www.internalfb.com/code/fbsource/[91c4e41c49ed191ac864250ccaec52c01ddaeccc]/fbandroid/libraries/soloader/java/com/facebook/soloader/SoLoader.java?lines=52-54%2C60-61%2C63-67
This way:
1. The So's are loaded plenty early (the method not found error went away).
2. We don't create our own so loading infra, which complicates this abstraction, and makes it harder to work with, even more.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51550622
fbshipit-source-id: f4782d6fa9387f21fbf611191e9483e2a58b3a34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41675
FBJni expects the HybridData object to exist on the mHybridData property of the java object. So, we have to call this propery mHybridData.
Otherwise, this fbjni class just won't work.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51550621
fbshipit-source-id: d169266474717f0a38799ede7c07af57461012b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41667
changelog: [internal]
I made a mistake during refactor in D51471667 where I removed the check if rawProps is nullptr. We must check if props are empty during `UIManager::clone`, leaving the check for `ConcreteComponentDescriptor::cloneProps` does not lead to the same result.
There is a deeper problem here that needs to be analysed but this should resolve the lunch blocker.
Reviewed By: javache
Differential Revision: D51614396
fbshipit-source-id: 055694c4a71a914d8732a3632c50026cc24cbe7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41660
While working on other things, I noticed those warnings firing on console which I'm fixing here.
Changelog:
[Internal] [Changed] - Fix several build warnings on RN Tester Android
Reviewed By: cipolleschi
Differential Revision: D51589072
fbshipit-source-id: 1ddb29afd0d150f1ccbc7a8def9f27ecedb69724
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41661
This aligns the Kotlin version used inside fbsource to the one used for React Native GitHub
Changelog:
[Internal] [Changed] - Kotlin to 1.8.22
Reviewed By: NickGerleman
Differential Revision: D51587726
fbshipit-source-id: 5f985bd50c7688e4d369184b79dbf1bdc799876e
Summary:
While working in an app I kept getting these `View X of type Y has a shadow set but cannot calculate shadow efficiently. Consider setting a background color to fix this` warnings even though I had added a background color to that view. Upon inspecting RCTView.m I notice that what is actually required to fix this is a solid background
To make this a bit clearer to developers I believe we should update this log message to explicitly say "solid background" instead of "background"
## Changelog:
[IOS] [CHANGED] - Update 'cannot calculate shadow efficiently' log message to explicitly say solid background
Pull Request resolved: https://github.com/facebook/react-native/pull/39700
Test Plan: N / A
Reviewed By: christophpurrer
Differential Revision: D51584574
Pulled By: javache
fbshipit-source-id: b1741f7002ebb876e4a50959bef7f39df76a5c3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41394
X-link: https://github.com/facebook/yoga/pull/1463
Now that are enums are unsigned, and we don't have BitfieldRef, we can convert the last remaining user of NumericBitfield to a plain old bitfield, for better readability (e.g. the default values), debugability, and less complexity. We also break a cycle which lets us properly group public vs private members.
Reviewed By: joevilches
Differential Revision: D51159415
fbshipit-source-id: 7842a8330eed6061b863de3f175c761dcf4aa2be
Summary:
This PR removes duplicated `pod 'Yoga'` as it is already declared in `use_react_native`.
## Changelog:
[INTERNAL] [REMOVED] - duplicated pod 'Yoga' in RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/41627
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D51603340
Pulled By: NickGerleman
fbshipit-source-id: 89e77e5a544cb54d77b969462130725853b36d5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41658
changelog: [internal]
FabricEventDispatcher does not need to run on every frame. Whenever a new event is added to Fabric's event queue, it will call `FabricUIManager.onRequestEventBeat` in Java. This in turn calls `FabricEventDispatcher.maybePostFrameCallbackFromNonUI` and adds a frame callback on the Choreographer.
This makes code simpler, as we do not need to manage the frame callback subscription.
Reviewed By: sammy-SC
Differential Revision: D50604303
fbshipit-source-id: ce2c7b77678bfc14aa7ecac71e40f78263c7036a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41625
To tell React Native whether we are building with hermes or not on iOS, we were using 2 different build time flags:
- USE_HERMES
- RCT_USE_HERMES
The first was widely used by the OSS use case, while the latter was set internally.
Worse than that, their default values were the opposite and we were never setting the RCT_USE_HERMES explicitly with Cocoapods, while there was some piece of code that was trying to "smartly" detect whether Hermes was included or not.
This change unifies the behavior, removing the "smartness" in favor od a declarative approach.
## Changelog:
[Internal] - Unify the USE_HERMES flags
Reviewed By: christophpurrer
Differential Revision: D51549284
fbshipit-source-id: 829ad361e185d5b4fa227605523af3a8e590e95c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41626
In the codebase, we never set the RCT_USE_HERMES flag.
When we install the pods, we use the USE_HERMES flag and we set USE_HERMES as a build setting. So, the RCT_USE_HERMES flag will always be not set for the OSS.
https://pxl.cl/3RRxr
## Changelog:
[iOS][Fixed] - use the right USE_HERMES flag
## Facebook:
This change was incorrect as in OSS we never set the RCT_USE_HERMES flag, while we actually set the USE_HERMES one.
I will align the BUCK RNTester setup in the next diff of the stackog:
Reviewed By: dmytrorykun
Differential Revision: D51547810
fbshipit-source-id: 1da5b3a48a83a8ba49cf65382927bed2f9fc893d
Summary:
changelog: [internal]
From sammy-SC, we would like to minimize the number of times that React Native schedules Choreographer calls. For animations, we do not need choreographer running on every frame, it only needs to run on frames that have an animation active. This diff modifies the frame callbacks such that Choreographer calls are only enqueued if there is an ongoing animation.
Reviewed By: sammy-SC
Differential Revision: D50647971
fbshipit-source-id: d77b246beafc5c658c738e574b0e02dd68fadce9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41560
This diff gives some functions and variables more accurate names:
1. `appRoot` -> `projectRoot`
2. `handleThirdPartyLibraries` -> `findExternalLibraries`
3. `handleLibrariesFromReactNativeConfig` -> `findLibrariesFromReactNativeConfig`
4. `handleInAppLibraries` -> `findProjectRootLibraries`
It also removes `isAppRootValid` check that checks that `appRoot != null`, it is redundant since `appRoot`(now `projectRoot`) is required by the CLI.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51309027
fbshipit-source-id: c5e34c2aa788a7795c68697a0fa9ddf0163cec0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41558
Now that the previous diff in the stack (D51303793) provides proper dependency path resolution, we can process `react-native` as a normal dependency, and remove a special code path for it.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51256764
fbshipit-source-id: 2a11641e9362d7bfad1ff9995b4f3bb4c92d9c0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41654
This diff removes support for defining external codegen targets in `react-native.config.js` for iOS. Now you can simply add your external dependency to the project's `package.json` and it will be resolved as a normal Node packages.
## Motivation
The need for defining external codegen targets in `react-native.config.js` historically appeared due to limitations of how codegen searched for external dependencies. Basically we performed search only in the project directory. External dependency paths had to be listed in `react-native.config.js`.
After D51303793 has landed we don't need this any longer. We can simply rely on Node resolution to find those external dependencies.
Changelog: [iOS][Breaking] - Defining external codegen targets in `react-native.config.js` is not supported anymore. Define them as normal dependencies in `package.json`.
Reviewed By: cipolleschi
Differential Revision: D51308595
fbshipit-source-id: 97841a3a8c295aa717c577bb188d48373b04ba38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41645
Right now, when defining concrete structs and Bridging headers for Cxx TMs we need to define their member types twice:
```
using ConstantsStruct =
NativeCxxModuleExampleCxxBaseConstantsStruct<bool, int32_t, std::string>;
template <>
struct Bridging<ConstantsStruct>
: NativeCxxModuleExampleCxxBaseConstantsStructBridging<
bool,
int32_t,
std::string> {};
```
Now we only need to define those once
```
using ConstantsStruct =
NativeCxxModuleExampleCxxConstantsStruct<bool, int32_t, std::string>;
template <>
struct Bridging<ConstantsStruct>
: NativeCxxModuleExampleCxxConstantsStructBridging<ConstantsStruct> {};
```
This change keeps the existing base types untouched - but they will be removed in the next RN version.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D51571453
fbshipit-source-id: 2783bd48bf786ffa80d322d06456b5d6f2d7ba8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41391
X-link: https://github.com/facebook/yoga/pull/1461
Converts usages of `YGEdge` within internal APIs to `yoga::Edge` scoped enum.
With the exception of YGUnit which is in its own state of transition, this is the last public yoga enum to need to be moved to scoped enum form for usages internal to the Yoga public API.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D51152779
fbshipit-source-id: 06554f67bfd7709cbc24fdd9a5474e897e9e95d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41390
X-link: https://github.com/facebook/yoga/pull/1460
Yoga passes `MeasureMode`/`YGMeasureMode` to express constraints in how a box should be measured, given definite or indefinite available space.
This is modeled after Android [MeasureSpec](https://developer.android.com/reference/android/view/View.MeasureSpec), with a table above `calculateLayoutImpl()` explaining the CSS terms they map to. This can be confusing when flipping between the spec, and code.
This switches internal usages to the CSS terms, but leaves around `YGMeasureMode` since it is the public API passed to measure functions.
Reviewed By: joevilches
Differential Revision: D51068417
fbshipit-source-id: 0a76266a4e7e0cc39996164607229c3c41de2818
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41392
X-link: https://github.com/facebook/yoga/pull/1458
We're moving `CompactValue` to be an internal detail of `yoga::Style`, where users outside of the style will be dealing with a resolved/non-compact representation.
This change renames usages of `CompactValue` to `Style::Length`, which will be Yoga's representation for CSS input lengths. Right now one is just a type alias of the other, but this will let us change the internals of CompactValue with the rest of the world looking the same.
A few factory functions are added to `yoga::value` for creating CSS values. There are some shenanigans around how we want to represent CSS pixels (one YGUnitPoint), when we also end up adding CSS points (slightly larger than one YGUnitPoint). For now, I reused `point` until making other changes.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D51000389
fbshipit-source-id: 00f55e72bfb8aa291b53308f8a62ac8797be490f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41640
react-native-svg reported that the SVG library was not building on the latest RC of React Native because Codegen was not finding the proper files.
By inspecting an example app with SVG, we realized that React-Codegen was not depending on `React-FabricImage`, while having access to their headers.
We added the dependency, but them the build was failing due to a circular dependency because the `React-ImageManager` was dependeing on `React-RCTImage`.
This dependency is conceptually wrong (a piece of Core should not depend on Library which depends on Core... 😑) and I verified that by removing that dependency the framework continue to build.
## Changelog:
[Internal] - Fixed dependencies of Codegen on React-Image
Reviewed By: cortinico
Differential Revision: D51564037
fbshipit-source-id: 8e7108b83f878be1063df5562311d862d4998121
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41643
Code in `AndroidTextInputComponentDescriptor` will rewrite Yoga props for padding based on Android theme, if a value isn't supplied. It determines this by adding props in `AndroidTextInputProps` which reads Yoga RawProps to tell if they were set.
RawProps are keyed using separate prefix/name/suffix, instead of the combined string name of the prop. This means that searching for the name `paddingLeft`, would be different from reading one with a name of `padding` and a suffix of `Left`.
This updates the keying, based on the changes in D51510562.
We should refactor this in the future (D20109605, introducing this code, admitted as much). We already have a phase, for aliased props, where we transform input props into the Yoga style (they don't need to be 1:1). This doesn't depend on RawProps, extra props, or prop mutations.
Changelog:
[Android][Fixed] - Fix AndroidTextInputProps Detection of Padding
Reviewed By: GijsWeterings
Differential Revision: D51566900
fbshipit-source-id: ca744b23d71382941903da42d86ad3eef7b65de8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41549
Changelog: [Internal]
Introduces the `JSRuntime` interface as a straightforward wrapper around `jsi::Runtime`, and refactors `ReactInstance` to hold a `JSRuntime` instead of a `jsi::Runtime`. In an upcoming diff we'll add debugging-related methods to `JSRuntime` and specialise their implementations for Hermes.
NOTE: `JSRuntime` is somewhat analogous to `JSExecutor` in the Bridge architecture.
Reviewed By: huntie
Differential Revision: D51447934
fbshipit-source-id: cfcab9ae0dd3d2a34c064abaac6cb676f435e216
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41642
This allows opening an example within RNTester without tapping the module card. If the app receives an openURL request with the format `rntester://example/<key>`, open that example (if exists) directly. Such URL request may come from various sources (e.g. custom test run, etc).
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51543385
fbshipit-source-id: f9a01963cefb4602b629da0b01be6e334c28a912
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41623
`static` fields require additional code to ensure the field is only ever initialized once. We already have a static "default props" field in the shadow node, so let's reuse that as much as possible.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D51547638
fbshipit-source-id: e4957ffb0f9352847b8cd8dc3a010dcfac8be699
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41628
# Changelog:
Even though `onClick` is used on Android (e.g. via Pressability), the fact of having the handler registered didn't get through to the C++ side on New Architecture, because of being filtered out via the corresponding static view config.
As the result, there was no way to know on C++ side whether the corresponding event handler is registered for the view or not. Dynamic updates to the prop also wouldn't correctly propagate to C++, which may be a problem if a view gets e.g. the handler dynamically added.
Reviewed By: javache
Differential Revision: D51551255
fbshipit-source-id: 0783f5a27c7250f83fb357173bbe5be6213277e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41613
Changelog: [Internal]
We were keeping ref in the AppContainer's state before migrating these components to functions.
We actually need a real ref here, so we can use `useImperativeHandle` on it later. These refs will be passed as an argument for DebuggingRegistry subscription, whichi will call them on all necessary AppContainers to highlight required components.
Reviewed By: javache
Differential Revision: D51536772
fbshipit-source-id: d49035874ce3c9b1acf08d5ab666886f68e6f40e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41562
Changelog: [Internal]
We will use this native component as a single layer for drawing debugging information: both for trace updates and inspected components from React DevTools.
Reviewed By: javache
Differential Revision: D51470789
fbshipit-source-id: 6c4633d2b70c2c2635a2bbfcd7adf1c727b73585
Summary:
Several deprecation warning messages related to components that were removed from `react-native` were outdated.
Some repositories have been moved, some packages were renamed/re-published under new names. A couple **never existed** (`react-native-community/segmented-checkbox` and `react-native-community/react-native-image-picker`).
This updates all messages to include links to the latest repositories and references to npm packages.
Because `react-native-community/art` is deprecated I've also slightly amended the message with the suggestion from its [repo readme](https://github.com/react-native-art/art#deprecated---this-package-is-deprecated-if-you-need-a-similar-package-please-consider-using-react-native-svg).
## Changelog:
[GENERAL] [FIXED] - Update pkg/repo names in deprecation messages
Pull Request resolved: https://github.com/facebook/react-native/pull/41618
Test Plan: No code change, just documentation/text.
Reviewed By: cipolleschi
Differential Revision: D51546345
Pulled By: cortinico
fbshipit-source-id: 5d7176a70d94c8b1e8111f4d84fba89eacde456a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41621
Currently, if you have a dependency that is alphabetically smaller than `app`, it's evaluation will happen before `app`.
This means that the namespace auto-discovery and the JVM toolchain configuration won't be working and the project will fail to buid.
This fixes it by introducing a root-project Gradle Plugin that takes care of enforcing the evaluation order on the `app` project.
Fixes#41620
Changelog:
[Android] [Fixed] - Fix projects being broken on dependencies starting with `a..`
Reviewed By: huntie
Differential Revision: D51547294
fbshipit-source-id: 65df7149548b7087dd8928e556fb803b3baf7b79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41557
The `configFileDir` CLI argument is used to help to find paths to the 3rd party dependencies of the app. Since we only care about dependencies listed in the root `package.json`, we can use `node` resolution instead of having to construct paths manually. In that case `configFileDir` becomes redundant.
Changelog: [iOS][Breaking] - Delete configFileDir CLI argument.
Reviewed By: cipolleschi
Differential Revision: D51303793
fbshipit-source-id: 46cb61197ddf51515af634c8fc6b85a8d218c51e
Summary:
This PR addresses the problem raised in the https://github.com/facebook/react-native/issues/41004 issue.
The current logic is that `selectionColor` on iOS sets the color of the selection, handles, and cursor. On Android it looks similar, while it doesn't change the color of the handles if the API level is higher than 27. In addition, on Android there was an option to set the color of the cursor by `cursorColor` prop, but it didn't work if the `selectionCursor` was set.
## 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] [ADDED] - Make same behavior of the `selectionColor` prop on Android as iOS
[ANDROID] [ADDED] - Introduced `selectionHandleColor` as a separate prop
[ANDROID] [CHANGED] - Allowing `cursorColor` and `selectionHandleColor` to override `selectionColor` on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/41092
Test Plan:
Manual tests in rn-tester:
### `selectionColor` same as iOS, sets selection, handles and cursor color
_There is a way to set only "rectangle" color by setting other props as null_

### `selectionHandleColor`

### `cursorColor`

Reviewed By: NickGerleman
Differential Revision: D51253298
Pulled By: javache
fbshipit-source-id: 290284aa38c6ba0aa6998b937258788ce6376431
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41609
Aggregate edges will no longer be exposed. Inline debugStringConvertibleItem string printing for it.
Previously included in D50998164
Changelog:
[Internal]
Reviewed By: joevilches
Differential Revision: D51510790
fbshipit-source-id: aaabaa4fdd899bd9c602b9a5ab5dd35265c7269b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41611
Aggregate edges will no longer be exposed. Inline the convertRawProp parsing functions for it.
This is a little bit more code, but subjectively easier to reason about.
Previously included in D50998164
Changelog:
[Internal]
Reviewed By: joevilches
Differential Revision: D51510562
fbshipit-source-id: 30440e19422a3a3fb49a754b5ecd8279ce1521a2