Summary:
RCTKeyboardObserver only uses the bridge to avoid sending events during a reload. See D6573855 (https://github.com/facebook/react-native/commit/d9c658566a14ce8767d87435264997aa18dd08e4) for reference.
In bridgeless mode, the bridge is expected to always be nil, as the module uses `invokeJS` block to send events instead.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23176990
fbshipit-source-id: 7946c9c2684d7d9ea0a606bad375309a5530a719
Summary:
This adds all the packages we use to the workspace in open source, which means we can change our publish scripts to also publish the packages from the repo every time we publish the main repo. I'll work with somebody from the community on that part.
Note: We do not use `eslint-config-react-native-community` internally and it pulls in a lot of packages we don't need. It is part of the React Native repo because it is used in the RN app template but we may want to choose to move it out into a separate repo at some point.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D23208695
fbshipit-source-id: 02d401721dfdc8bbb2305f8ac3381f1e98c18f1d
Summary:
Changelog:
Some callsites may rely on the assumption that address return by this method does not contain port information. JSLocation saved in NSUserDefault might contain port information, removing it here can prevent the issue for callsites.
Differential Revision: D23240495
fbshipit-source-id: a2edf4abb086fd951dd089331407bd659aad1729
Summary:
This diff updates the directory hierarchy of AndroidTextInput C++ files to be compatible with Android OSS build system
changelog: [internal] Internal
Reviewed By: PeteTheHeat
Differential Revision: D23179390
fbshipit-source-id: 1c52e4f882853799a58d44876cadd392b4a35050
Summary:
This comment shouldn't be committed, and should just be part of the template that generates new BUCK files.
Changelog: [Internal]
Differential Revision: D23225700
fbshipit-source-id: a1728e1a4ac0f3f94c4d1330d489bfae7a76a82d
Summary:
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
This PR aims to migrate the RNTester App to `packages` directory. But is currently, open to inspect the CI issues and resolve the merge conflicts.
Currently done
- Working on iOS
- Working on Android
- Detox Tests working on iOS
Need to work on
- Errors generated by the CI builds
[General] [Changed] - Migrated the RNTester App to the packages directory.
Pull Request resolved: https://github.com/facebook/react-native/pull/29567
Test Plan: It runs on both ios and android for now and the detox iOS builds are working.
Reviewed By: cpojer
Differential Revision: D23034761
Pulled By: rickhanlonii
fbshipit-source-id: e04bb06e1c7ef15d340206090d1575a871b9e6f5
Summary:
`accessibilityElementsHidden` property hides a subtree starting from the node with this prop from VoiceOver and TalkBack, so the node with this prop should form the stacking context (otherwise the children will mount as siblings and the property will not have an effect).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23202220
fbshipit-source-id: d87dfab5f791219551c1eb90cdf3b3fa86f9c51f
Summary:
This diff flattens the hierarchy of Text C++ files.
This is required to integrate Text into RN OSS
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D23173556
fbshipit-source-id: ce90000cae147460aa4ddad55b7c90369fa734a2
Summary:
Partial backout of D23123575 (https://github.com/facebook/react-native/commit/1e4d8d902daca8e524ba67fc3c1f4b77698c4d08). It's causing some crashes and there is a more efficient way of doing it, which I will land in a future diff.
Leaving unused feature-flags in place for now, they'll be used shortly.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23198625
fbshipit-source-id: 6e9cbc6b39898a604b8f4dfccf5a6dd238511a68
Summary:
This diff filters the iOS C++ friles that are generated by the oss-android-codegen script
Also, as part of this diff I'm inlcuding .cpp files into the output.
These files are only used and compiled in Android
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23169268
fbshipit-source-id: 404607f3cd6e59197291ea67701774c9c492a282
Summary:
Logbox inside bridgeless surfaces was crashing and not able to open, this diff should fix it.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23043773
fbshipit-source-id: 6e584f97e53e626b9bfedd6dc997ba6ba8c08b8f
Summary:
Twilight doesn't have TMPerfLogging enabled. However, the TurboModule infra uses the TMPerfLogger java class everywhere, which loads the turbomodulejsijni library on class load. For some reason, this class load doesn't work, and causes Twilight prod to crash.
To mitigate that crash, this diff delays the so load until it's absolutely necessary, which is by the time we call jniEnableCppLogging. This should never be called in Twilight, because it doesn't have TMPerfLogging enabled. Therefore, the crash should disappear on Twilight.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23192072
fbshipit-source-id: b73ece580e4345dbf835b0fc2f7d43b90f202411
Summary:
This parses the JSON schema's aliases and reserved function valye types. It also assigns TypeId correctly now:
* TypeId is an identifier for a specific type, that can be referred by others
* This means only aliases should have TypeId.typeName. Properties' names are not typeNames
* NativeModule spec's typeName is hardcoded to `Spec`, see T71955395
This way, whenever we encounter an `AliasType`, we can just lookup the actual Type by a quick Map lookup with TypeId as the key.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23181432
fbshipit-source-id: 9d0ea17dbf601589d8f3fc1955e0c9406a80e244
Summary:
Every single RN iOS application is initializing this native module on first bundle load, regardless if it is used or not. This wrapperModule makes it lazy.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D23175668
fbshipit-source-id: 0424a62d6c0b4fe7d5ce95f6c96e641a03b5fb2c
Summary:
This diff extends test-react-native-oss-android-legocastle to test the build of RNTester with fabric enabled in Sandcastle
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23141524
fbshipit-source-id: 396dae1c0a23ce03db1053de1627eacb09a6df94
Summary:
This diff reintroduces the CoreComponentsRegistry class to register core components in the RN Tester app.
This class was previously deleted as part of D23091020 (https://github.com/facebook/react-native/commit/7fb1afae7f4b78970463e272b7d4f3230e84887d). Different from a past approach, this diff doesn't use inheritance for Hybrid classes (which seems to bring problems in Android 4 devices)
I'm planning to land this diff after I verify that D23091020 (https://github.com/facebook/react-native/commit/7fb1afae7f4b78970463e272b7d4f3230e84887d) fixed RC (maybe I will wait until sunday's cut)
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23109856
fbshipit-source-id: 5220e522e197f701c782ab5089f9f1036ec90c19
Summary:
This parses the output JSON schema into Java Type's, without any alias resolution. Some parts of the schema have incomplete information, hence a bunch of TODOs in the code expressing the issues.
Notes:
* The type structure here could be implemented in other codegen generators as well (including the RNCodegen.js' generators) for better type safety and correctness. With this exercise, I was able to catch a few issues mentioned above.
* This commit does not produce any Java code with JavaPoet yet, just parsing the schema.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23152891
fbshipit-source-id: 9f774dd98975f7202d3faf11c3fbfb83d4c97f5a
Summary:
Migrating DrawerLayoutAndroid component to use ES6 import
Slowly migrate each file to use es6 import/exports to make this discussion happen
react-native-community/discussions-and-proposals#201 (comment)
## Changelog
[General] [Changed] - Use ES6 import/export syntax for DrawerLayoutAndroid component
Pull Request resolved: https://github.com/facebook/react-native/pull/29639
Test Plan: Manual RNTester for Android
Reviewed By: TheSavior
Differential Revision: D23110137
Pulled By: mdvacca
fbshipit-source-id: a43b4f3981335c9f532185cec8957e46f35aac7b
Summary:
Changelog: [Internal]
This lint is now an error by default, so we no longer need to manually specify it as such in the flowconfig
Reviewed By: gkz
Differential Revision: D23145523
fbshipit-source-id: 6c104563793fbc67c8b15b7310e96d1750d21df3
Summary:
These files or directories no longer exist, so they don't need to be listed as files to be published to npm. The only file that was removed that does exist is the `.flowconfig` file, which should not actually be shipped to npm as projects using Flow would have their own `.flowconfig` file.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D23132479
fbshipit-source-id: dc656d8215c9dac11025902b403c3f6560e62e37
Summary:
Changelog: [internal]
Original commit changeset: 5cb78a3a75a7
In D23151218 (https://github.com/facebook/react-native/commit/dffec8bc7bee4d05b72d19b4efe4aeab980f4cd5) we switched from `ShadowTree::tryCommit` to `ShadowTree::commit` inside `UIManager::updateState`.
It fixes update state being dropped but can cause an infinite loop inside `ShadowTree::commit` because the shadow node that triggered `UIManager::updateState` can been removed before the `updateState` call is dispatched..
Reviewed By: JoshuaGross
Differential Revision: D23155228
fbshipit-source-id: f3339a4e4798880972366d6f894c14a58be1b9b2
Summary:
Changelog: [internal]
In D22940187 (https://github.com/facebook/react-native/commit/774dec1e17f6f250172a6d4d944121b82fa36efb) we introduced a mechanism to retry failed state updates from view layer.
The mechanism fixes an issue where state update is occasionally dropped with background executor enabled.
# Why is state dropped?
The state is dropped because with background executor enabled, it is possible to enter `ShadowTree::tryCommit` for the same tree from 2 different threads at once. One of thread changes `_rootShadowNode` causing the other commit to fail.
The code goes like this:
```
{
Lock mutex
grab reference to `rootShadowNode_` and call it `oldRootShadowNode`
Unlock mutex
}
State reconciliation
Trigger layout
`rootShadowNode_` is untouched in this section.
{
Lock mutex
Check if `oldRootShadowNode` is equal to `rootShadowNode_`, if not, return false signalling failure. Now this is what happens when
state update fails.
..... not relevant
Unlock mutex
}
..... not relevant
```
However, in D22940187 (https://github.com/facebook/react-native/commit/774dec1e17f6f250172a6d4d944121b82fa36efb), we have taken another path. Instead of retrying to commit transaction, client is informed about the failure and it is left up to them to retry. This is correct and works. But I think it is unnecessary to this retry can be done inside UIManager::updateState.
In this diff I call `ShadowTree::commit` (version with retries) in case no `stateUpdate.failureCallback` is provided.
This makes sure that we do retry if state update fails but if Android implements `stateUpdate.failureCallback`, it is left up to view layer to retry.
Eventually we might decide to converge these two approaches.
Reviewed By: shergin
Differential Revision: D23151218
fbshipit-source-id: 5cb78a3a75a754429a8e33bd7736e683e9ed34d4
Summary:
# Summary
In previous diffs earlier in 2020, we made changes to detect and optimize reordering of views when the order of views changed underneath the same parent.
However, until now we have ignored reparenting and there's evidence of issues because of that. Because Fabric flattens views more aggressively, reparenting is also marginally more likely to happen.
This diff introduces a very general Reparenting detection. It will work with view flattening/unflattening, as well as tree grafting - subtrees moved to entirely different parts of the tree, not just a single
parent disappearing or reappearing because of flattening/unflattening.
There is also another consideration: previously, we were generating strictly too many Create+Delete operations that were redundant and could cause consistency issues, crashes, or bugs on platforms that do not handle that gracefully -
especially since the ordering of the Create+Delete is not guaranteed (a reparented view could be created "first" and then the differ could later issue a "delete" for the same view).
Intuition behind how it works: we know the cases where we can detect reparenting: it's when nodes are *not* matched up with another node from the other tree, and we're either trying to delete an entire subtree, or create an entire subtree. For perf reasons, we generate whatever set of operations comes first (say, we generate all the Delete and Remove instructions) and take note in the `ReparentingMetadata` data-structure that Delete and/or Remove have been performed for each tag (if ordering is different, we do the same for Create+Insert if those come first). Then if we later detect a corresponding subtree creation/deletion, we don't generate those mutations and we mark the previous mutations for deletion. This incurs some map lookup cost, but this is only wasteful for commits where a large tree is deleted and a large tree is created, without reparenting.
We may be able to improve perf further for certain edge-cases in the future.
# Why can't we solve this in JS?
Two things:
1. We certainly can avoid reparenting situations in JS, but it's trickier than before because of Fabric's view flattening logic - product engineers would have to think much harder about how to prevent reparenting in the general case.
2. In the case of specific views like BottomSheet that may crash if they're reparented, the solution is to make sure that the BottomSheet and the first child of the BottomSheet is never memoized, so that lifecycle functions and render are called more often; and that in every render, the BottomSheet manually clones its child, so that when the Views are recreated, the child of the BottomSheet has a tag and is an entirely different instance. This is certainly possible to do but feels like an onerous requirement for product teams, and it could be challenging to track down every specific BottomSheet that is memoized and/or hoist them higher in the view hierarchy so they're not reparented as often.
Reviewed By: shergin
Differential Revision: D23123575
fbshipit-source-id: 2fa7e1f026f87b6f0c60cad469a3ba85cdc234de
Summary:
This diff unifies the type and value of USE_FABRIC env variable exposed in Gradle with the USE_CODEGEN env variable
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23145658
fbshipit-source-id: 9575f6b50c7a977254e364037d1417b3b1cdb607
Summary:
Changelog: [Internal]
This lint is now an error by default, so we no longer need to manually specify it as such in the flowconfig. This also gets us ready to remove the lint entirely from Flow.
Reviewed By: gkz
Differential Revision: D23134689
fbshipit-source-id: 683a414bb399b823c65b7f687d25344d3e3ba980
Summary:
This diff fixes an issue in `TextInput` where `TextInputState.currentlyFocusedInputRef` could maintain a ref to a view that no longer exists. This issue was exposed when upgrading React, where cleanups for passive effects are deferred. This change means that `inputRef.current` would no longer reference the host view *to be* destroyed; it would be null because the view was *already destroyed*.
There are two fixes here that would independently fix the bug and fix the issue better together.
First, we convert `useEffect` to `useLayoutEffect`. `useLayoutEffect` is intended to fire synchronously after all host view mutations, and the cleanup function is intended to fire synchronously before the host view is destroyed, similar to the behavior assumed before. This change is now the correct function to use semantically. However, if we made this change without the second then any change in the order the effects fire would surface the same bug.
So second, move the `inputRefValue).blur()` call to the same effect as unregistering. This is because we currently require the `blur` effect to be called to null out `currentlyFocusedInputRef` in addition to calling `unregisterInput`. That makes the semantic ordering of effects in `TextInput` meaningful. Instead, when a TextInput is unregistered we should always `blur` to clear the `currentlyFocusedInputRef`, which will prevent dispatching events to a view that doesn't exist. If we made this change without the first then there's would be a race condition between calling blur on a TextInput and when that TextInput has been unregistered.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23035358
fbshipit-source-id: ab686b8046d85e2becd8b879b0b4b7e69e672754
Summary:
Motivation:
`Invariant Violation: Module AppRegistry is not a registered callable module (calling runApplication).` is an error that happens rarely, and most SO answers end up recommending to use `react-native bundle` to work around. I stumbled upon this error the other day and it took me a while to figure out that the error was caused by the fact that my `entryFile` path was pointing to an existing but invalid file. I figured it would be nice to mention this because I believe this will be a frequent cause of the error.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Changed] - improve "not a registered callable module error message"
Pull Request resolved: https://github.com/facebook/react-native/pull/28913
Test Plan:
tested locally with RNTester, prints
```
[Sun May 17 2020 18:15:55.396] ERROR Invariant Violation: Module AppRegistry is not a registered callable module (calling runApplication). This can happen when the application entry file path is incorrect.
On Android, verify 'getJSMainModuleName()' in 'MainApplication.java' and 'project.ext.react.entryFile' in 'android/app/build.gradle'.
On iOS, verify '- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge' in 'AppDelegate.m' and 'ENTRY_FILE' env. variable passed to 'react-native-xcode.sh' (if any) in 'Build Phases' -> 'Bundle React Native code and images'.
```
in metro logs
Reviewed By: mdvacca
Differential Revision: D23107228
Pulled By: fkgozali
fbshipit-source-id: 0712ed7e593ba96b041578bafdbefcd09a3994b7
Summary:
This new buck target will execute the code gen and copy C++ files to the output directory. This will be used to integrate these files into RN Tester
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23115538
fbshipit-source-id: de4135be697c36cd559edf416986299511c31744
Summary:
JavaGenerator is a Java-based implementation for generating codegen output from the parsed schema file. Right now the output is a hardcoded Java file. In the next commits, proper JavaGenerator impl will be added.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23100171
fbshipit-source-id: 1bef23e3dba4d8c222ebdece0edeb4435d388cd4
David Vacca
Peter Argany
Christoph Nakazawa
Jimmy Zhang
stealthanthrax
Sahil Jain
Valentin Shergin
Samuel Susla
Joshua Gross
Lulu Wu
Ramanpreet Nara
Kevin Gozali
Paige Sun
Agastya Darma
Daniel Sainati
Rick Hanlon
generatedunixname89002005287564
Vojtech Novak
