Summary:
## This diff
- Add a hybird scene tracker that support both native navigation and js navigation
- It also has a filter that bypass loading routes and unrelated routes like log box
- The tracker can provide exactly what surface user is looking at
Changelog: [Internal]
Differential Revision: D19667699
fbshipit-source-id: 600efd05e68bf2702c6c2b1d794e720059f75f81
Summary:
All of our other JS view configs are gated by the `RN$Bridgeless` flag. This one has been behind a DEV flag instead. We've been using it in DEV for a long time now, so it's probably ok to be in prod, but I figured it's better to just be consistent with the rest of the native components, since we only need this for bridgeless.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19669902
fbshipit-source-id: bd28cf84947bfe298efd95ae07e38c2bf4e45091
Summary:
Changelog: [internal]
`ShadowNodeFamily` can be used as target in state updates instead of `ShadowNode`.
Reviewed By: shergin
Differential Revision: D19517428
fbshipit-source-id: 6831357e749239d5afec1dfd2d44a26ca6553e51
Summary:
Changelog: [internal]
Merges all of responsibilities of `StateCoordinator` into `ShadowNodeFamily`.
Reviewed By: shergin
Differential Revision: D19500104
fbshipit-source-id: f31ffded5a840e722fd898eef6a9f52cd2186df7
Summary:
This diff regenerates all Jest inline snapshots (`expect().toMatchInlineSnapshot()`) now that we use Jest 24.9.0 which fixes a longstanding [formatting instability bug](https://github.com/facebook/jest/issues/8424).
This is strictly a formatting change.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D19684238
fbshipit-source-id: 77c1e5fe9d2dfef85dffdcc00056fb439d7d7f84
Summary:
Upgrades Jest to the latest 24.x release, [24.9.0](https://github.com/facebook/jest/blob/master/CHANGELOG.md#2490). This is a minor update as we are already on 24.x across the board.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D19683451
fbshipit-source-id: 12eaeb8b6341d81daf6bdc8f35728967729f291e
Summary:
When an asset is outside of the metro project root, it can lead to relative paths like `/assets/../../node_modules/coolpackage/image.png` as the `httpServerLocation`. This can happen for example when using yarn workspaces with hoisted node_modules.
This causes issues when bundling on iOS since we use this path in the filesystem. To avoid this we replace `../` with `_` to preserve the uniqueness of the path while avoiding these kind of problematic relative paths. The same logic is used when bundling assets in the rn-cli.
CLI part of this PR: https://github.com/react-native-community/cli/pull/939
## Changelog
[General] [Fixed] - Fix resolving assets outside of the project root
Pull Request resolved: https://github.com/facebook/react-native/pull/27932
Test Plan: Tested that an asset in a hoisted node_modules package doesn't show up before this patch and does after in a release build.
Differential Revision: D19690587
Pulled By: cpojer
fbshipit-source-id: 8a9c68af04594ce1503a810ecf2e97ef5bfb8004
Summary:
Add warning messages for Clipboard, SegmentedControlIOS, ProgressViewIOS, ProgressBarAndroid that has been published in community repo.
## Changelog
[General] [Deprecated] - Add deprecation warnings for Clipboard, SegmentedControlIOS, ProgressViewIOS, ProgressBarAndroid.
Pull Request resolved: https://github.com/facebook/react-native/pull/27929
Test Plan: yarn lint
Differential Revision: D19690577
Pulled By: cpojer
fbshipit-source-id: d53fbe9980c5eb2f7b62deb397064aa727d513bd
Summary:
Add warning message for development that is trying to use ToolbarAndroid that has been removed from ReactNative in 0.61
Ref: https://github.com/facebook/react-native/issues/26591
## Changelog
[General] [Deprecated] - Add warning message for trying to use ToolbarAndroid which has been removed from the core.
Pull Request resolved: https://github.com/facebook/react-native/pull/27930
Differential Revision: D19690581
Pulled By: cpojer
fbshipit-source-id: 8e404fe62651fba4940199c74c45270d6e853740
Summary:
This implement the autoFocus functionality natively instead of calling the focus method from JS on mount. This is needed to properly fix the issue described in https://github.com/facebook/react-native/issues/27217, where when using native navigation (UINavigationController) text input focus needs to happen in the same frame transition starts or it leads to an animation bug in UIKit.
My previous attempt fixed the problem only partially and the bug could still happen since there is no guaranty code executed in useEffect will end up in the same frame as the native view being created and attached.
To fix this I added an autoFocus prop to the native component on iOS and in didAttachToWindow we focus the input if it is set. This makes sure the focus is set in the same frame as the view hierarchy containing the input is created.
## Changelog
[iOS] [Fixed] - Add native support for TextInput autoFocus on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/27803
Test Plan:
- Tested that the UI glitch when transitionning to a screen with an input with autofocus no longer happens in my app.
- Tested that autofocus still works in RNTester
- Made sure that onFocus does get called and TextInputState is updated properly
Differential Revision: D19673369
Pulled By: TheSavior
fbshipit-source-id: 14d8486ac635901622ca667c0e61c75fb446e493
Summary:
This is a quite fragile and important part of the render engine. We need to dirty Yoga node only in cases where a change affects layout. In the case of over-dirtying, we can kill performance. In the case of under-dirtying, we can produce an incorrect layout.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596279
fbshipit-source-id: 9f2ac67c44cb35c8ba44be1025b94b7921b74e17
Summary:
This is aligned with all simular changes that we do for `*Props` types (see D19583582 and D19390813).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596281
fbshipit-source-id: 283b89c65504e20a461b12c2d1218325c6621dd8
Summary:
Reasons:
* The name of the method now better represent what it's doing;
* It exposes information about "dirty" state of the node without opening actual `LayoutableShadowNode` protected APIs;
* It's a tiny bit faster now because it checks the flag before calling Yoga.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596282
fbshipit-source-id: 3d87d9d5ba20bb8e360683f149b5ebf90beecd65
Summary:
Follow up to https://github.com/facebook/react-native/issues/27803. To keep consistency between the implementations this also implements autoFocus natively on Android. This will allow removing the JS auto focus logic completely.
## Changelog
[Android] [Fixed] - Implement native TextInput autoFocus on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27924
Test Plan: Test using the TextInput example in RN tester.
Differential Revision: D19674506
Pulled By: TheSavior
fbshipit-source-id: 9cbb517fc69bccd11f5292a1ccb4acea2e3713e9
Summary:
This diff changes the behavior of UIImplementation.resolveViewManager() to return null instead of throwing an exception when trying to find an unexistent viewManager during the computation of constants for view Managers.
The C++/JS code manages exceptions and null results when a view manager doesn't exists, this diff simplifies the way this method operates.
changeLog: [internal]
Reviewed By: rickhanlonii
Differential Revision: D19624423
fbshipit-source-id: df31dcfae9a588bf325b61d529cec6ead59fb19d
Summary:
I hit a crash when testing bridgeless mode in a release build:
Error: Exception in HostFunction: java.lang.NoSuchMethodError: no non-static method "Lcom/facebook/react/modules/core/JavaTimerManager;.createTimer(IJZ)V"
It turns out that `JavaTimerManager.createTimer()` is getting stripped from release builds because it's not referenced in Java at all. Adding `DoNotStrip` annotation to keep it around. The other methods in JavaTimerManager don't need this because they're referenced by TimingModule - this is the only method that's only used directly from C++ by bridgeless mode.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19655519
fbshipit-source-id: 8b9862475986bb84b12d81f73f677cc2e4860c67
Summary:
fbobjc_target_sdk_version is not available in Buck used for OSS, and broke Android CI.
## Changelog
[Android] [Fixed] - Android CI dependency fetch
Pull Request resolved: https://github.com/facebook/react-native/pull/27919
Test Plan: ./scripts/circleci/buck_fetch.sh will successfully run on CI,
Reviewed By: RSNara
Differential Revision: D19663699
Pulled By: fkgozali
fbshipit-source-id: c1f10cfad6c3415c876570139f1af2bcc9e56e4e
Summary:
Previously, users of the TurboModuleManager system would have to `TurboModuleManager.installBindings()` themselves, which synchronously attached the `__turboModuleProxy` function on the JS `global` object.
After these changes, the TurboModuleManager, when created will schedule work on the JS thread to install the global `__turboModuleProxy` function. As long as you create the TurboModuleManager before you run the bundle, we'll install the bindings before any TurboModules are accessed.
Changelog:
[Android][Fixed] - Install TM Bindings on JS thread
Reviewed By: ejanzer
Differential Revision: D19335956
fbshipit-source-id: 967ac2d3a0510392f6f0e42efe79b1a0ff6768c4
Summary:
After D19565499, the `LongLivedObjectCollection` will be cleared on the JS thread when the jsi::Runtime is deleted. This diff makes it so that we never hold strong references to `CallbackWrapper`s in our Android TurboModules infra. Therefore, we can leverage the changes in D19565499 to ensure that our `jsi::Function`s are deleted before the `jsi::Runtime`.
## Caveat
If you delete a TurboModule by itself, it's jsi::Functions that haven't been invoked won't be released. This is also the case for iOS. I plan to fix this for both iOS and Android at a later point in time.
Changelog:
[Android][Fixed] - Refactor jsi::Function cleanup in TurboModules
Reviewed By: mdvacca
Differential Revision: D19589151
fbshipit-source-id: efa3cc6c83634014159ac7500dcf6bef9c925762
Summary:
It makes perfect sense because `Builder` builds totally new shadow trees, so those are not sealed or used by anyone yet.
Assigning it to const shared pointer will do logical sealing (and it does not requires const-cast).
Fewer const-casts in the code, fewer bugs.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596284
fbshipit-source-id: 75d1c706034958ba7e4bc80a68af75a57c46eb6f
Summary:
Before this change `Element<X>` cannot have children of `Element<Y>` which was wrong because we don't have such limitation in Fabric.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596283
fbshipit-source-id: 9002f5dd42b3d05e7cf492499499399c97b58152
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
Yuanzhe Bian
Emily Janzer
Samuel Susla
Moti Zilberman
Janic Duplessis
Jesse Katsumata
Han Lin Yap
Eloy Durán
Ramanpreet Nara
Valentin Shergin
David Vacca
Dulmandakh
Mackenzie Mance
Joshua Gross
Peter Argany
Pasquale Anatriello
Jason Safaiyeh
Rick Hanlon
Héctor Ramos
Dustin Shahidehpour
Arthur Kushka
Pascal Hartig
