Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Differential Revision: D39052812
fbshipit-source-id: 9692633930555e64a3769116fc484a19e534aa3f
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D38938632
fbshipit-source-id: 1dc9a544ca679463a8aad5cc632bd918f42b15d1
Summary:
Noticed this logging was broken when enabling the flag.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38616851
fbshipit-source-id: acf0ab75918b389586cb713c2edf5a6bf83ee7a2
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of `convertRawProp` for `std::optional` since we can handle that in a `fromRawValue` specialization instead.
To make this work, we need to remove `noexcept` from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D37055069
fbshipit-source-id: 8ce121a9b187f068d3ab790c6fae66d53e6338d2
Summary:
As title, replace json serialization/deserialization and folly with MapBuffer for js error handling in Android.
Changelog:
[Android][Changed] Replace Folly with MapBuffer for passing js error data
(Note: this ignores all push blocking failures!)
Reviewed By: RSNara
Differential Revision: D38460202
fbshipit-source-id: e13a47722964baa9e0a16bb138456a19350f809e
Summary:
Currently the PropSetter parser parses all border{TopLeft,TopRight,...}Radius props except for `borderRadius`.
This is the fix.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38678226
fbshipit-source-id: 8c5d67a652c2b327aa50a997e8e886630fe139c0
Summary:
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for mapbuffer
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - mapbuffer
Reviewed By: cipolleschi
Differential Revision: D38699253
fbshipit-source-id: c1c8f8693b6da4e3428f8f280e1ca4d5c5d0f853
Summary:
Changelog: [iOS][Internal] - Add iOS implementation of the button property of the PointerEvent object
This implements the `button` property on the PointerEvent object by storing the button which caused the down event in the `ActiveTouch` and reporting that button through `pointerdown` and `pointerup` events and -1 on all others. This diff also includes a small fix to the `pressure` property which was introduced due to `button` being correctly implemented.
Reviewed By: yungsters
Differential Revision: D38632543
fbshipit-source-id: 9dbbb23a9251f2e661faf37fdf206b9f0b26bc5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34403
This change mirrors D38457812 (https://github.com/facebook/react-native/commit/063c2b4668b279ccbca639f98f7a0a5c4d7c5690) which added -Wpedantic to ReactCommon targets, but for the Android build used by OSS. This should ensure contributors see the same warnings locally as the internal build would produce.
Changelog:
[Android][Changed] - Enable -Wpedantic in OSS Android Targets
Reviewed By: cortinico
Differential Revision: D38632454
fbshipit-source-id: 19a036ee3f902eb9d47c568aef448af9d8562358
Summary:
Add ability to store and retrieve a list of MapBuffer as an entry of MapBuffer.
```
Example:
MapBuffer1
{
key1: "test string",
key2: MapBuffer2,
key3: [MapBuffer3, MapBuffer4]
}
```
Changelog:
[General][Added] Add ability to store and retrieve a list of MapBuffer
Reviewed By: JoshuaGross
Differential Revision: D38460204
fbshipit-source-id: 3e721418be2dca6d5f15f665753844d6f531e31c
Summary:
Folly's molly target combines a number of targets that are supposed to be useable on mobile. Since we're trying to move away from folly, we should instead list explicitly which parts of folly we're using so we can remove them over time, and track which targets no longer have any folly dependencies.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38352060
fbshipit-source-id: 09d0d84793692f97f4d49390c99c38b23441df54
Summary:
React Native is compiled downstream with MSVC, meaning the introduction of code depending on language extensions specific to gcc/clang may cause breakage.
We can enable `-Wpedantic` to flag any behavior not officially supported by the specified C++ standard. This will includes rules beyond what MSVC has trouble with, but seems to not have too many "noisy warnings".
This change enables -Wpedantic in BUCK targets within ReactCommon.
This makes the OSS C++ build for Android/iOS slightly more permissive than the internal build, A followup is to add the changes to OSS build logic as well, to avoid contributors seeing more errors upon internal submission. (checking with cortinico on how to do this for Android).
react-native-windows uses a higher warning level than `-Wall`, which is an additional cause of compilation failures, but is not addressed as part of this change.
Changelog:
[Internal][Changed] - Enable -Wpedantic for targets inside ReactCommon
Reviewed By: rshest
Differential Revision: D38457812
fbshipit-source-id: 014da1ac0b7ad8f78154e6e447ed58def6bd0d47
Summary:
We ran an experiment to test different implementations of TurboModules HostObjects, as the current one has various inefficiencies, such as re-creating HostFunctions on every property access. The strategy we found to be most efficient and flexible longer-term is to represent the TurboModule with a plain JavaScript object and use a HostObject as its prototype. Whenever a property is accessed through the prototype, we cache the property value on the plain object, so it can be efficiently resolved by the VM for future accesses.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38355134
fbshipit-source-id: 59253091412d0c6827ad7a4b1ac7dc0c7fe89cc2
Summary:
`toJs()` resolution trips up on converting the plain old jsi values.
In order to help it - remove the automatic inference of template types, since we already know that `T` in this case is going to be the concrete jsi type.
This allows using implicit conversions on Sync/Async Callback types, as well as AsyncPromise.
Without it - AsyncPromise/Callback trip up on trying to convert Convertor<T> to jsi type.
Changelog:
[General][Added] SyncCallback/AsyncCallback/AsyncPromise bridging types in C++ now allow wrapping JSI types.
Reviewed By: JoshuaGross
Differential Revision: D38529799
fbshipit-source-id: 860de2d771899f331bf1a4ff0dade4eccc875618
Summary:
This Pull Request aims at removing the making of reactnativeutilsjni as it is built from the same sources as reactnativejni. It also replaces references to reactnativeutilsjni with reactnativejni.
This should get rid of `reactnativeutilsjni.so` while reusing `reactnativejni.so` in it's place. This should give us some size improvements in the finally built apk.
## 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
-->
[Android] [Changed] - Replaced reactnativeutilsjni with reactnativejni in the build process to reduce size
Pull Request resolved: https://github.com/facebook/react-native/pull/34339
Test Plan:
1. Ran the CMakelist.txt file using CMake and I could see that reactnativeutilsjni.dir is no longer generated with my changes.
2. Built the aar from this branch in Android Studio and build happened successfully.
I am not sure if we could run any more tests. Please let me know in case anymore testing is required and I can do accordingly
Reviewed By: cortinico
Differential Revision: D38400481
Pulled By: genkikondo
fbshipit-source-id: 592736e56441328389ae89135667c336ff8018e6
Summary:
Changelog:
[Android][Fixed] - Fix regression when setting shadow node properties.
Also simplified the corresponding macros to avoid using lambdas altogether, as they are not required.
Note that this **does not** modify any constexpr-related semantics of the existing code, as the main constexpr macro, `CONSTEXPR_RAW_PROPS_KEY_HASH` evaluation result is still contstexpr value, and the other ones already involved non-const parts (see my comments).
Reviewed By: NickGerleman
Differential Revision: D38356411
fbshipit-source-id: 22c330d3425c8aed36693f4652f1b257d2dc96be
Summary:
Fix macro errors for Windows. Current syntax breaks the build of the React Common project on Windows because the ({...}) syntax is not supported; must be replaced with lambda expressions.
Resolves https://github.com/facebook/react-native/issues/34090
## 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
-->
[General] [Fixed] - Fix macro errors for Windows.
lyahdav JoshuaGross
Pull Request resolved: https://github.com/facebook/react-native/pull/34299
Test Plan: Build on react-native-windows repo. Tested in RNW app.
Reviewed By: javache
Differential Revision: D38272966
Pulled By: NickGerleman
fbshipit-source-id: e76eac11cde173ef49465d01d793c593017f2ab7
Summary:
This diff fixes the bug T127619309 by exit early during calculateTransformedFrames if currentShadowNode cannot be casted
This is a bug that fired in fb4a but we didn't have a way to reproduce locally.
We are going to release this and enable feature flag with a MC
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38280674
fbshipit-source-id: 1c42c17678d8473564e4075a78d3c688efed1a23
Summary:
Calculation of TransformedFrames was a method introduced by D37994809 (https://github.com/facebook/react-native/commit/64528e5faa445907b8287b412c344f30c20fca61) to fix rendering of inverted flat lists.
We found that this operation is crashing in fb4a causing the UBN T127619309
This diff creates a feature flag to disable the calculation of TransformedFrames in Layoutable ShadowNodes. **The goal of this diff is to revert the behavior introduced by D37994809 (https://github.com/facebook/react-native/commit/64528e5faa445907b8287b412c344f30c20fca61)**
The featureFlag is disabled in fb4a and enabled in react AR (because ReactAr apps relies on the calculation of TransformedFrames and these apps are not affected)
The root cause of the bug will be fixed by D38280674 (which still requires more testing and investigation)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D38286857
fbshipit-source-id: 721cd0554ae6a6b369b3f8dbb584160a270d0f18
Summary:
Fixes https://github.com/facebook/react-native/issues/34120
The new React Native architecture doesn't check `needsCustomLayoutForChildren` so it wrongly positions native views on Android. In https://github.com/facebook/react-native/issues/34120 there are videos comparing the positioning of a native action view in the old and the new architecture.
This PR passes the parent tag to the `updateLayout` method of the `SurfaceMountingManager`. The `SurfaceMountingManager` calls `needsCustomLayoutForChildren` on the parent view manager (copied the code from the `NativeViewHierarchyManager` in the old architecture).
**NOTE** - I wasn't sure where to get the parent shadow view from so I've put in my best guesses where I could and left it as `{}` otherwise.
## Changelog
[Android] [Fixed] - Migrate `needsCustomLayoutForChildren` check to the new architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/34254
Test Plan:
I checked the fix in the repro from https://github.com/facebook/react-native/issues/34165. Here is a video of the action view closing using the native button that is now visible in the new architecture.
https://user-images.githubusercontent.com/1761227/180607896-35bf477f-4552-4b8a-8e09-9e8c49122c0c.mov
Reviewed By: cipolleschi
Differential Revision: D38153924
Pulled By: javache
fbshipit-source-id: e2c77fa70d725a33ce73fe4a615f6d884312580c
Summary:
Changelog: [iOS][Internal] - Add isPrimary property implementation to the PointerEvent object
This diff adds the `isPrimary` property to the PointerEvent object iOS implementation. In addition this adds a related change where we "reserve" the 0 touch identifier for mouse events and the 1 identifier for apple pencil events. This is an easy way to ensure that these pointers are always consistent no matter what happens. Since mouse & pencil pointers should always be considered the primary pointer, that allows us to focus the more advanced primary pointer differentiation purely on touch events.
The logic for this touch event primary pointer differentiation is essentially setting the first touch it recieves as a primary pointer, setting it on touch registration, and sets all subsequent touchs (while the first touch is down) as not the primary pointers. When that primary pointer is lifted, the class property keeping track of the primary pointer is reset and then the **next** pointer (secondary pointers which had already started before the previous primary pointer was lifted are not "upgraded" to primary) is marked as primary. A new platform test is also included in this diff in order to verify the aforementioned behavior.
Reviewed By: lunaleaps
Differential Revision: D37961707
fbshipit-source-id: ae8b78c5bfea6902fb73094fca1552e4e648ea44
Summary:
changelog: [internal]
Vertical and horizontal inversion was not taken into account in `computeRelativeLayoutMetrics`. To fix it, we precompute frames to include inversions.
Reviewed By: mdvacca
Differential Revision: D37994809
fbshipit-source-id: 043e6f19b6fa577f61fa3c739ce2d751ef973cc3
Summary:
D37801394 (https://github.com/facebook/react-native/commit/51f49ca9982f24de08f5a5654a5210e547bb5b86) attempted to fix an issue of TextInput values being dropped when an uncontrolled component is restyled, and a defaultValue is present. I had missed quite a bit of functionality, where TextInput may have child Text elements, which the native side flattens into a single AttributedString. `lastNativeValue` includes a lossy version of the flattened string produced from the child fragments, so sending it along with the children led to duplicating of the current input on each edit, and things blow up.
With some experimentation, I found that the text-loss behavior only happens on Fabric, and is triggered by a state update rather than my original assumption of the view manager command in the `useLayoutEffect` hook. `AndroidTextInputShadowNode` will compare the current and previous flattened strings, to intentionally allow the native value to drift from the React tree if the React tree hasn't changed. This `AttributedString` comparison includes layout metrics as of D20151505 (https://github.com/facebook/react-native/commit/061f54e89086af1c80e5b0460ec715533f99bdb7) meaning a restyle may cause a state update, and clear the text.
I do not have full understanding of the flow of state updates to layout, or the underlying issue that led to the equality check including layout information (since TextMeasurementCache seems to explicitly compare LayoutMetrics). D18894538 (https://github.com/facebook/react-native/commit/254ebab1d2b6fac859ab1ae0c9503328fc99a6d0) used a solution of sending a no-op state update to avoid updating text for placeholders, when the Attributed strings are equal (though as of now this code is never reached, since we return earlier on AttributedString equality). I co-opted this mechanism, to avoid sending text updates if the text content and attributes of the AttributedString has not changed, disregarding any layout information. This is how the comparison worked at the time of the diff.
I also updated the fragment hashing function to include layout metrics, since it was added to be part of the equality check, and is itself hashable.
Changelog:
[Android][Fixed] - Fix `AttributedString` comparison logic for TextInput state updates
Reviewed By: sammy-SC
Differential Revision: D37902643
fbshipit-source-id: c0f8e3112feb19bd0ee62b37bdadeb237a9f725e
Summary:
Changelog: [iOS][Internal] - Add key modifier properties to the PointerEvent interface
This diff adds implementations of the `ctrlKey`, `shiftKey`, `altKey`, and `metaKey` properties on the PointerEvent interface for iOS.
Reviewed By: lunaleaps
Differential Revision: D37869377
fbshipit-source-id: b187bae93fbfc97b6ca1d8d9786ad85343484b3d
Summary:
changelog: [internal]
Original commit changeset: 290ae428a720
Original Phabricator Diff: D37881453 (https://github.com/facebook/react-native/commit/e98a835bfc7b01bccb1b7cdee94db248a0a90607)
in the original diff I made a mistake. The default value for RN is never, we override it in one of our subclasses.
Reviewed By: cortinico
Differential Revision: D37884715
fbshipit-source-id: 3c5b5ef5550120034e33ae9047292f38159dea3e
Summary:
Changelog: [iOS][Internal] - Implement offsetX/offsetY properties on the PointerEvent interface
Simple diff implementing the offsetX/offsetY properties on PointerEvent — thankfully the touch events already kept track of these so it was mostly a matter of forwarding that data to the pointer events.
Reviewed By: lunaleaps
Differential Revision: D37830139
fbshipit-source-id: 77f33a99393350d32cbe449e6a009bdeb2a12d08
Summary:
Changelog:
[general][change] - Use RuntimeConfig instead of VM Experiment Flag to set up the micro task queue.
Reviewed By: neildhar
Differential Revision: D37353947
fbshipit-source-id: 5c8f35c0a79d70cb0d234e881e55058cffb44ac8
Summary:
Changelog: [iOS][Internal] - Implement screenX/screenY properties on the PointerEvent interface
This diff implements the screenX/screenY properties which report the position of a pointer in the device's physical screen coordinates.
Reviewed By: lunaleaps
Differential Revision: D37794415
fbshipit-source-id: 6c39c3651812f99e66b93647579a2935598ef6f2
Summary:
Changelog: [iOS][Internal] - add x/y & pageX/Y implementations to PointerEvent interface
This diff adds the x/y properties, which are defined as aliases of clientX/clientY respectively. In addition this diff adds pageX/pageY which, while not definted as aliases of clientX/clientY, are effectively aliases in React Native since the root view is not scrollable (client and page points only differ on the web when a user has scrolled the document element).
Reviewed By: lunaleaps
Differential Revision: D37766818
fbshipit-source-id: c7ad3750460b1913889c6d1a55b4c1edc6918f5b
Summary:
Changelog: [iOS][internal] - Add twist property to PointerEvent interface
This adds the twist property to the PointerEvent implementation on iOS which similarly to tangentialPressure doesn't really apply so we default to a hard-coded value of 0.
Reviewed By: lunaleaps
Differential Revision: D37760511
fbshipit-source-id: f1fccfd6b5d07024cea83d86925a9bfc2e6cc8cf
Summary:
Changelog: [iOS][internal] - Add tangentialPressure property to PointerEvent interface
This diff adds the tangentialPressure property to the PointerEvent implementation on iOS. This one is pretty simple considering iOS doesn't have the concept of tangential pressure so we just hard code it to 0 as defined by the spec.
Reviewed By: lunaleaps
Differential Revision: D37759634
fbshipit-source-id: 7ca0e47267f5fde76ace2b96d05ea2e154cb4b8f
Summary:
Fix todo and inconsistency across codebase. It's better to have just one way to refer to these types.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D37653146
fbshipit-source-id: e82f09caa6cd6eec5512b78f413708d9c04a7a83
Mitch Powell
Pieter De Baets
Shawn Shihang Wei
Lulu Wu
Ravi Shah
Huyue Gu
Samuel Susla
Joshua Gross
Nicola Corti
Luna Wei
Vincent Riemer
Nick Gerleman
Oleksandr Melnykov
Nikita Lutsenko
Sparsha Saha
Ruslan Shestopalyuk
Dark Knight
Chiara Mooney
David Vacca
Graham Mendick
Tony Du
Eric Edouard
Michael Anthony Leon
Genki Kondo
Kevin Gozali
