Summary: Migrate ReactTextinputManager to support bridgeless mode by accessing the EventDispatcher through the UIManagerHelper instead of from ReactContext.
Reviewed By: mdvacca
Differential Revision: D19614184
fbshipit-source-id: 5dd4945223d10785f8fe171e06d6f7ef42f9d834
Summary:
Changelog: [Internal]
# Analysis
Measure returns following values for `frame.y` when tapping item in bottom sheet.
Fabric 412.33331298828125.
Paper 49.
In Paper, the frame.y returned is the position of tapped item in bottom sheet relative to the bottom sheet itself, which is correct.
This can happen in both BottomSheet and Modal.
# Why it happens?
In [UIManager.getRelativeLayoutMetrics](https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/ReactCommon/fabric/uimanager/UIManager.cpp?commit=a372cf516ba1245ad9462e68376ee759c118a884&lines=172-181) if `ancestorShadowNode` is nullptr we populate `ancestorShadowNode` with `rootShadowNode` for the surface.
Problem is that BottomSheet that is presented, is not a separate surface. This means that we climb up the shadow node hierarchy all the way to root shadow node and keep adding offsets. Even though we should stop when we hit shadow node representing BottomSheet.
# How could be this fixed?
I think we should add a new shadow node trait that would mark node as root node. As we are traversing the shadow node tree upwards and adding offset of that node, once we hit a node that is "anchor", we would immediately stop the traversal.
This solution is inspired by Paper where the node representing BottomSheet has a special flag which marks it as "root" node.
accepttoship
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19640454
fbshipit-source-id: bde623b1f41a9745a41f0aada7221bf924fad453
Summary: `requireNativeComponent` redboxes in bridgeless mode because there is no UIManager. This adds a handwritten view config to avoid using UIManager.
Reviewed By: ejanzer
Differential Revision: D19624044
fbshipit-source-id: 5ae68f63068a131a305754003154ee0cf0f1be46
Summary:
## Description
You're not supposed to hold on to JSI objects (ex: `jsi::Function`) past the point where their `jsi::Runtime` is deleted. Otherwise, we get a dangling pointer crash, like this: T60262810! Historically, this cleanup problem has always been really tricky to get right. With this diff, I hope to fix that problem once and for all by deleting all `jsi::Function`s when we delete the global `__turboModuleProxy` function.
## Current Setup
- The TurboModules infra uses weak references to `CallbackWrapper`s to hold on to the `jsi::Function`s passed from JS to ObjC.
- The LongLivedObjectCollection holds on to strong references to `CallbackWrapper`s. This ensures that the `jsi::Function`s aren't deleted prematurely. This also means that we can use `LongLivedObjectCollection` to delete all `CallbackWrappers`.
- `TurboModuleBinding` is the abstraction we use to install the global `__turboModuleProxy` function. It is owned by `TurboModuleManager`, and `TurboModuleManager` uses it to clear all references to `jsi::Function`s, when we delete all NativeModules.
## Solution
1. Transfer ownership of `TurboModuleBinding` from `TurboModuleManager` to the `__turboModuleProxy` function.
2. Clear the `LongLivedObjectCollection` when `TurboModuleBinding` is deleted.
Changelog:
[iOS][Fixed] - Clear all held jsi::Functions when jsi::Runtime is deleted
Reviewed By: JoshuaGross
Differential Revision: D19565499
fbshipit-source-id: e3510ea04e72f6bda363a8fc3ee2be60303b70a6
Summary:
Changelog: [Internal]
Exposes `synchronouslyWaitForStage` to `RCTFabricSurface`.
This is a first step towards having screenshot tests rendered with Fabric.
Reviewed By: shergin
Differential Revision: D19603837
fbshipit-source-id: 26c14cf3bbd67fea96319ff08d3321557ddcdd9c
Summary:
Issue: https://github.com/facebook/react-native/issues/27565
initalizeFlipper should be set in template app by default.
## Changelog
[iOS] [Changed] - Added Flipper to template app
[Android] [Changed] - Added Flipper to template app
Pull Request resolved: https://github.com/facebook/react-native/pull/27569
Test Plan:
Connect Flipper to the iOS application
Connect Flipper to the Android application
Reviewed By: passy
Differential Revision: D19344704
Pulled By: rickhanlonii
fbshipit-source-id: ca126fd2caab13751ddc2ce6d195bd0c644c704e
Summary:
We are deprecating SharedShadowNode in favor of ShadowNode::Shared, the previous diff already removed most of the usages of SharedShadowNode
changelog: [internal]
Reviewed By: shergin
Differential Revision: D19217718
fbshipit-source-id: 1b7cd1af0ecdc6112befdc45c1dd0fca5012ab21
Summary:
ShadowNode::Shared and SharedShadowNode represent the exact same type. Nowadays we use ShadowNode::Shared instead of SharedShadowNode.
This diff replaces usages of SharedShadowNode for ShadowNode::Shared in the fabric folder.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D19217717
fbshipit-source-id: 112331b22251aa3a3d5e183395c54f2ca0f56e47
Summary:
A new triage group is being set up. As part of the triage process, all new issues will be tagged as "Needs: Triage 🔍". We can achieve this by baking the label into the default issue template.
The `react-native-bot` has been updated so it does not auto-close issues tagged with this label. Previously, it would look for the presence of the "Bug" label to determine if someone used the default issue template.
I've removed HTML comments from the template to minimize confusion. Folks that may not be familiar with HTML or Markdown and how they handle comments.
## Changelog
[Internal] - Modify GitHub issue template
Pull Request resolved: https://github.com/facebook/react-native/pull/27842
Test Plan: N/A
Differential Revision: D19629687
Pulled By: hramos
fbshipit-source-id: 25a989ebc04e42e7be234244a9ded48756cb9ba4
Summary:
We can now use `rn_apple_library` to the same effect.
Changelog: [Internal]
Reviewed By: adamjernst
Differential Revision: D19610730
fbshipit-source-id: 98353b062229c192447d1f49e6fe9bdcf12c6a96
Summary:
In case when Platform is different from Android or iOS, ScrollView initialised RCTScrollView two times, which caused a crash. It looks for me that default option is obsolete and can be united with iOS one to fix this issue.
## Changelog:
[Internal] [Fixed] - Fixed crash during ScrollView initialisation if Platform.OS is not iOS or Android
Reviewed By: ejanzer
Differential Revision: D19623046
fbshipit-source-id: 84f8a46ea24b463aa6aae761f4386ab7e4e95f9b
Summary:
This validate function uses the `UIManager.getViewManagerConfig` API to verify if props are supported. Bridgeless mode doesn't support UIManager APIs.
It seems like these `deprecatedPropType` will be removed eventually, so let's ignore it in bridgeless.
Changelog: [Internal] Ignore deprecatedPropType in bridgeless mode
Reviewed By: ejanzer
Differential Revision: D19603819
fbshipit-source-id: 2c744705be8821cc6a9d8daaac3e652987447e4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/27841
Follow up from https://github.com/facebook/react-native/pull/27539 - adding back in the optimization that Detox has in TimersIdlingResource to avoid iterating over the entire timers queue if the next timer is already within the specified range.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19522346
fbshipit-source-id: 32609f434d1ca575a5a49ad630e288c43fa90864
Summary:
Depends on https://github.com/facebook/react-native/issues/27833.
Updates the Flipper version to the most recent release.
## Changelog
[Android] [Changed] - Upgrade Flipper version in default template
Pull Request resolved: https://github.com/facebook/react-native/pull/27837
Test Plan:
This is a bit annoying, but I can't test this against the 0.62-rc.0 version. I tried patching it by running `react-native init --version 0.62.0-rc.0 testproj`, which would fail because of a missing androidx dep. After adding `implementation 'androidx.swiperefreshlayout:swiperefreshlayout:1.0.0'` to the deps, that was fixed but now after updating, `libfbjni.so` is missing because my PR https://github.com/facebook/react-native/issues/27729 isn't part of the RN dependency yet.
Given that this mirrors the RNTester app, I'm pretty confident that the change here is otherwise correct and will work on top of master with the most recent template changes.
Differential Revision: D19619365
Pulled By: passy
fbshipit-source-id: 5723bd105ab3ab86b7f00e1a26e29e1e9dc58290
Summary:
Adds build version and an onPress for the build info.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D19334440
fbshipit-source-id: b201b630086179faca31a08c62019a2019cedf4f
Summary:
Now that react-native has got rid of all the uses of create-react-class, it doesn't need to be listed as a dependency.
## Changelog
[General] [Removed] - Removed create-react-class from dependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/27861
Test Plan: Will hit build break when building bundle if its still needed. Other risks are if community packages are relying on create-react-class in their code, but not declaring it in their dependencies. -- But those packages should fix their dependencies.
Differential Revision: D19568065
Pulled By: cpojer
fbshipit-source-id: be26c3376aaebfa829def12983b04349ba9907ae
Summary:
Here is a mutation test for the Diffing algorithm that we use to diff ShadowNode trees and flatten them. As a side-effect, it also "tests" that Concurrent Yoga does not crash and produces decent cloning requests.
The test works this way:
1. We create a random ShadowNode tree;
2. We create a View tree from that that we continue to maintain;
3. We apply random mutation on this;
4. We layout the tree;
5. We generate the mutation instruction comparing a previous tree with a new one;
6. We apply mutations on the first tree;
7. We generate a new tree from scratch;
8. We compare the new tree with the tree updated with mutations and expect equivalence;
9. Repeat a million times.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19357714
fbshipit-source-id: 04765ede87d91180952ae650ff0d505dfac2ed8e
Summary:
Can be handy for general animation components, like `FancySuspense`.
ChangeLog:
[General][Added] Export LayoutAnimationConfig flow type
Reviewed By: zackargyle, TheSavior
Differential Revision: D19345668
fbshipit-source-id: 26178d1eb0b6f710f652bf82c8095dec5bf5afbd
Summary:
As discussed in https://github.com/facebook/react-native/issues/27863, the following changes were made to modernize the internal default logging function:
- `RCTDefaultLogThreshold` is now set to `RCTLogLevelTrace` in both release and debug builds—the Apple logging system will discard uncollected log entires, while allowing for collection when needed
- `RCTLogLevel` is translated to the appropriate log type
- The log subsystem is "com.facebook.react.log"
- `RCTLogSource` translates to the appropriate category ("native"/"javascript")
- Log the provided message using `os_log_with_type`
Closes https://github.com/facebook/react-native/issues/27863
## Changelog
[iOS] [Changed] - Use Apple unified logging API (os_log)
Pull Request resolved: https://github.com/facebook/react-native/pull/27892
Test Plan:
## From Original PR
Ran a test app in the iOS simulator, and verified that logs are correctly displayed in Console.app as well as using the following command:
```sh
/usr/bin/xcrun simctl spawn booted log stream --level debug --style compact --predicate 'process=="ReactNativeTesterApp" && subsystem=="com.facebook.react.log"'
```
## Peter's Test Plan
1. Apply P125583473
2. Verify log output in Xcode P125583504
3. Apply this diff
4. Verify log output in Xcode P125583597
These appear unchanged, after digging into why, I realized that FB doesn't even use the default log function, we inject a custom one [here](https://fburl.com/diffusion/887a1axs). So this PR shouldn't affect us at all. :)
Differential Revision: D19605414
Pulled By: PeteTheHeat
fbshipit-source-id: 1d70fb702c337a759905d4a65a951a31353ce775
Summary:
Introduces `Rect`, an (eventual) replacement for `EdgeInsetsProp`.
This new type is then used in `Pressability` to expand support such that `hitSlop` and `pressRectOffset` can be either a `Rect` or a numeric size.
Changelog:
[Internal]
Reviewed By: yungsters
Differential Revision: D18742616
fbshipit-source-id: 13dd360f68ab804839938fc950fa2f4b25d3ed8c
Summary:
This was all yungsters idea. I blame him. :)
Switching Pressable to be a functional component presents a new challenge. ReactNativeTestTools can no longer find its instance because there is no instance Pressable uses forwardRef.
We need a way to both find a pressable, and then call the onPress callback if the pressable isn't also disabled.
So in DEV (and thus test) we add the pressable config to a secret key on a function passed onto View. The TestTools look for this key on this function, and then can call onPress.
Super hacky, but so is all of ReactNativeTestTools. We aren't proud of this.
Changelog:
[General][Changed]: Added support for Pressable to ReactNativeTestTools.tap
Reviewed By: yungsters
Differential Revision: D18849358
fbshipit-source-id: ea8880ceedfc04cda217ee17ba140475d003172c
Summary:
When building as a framework these headers get automatically added to the framework umbrella header for React-Core. Instead of converting all the React sources to ObjC++ files and still forcing external users that build native source (and link against a framework build) to also compile as ObjC++, this makes the attribution related methods that were added in https://github.com/facebook/react-native/commit/fdcdca4 opt-in to ObjC++ builds.
This is also the reason for the current failure of the CI `test_ios_frameworks` run.
## Changelog
I’m unsure if this change really warrants an entry in the CHANGELOG, as it’s more of an amendment of the (afaik) unreleased [change](https://github.com/facebook/react-native/commit/fdcdca4).
[iOS] [Fixed] - Make framework builds work again by making `RCTImageLoader` C++ requirement opt-in
Pull Request resolved: https://github.com/facebook/react-native/pull/27730
Test Plan:
I tested static and dynamic (framework) builds and ran the test suite.
This change should make the `test_ios_frameworks` CI run _build_ again, ~~but it may still fail overall as in my local testing one of the tests leads to a segfault (which I will try to address separately)~~.
Reviewed By: PeteTheHeat
Differential Revision: D19348846
Pulled By: fkgozali
fbshipit-source-id: 8a74e6f7ad3ddce2cf10b080b9a5d7b399bd5fc0
Summary:
Changelog: [Internal]
I went over the ownership model in this call `_state->getData().getImageRequest().getImageInstrumentation().didSetImage();`
1. `getData()` returns reference to an object that is copied to state.
2. `getImageRequest()` returns a reference to an object that is strongly owned by `ImageState`.
3. `getImageInstrumentation()` returns a reference to an object that is strongly owned by `ImageRequest`.
I don't think any of these can cause a crash, however `_state` can be nullptr.
Reviewed By: shergin
Differential Revision: D19599258
fbshipit-source-id: 317f03cd9a53d83f64ccbb9f9abfce10fcc1fae5
Summary:
## Context
When a `VirtualizedList` contains a cell which itself contains more than one `VirtualizedList` of the same orientation as the parent list, we log an error if sibling lists in a cell don't have unique `listKey`s (e.g. when the `listKey` prop isn't explicitly set). In release builds, this error does not have a component stack - nor a useful call stack - so it can be hard to track down the true source of the error in complex applications.
## This diff
Here, in addition to the generic error message, we also print the `listKey`, `cellKey` and orientation of each `VirtualizedList` in the hierarchy, from the child list upwards. This is done without significant overhead, by reusing the already-in-place context that `VirtualizedList`s use to manage nesting.
The assumption is that common strategies for deriving `listKey`s and `cellKey`s will make it possible to identify at least some lists in the hierarchy in common cases, and therefore help narrow down the search space even when component stacks are not available.
## Example
(See code in unit test)
```
A VirtualizedList contains a cell which itself contains more than one VirtualizedList of the same orientation as the parent list. You must pass a unique listKey prop to each sibling list.
VirtualizedList trace:
Child (horizontal):
listKey: level2
cellKey: cell0
Parent (horizontal):
listKey: level1
cellKey: cell0
Parent (vertical):
listKey: level0
cellKey: rootList
```
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19600366
fbshipit-source-id: 73f29507ec58a6a3f9b3f6b174a32b21dcd237a1
Summary:
Migrate ReactTextinputManager to support bridgeless mode by accessing the EventDispatcher through the UIManagerHelper instead of from ReactContext.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19456326
fbshipit-source-id: 5e9643793cd764e29964f565db24cdea683ac032
Summary:
Migrating ReactImageView to use the new API for accessing the EventDispatcher (UIManagerHelper.getEventDispatcherForReactTag) that supports bridgeless mode.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D19190765
fbshipit-source-id: a958dfc9c48845270e99f8d378ce034cddc8036f
Summary:
In my app I have a case where I need to pass a very large string (45MB) between JS and native. This is obviously suboptimal, but… this is where I'm at.
The main bottleneck to doing this turned out to be `jsi`'s `JSStringToSTLString()`, which was extremely slow. In my case, 4.7s to execute. After this change, 204ms.
I don't really know C++, so I'm not sure this code is 100% correct and safe, and I bet it could be done even better by avoiding the extra memory allocation (would shave off another 70ms).
## Changelog
[General] [Changed] - Make JSStringToSTLString 23x faster
Pull Request resolved: https://github.com/facebook/react-native/pull/26955
Reviewed By: shergin
Differential Revision: D19578728
Pulled By: motiz88
fbshipit-source-id: 2fbce83166953ce928f0a6aa36eed710bfe05383
Summary:
Changelog: [internal]
1. Creates `ShadowNodeFamily` inside `ComponentDescriptor`.
2. As a side effect of this, we no longer need `ComponentDescriptor::createEventEmitter` so it is removed.
This is a step in order to merge `StateCoordinator` into `ShadowNodeFamily` and use it as target for state updates.
Reviewed By: shergin
Differential Revision: D19514906
fbshipit-source-id: 04ad3c621886be56925acd76f9b35a09d8c5e15a
Summary:
Changelog: [internal]
1. Use `ShadowNode::Shared` instead of `SharedShadowNode`.
2. Initialise `ShadowNodeFamily` before `ShadowNode`.
Why?
This is a step in order to merge `StateCoordinator` into `ShadowNodeFamily` and use it as target for state updates.
Reviewed By: shergin
Differential Revision: D19471399
fbshipit-source-id: 2f67901c901349d238c711f9eeaadb19fe7c1110
Summary:
Changelog: [internal]
1. Moves `ShadowNode::getAncestors` to `ShadowNodeFamily`.
2. Exposes shadowNode's family through `ShadowNode::getFamily()`.
# Why?
This is a first step in order to merge `StateCoordinator` into `ShadowNodeFamily` and use it as target for state updates.
Reviewed By: shergin
Differential Revision: D19465188
fbshipit-source-id: b5a3625aa21c040301259de02beedbf97e11f20e
Summary:
The FBJNI compat issue is gone so this is working now. �
Still a bit ugly to set up, but that's on our ToDo. Next: Template.
## Changelog
[Android] [Fixed] - Use modern Flipper SDK version for RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/27833
Test Plan:
```
./gradlew :RNTester:android:app:installHermesDebug
```
Reviewed By: cpojer
Differential Revision: D19513412
Pulled By: passy
fbshipit-source-id: af118bd364ab316732e2a1e657fa1b682bf7da59
Summary:
`SnapToInterval` is a Float in JavaScript, if we pass it and try to convert it to Int, it crashes in C++.
exception
> libc++abi.dylib: terminating with uncaught exception of type folly::ConversionError: Loss of precision during arithmetic conversion: (long long) 1.15
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19580509
fbshipit-source-id: f705f92953195a9e034f6ce3fe7a077007d5212d
Summary:
Collecting Telemetry is a crucial part of building a performant UI framework; we do that but we need to improve it to make the data more reliable, actionable and trustful.
Now we collect time points as the number of milliseconds from the start of the CLOCK_MONOTONIC epoch. That's fine but it also has problems:
Sometimes a millisecond is an eternity. We have only 16 (or fewer) of them on each frame. What if some operation takes 1ms (according to telemetry) but we have to run it a dozen times? Does it mean that it's 12 ms in total? So, we lack precision.
This is not type-safe. Do you know how many milliseconds in a microsecond? I don't. We multiply that on magical constants hoping that we copied that from some other place right.
The current implementation is not cross-platform. We have ifdefs for iOS and Android and Unix and Windows (which is now implemented).
So, this diff replaces that with using `std::chrono` which is part of the standard library that designed to fix all those concerns. We also define our type-aliases on top of that to express our concrete constrains:
We use `std::chrono::steady_clock` as the base clock which is according to the standard using `clock_gettime(CLOCK_MONOTONIC, ... )` if available. So, it's fast and compatible (the same under the hood) with Android infra.
We use nanoseconds when we store time durations (TelemetryDuration type).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19184569
fbshipit-source-id: 7a44688f4bb3bfc6e3009874f0075c531c8569a1
Emily Janzer
Joshua Gross
Samuel Susla
Peter Argany
Ramanpreet Nara
Moti Zilberman
Pasquale Anatriello
Jason Safaiyeh
David Vacca
Rick Hanlon
Héctor Ramos
Dustin Shahidehpour
Arthur Kushka
Pascal Hartig
REDMOND\acoates
Jesse Katsumata
Frieder Bluemle
Daiki Ihara
Valentin Shergin
Eli White
Spencer Ahrens
Leo Natan
Mike Vitousek
Eloy Durán
Rick Ratmansky
Radek Pietruszewski
Kevin Gozali
