Summary:
The documentation in two out of the three variants of `Function::callWithThis` incorrectly stated that the `this` value was to be `undefined` instead of set to `jsThis`, which contradicts the point of the `callWithThis` method existing in the first place. This diff fixes that issue.
Changelog: [General] [Fixed] - Fix documentation comments for HermesJS's `Function::callWithThis` method to accurately reflect how `this` is handled.
Reviewed By: jbower-fb
Differential Revision: D19714074
fbshipit-source-id: 123688c1f7e578d6356bec54604fb6e30f06b0b1
Summary:
Easy diff to add extra logging when Fabric tries to add a view inside a view that is not a ViewGroup
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D19737506
fbshipit-source-id: ecb858820de7befc385e725c45b537359e39c0e7
Summary:
Simple hack to prevent duplicate onLayout events from being emitted to JS.
Because of the addition of State Reconciliation to the Fabric lifecycle (see previous diff), in certain circumstances entire subtrees can be relayed-out many, many times even though they aren't changing. For JS product code that responds to every onLayout and forces a ReactJS tree commit (see: some usages of VirtualizedList) this can cause an async infinite loop of commits and layouts even though the tree and the LayoutMetrics aren't actually changing. Even though nothing is changing, it can still cause serious performance regressions and even some bugs since the internals of various state machines may assume onLayout won't be called many times.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19715280
fbshipit-source-id: d879e24f1c7b1f710ad430b7473aa9293d093dea
Summary:
Flow is moving the react-dom libdef to flow-typed. To prepare for that, we should add `react-dom_v16.x.x` to the react-native library definitions
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D19726257
fbshipit-source-id: b2dcbc938b482b73947cc2683b87229873b573dd
Summary:
Bridgeless mode requires all native modules to be turbomodules. The iOS animated module was converted to TM, but reverted due to perf issues. RSNara is looking into it, but it may be an involved fix. As a short term workaround, to unblock release mode testing of bridgeless mode, use `AnimatedMock`.
Changelog: [Internal] Disable animations in bridgeless mode
Reviewed By: RSNara
Differential Revision: D19729827
fbshipit-source-id: e6c4d89258ec23da252c047b4c67c171f7f21c25
Summary:
Removing the experimental types-first flag from RN templates, until these are properly documented in the docs. See https://github.com/facebook/flow/issues/8279 for context.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D19728257
fbshipit-source-id: 8f7473b9c8383bd1eef76b5733ff3a26e2e554fc
Summary:
React is way better than it used to be...
Changelog: [Internal]
Reviewed By: zackargyle, lunaleaps
Differential Revision: D19421772
fbshipit-source-id: db82b68a0c2f31e9ef7e1875fd9e4bf27ef6295a
Summary:
Adding a `.clang-tidy` to a bunch of dirs under `react-native-github/ReactAndroid` and `react-native-github/ReactCommon`.
I don't want to add a single `.clang-tidy` at the root because we'll need more fine-grained control over what checks are enabled in different parts of the codebase; for example, fabric will and TM will probably have more checks enabled than older parts of the codebase that we're not actively modernizing, and the Hermes team probably wants its own config to be consistent with the rest of their codebase.
Starting off each `.clang-tidy` by only enabling clang-diagnostic; this is just to test that it's working. In the future, we'll work with the community to gradually enable more checks.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19705749
fbshipit-source-id: 979cea053b645ac4a9790340033bfcfb49ca0f97
Summary:
This test has been failing internally because it attempts to access external images during CI execution, which it is blocked from doing. Because Detox synchronizes with the app to make sure network requests and animations are complete before continuing, the test waits indefinitely for these images to be fetched.
This diff makes the following changes
* External images are replaced with fb-hosted images
* Timeout threshold is reduced
* Detox initialization is broken out into two steps to help debug any future instances of this occurring
* If Detox is blocked for over 20 seconds, diagnostic messages will be printed indicating why it's being blocked
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19671592
fbshipit-source-id: 368c683101ed7fc68578fc7758061b31c96c241d
Summary:
This diff refactors Text and Text input components in Fabric to support customizable emojis
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D19679391
fbshipit-source-id: 358aa97064209d28d317ba4ca5fff84245c9b1bb
Summary:
This diff refactors support of emojis in RN classic in order to make it easy to extend support for text input and fabric (as part of this stack)
changelog:[internal]
Reviewed By: JoshuaGross
Differential Revision: D19679394
fbshipit-source-id: 45eff49800b3db281721088f107494005d390fff
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