Summary:
no-inline-styles is a false positive more often than not because it fires even when compositing dynamic styles which must be done inline. It's not that big a deal anyway so I'm just turning it off to reduce noise on diffs.
Also removes all existing supressions.
Reviewed By: yungsters
Differential Revision: D15457771
fbshipit-source-id: 44fbd058834e70966b71fbe4eb7af40d6f3a0a57
Summary: As of D14529038, LayoutAnimations can sometimes throw an exception due to the view being null. This can happen when elements are removed/added and is not fixable in product code. This is a temporary fix - the root cause for this issue will be fixed soon.
Reviewed By: lunaleaps
Differential Revision: D15428791
fbshipit-source-id: 41200e572ed7d5d470754792c5576a0ea23fe946
Summary:
## Background
Legacy Cxx NativeModules are implemented as Hybrid classes. Essentially, when a Cxx NativeModule is requested, you instantiate its hybrid class, which then creates a C++ counterpart. Then, the bridge uses the C++ counterpart's `getModule()` method to obtain ownership of the Cxx NativeModule.
## Summary
This diff implements backwards-compability for Cxx NativeModules.
If a Cxx NativeModule implements the `TurboModule` interface, then when the module is requested by name, we:
1. Instantiate its Java hybrid class, createing a C++ counterpart.
3. Obtain the CxxModule from the C++ counterpart using `getModule()` and use it to create a `TurboCxxModule` instance (this forwards all JavaScript method calls to the CxxModule) inside `TurboModuleManager`.
5. Return this `TurboCxxModule` to JS.
Reviewed By: mdvacca
Differential Revision: D15252041
fbshipit-source-id: cdbb62632d7a8735f7687daf62de63df9e3ad2c5
Summary:
## Summary
If the Java instance of a TurboModule is null, then the resultant JS object returned from `TurboModuleRegistry` should also be null.
Reviewed By: mdvacca
Differential Revision: D15253476
fbshipit-source-id: 83a6b9aa97b547aeecf9b285986ad0f5b9e413da
Summary:
## Summary
This diff does a bunch of things:
1. The TurboModule resolution algorithm on Android now supports C++ TurboModules.
2. `SampleTurboCxxModule` is moved from `ReactCommon/turbomodule/samples/platform/ios/` to `ReactCommon/turbomodule/samples` so that both iOS and Android can share it.
3. `CatalystTurboModuleManagerDelegate::getTurboModule(std::string, JSCallInvoker)` now understands and returns `SampleTurboCxxModule`.
Reviewed By: mdvacca
Differential Revision: D15253477
fbshipit-source-id: 3def91911b091f8cf93be17decd245a0499ed718
Summary:
## Summary
People use `ReactPackage` instances to create NativeModules. To make the migration from NativeModule to TurboModule easy, I'm introducing a `TurboModuleManagerDelegate` that understands `ReactPackage`s, and uses them to lookup and create the Java TurboModule objects. This way, we don't have to change the way we declare NativeModules for the migration.
## TurboModule registration
Each application should have its own subclass of `ReactPackageTurboModuleManagerDelegate`. This subclass is a hybrid class with a C++ and a Java part. The Java part can (and probably should) do nothing (for now). The C++ part has to implement the `moduleName -> jni::HostObject` and `moduleName, javaInstance -> jni::HostObject` functions for all TurboModules in the application.
**Use Case: Migrating a NativeModule to TurboModule system**
1. Make the Java NativeModule extend `TurboModule`. (The reason why this doesn't happen automatically is probably because we haven't changed the Java codegen yet).
2. Modify the `moduleName -> jni::HostObject` or `moduleName, javaInstance -> jni::HostObject` functions to return the `TurboModule`.
**Use Case: Adding a new TurboModule**
1. Add the TurboModule to a `ReactPackage` in the application.
2. Modify the `moduleName -> jni::HostObject` or `moduleName, javaInstance -> jni::HostObject` functions to return the TurboModule `jsi::HostObject`.
**Note:** It's also possible to declare TurboModules by overriding the `getModule(String moduleName)` function of `ReactPackageTurboModuleManagerDelegate`. It's not a good idea, because it'll make switching between the NativeModule/TurboModule system difficult.
Reviewed By: mdvacca
Differential Revision: D15209129
fbshipit-source-id: 4b0a303595145be9b19d6f4934f956b91990f859
Summary: `ReactContext.getNativeModule` can be used to access NativeModules. With these changes, it can also be used to instantiate (if necessary) and retrieve a TurboModule.
Reviewed By: mdvacca
Differential Revision: D15167631
fbshipit-source-id: 3cb0d9a4be16cbadebbf6648c3f1481ba26513c3
Summary: Removes a check introduced in D6969537, comparing `totalFlexGrowFactors` and `resolveFlexGrow` to both `0.0` *and* undefined.
Reviewed By: SidharthGuglani
Differential Revision: D15431425
fbshipit-source-id: 13c8f24e1bc8c49496097a6aa78e20ee5d3964a7
Summary:
part of #24875. iOS only it appears, but not really used by RN itself. Should be fine?
## Changelog
[General] [Added] - Add TM spec for KeyboardObserver
Pull Request resolved: https://github.com/facebook/react-native/pull/24881
Reviewed By: fkgozali
Differential Revision: D15391769
Pulled By: rickhanlonii
fbshipit-source-id: 557507f6063b40d1c68ec8739e23b33bc22ade39
Summary:
There is currently no entry point for running the RNTester tests in package.json. This adds a test-ios command which leverages the existing objc-test-ios.sh script.
With this change in place, our documentation for running tests locally can be simplified and made consistent with how JavaScript tests are run (yarn test).
## Changelog
[General] [Added] - Add a test-ios command to run iOS RNTester tests locally
Pull Request resolved: https://github.com/facebook/react-native/pull/24985
Differential Revision: D15449399
Pulled By: cpojer
fbshipit-source-id: 63f7ad653d23c5601a11fc9d27a39b4987fccaad
Summary:
This diff reorganizes some of the code in react-native-codegen as requested in T44120025
There are two new dirs: `scr/cli` and `src/parsers`
```
buck_tests/
src/
cli/
generators/
parsers/
```
We moved anything cli-ish from `buck_tests` to the `src/cli` directory:
```
src/
cli/
combine/
combine_js_to_schema.sh
combine_js_to_schema-cli.js
combine_js_to_schema.js
viewconfigs/
generate-view-configs-cli.js
generate-view-configs.js
generate-view-configs.sh
```
And we created a new `src/parsers` directory that will contain the flow parser and the current schema parser:
```
src/
parsers/
flow/
index.js
schema/
index.js
```
This should organize the code a little better and make it easier to contribute 👍
Reviewed By: cpojer
Differential Revision: D15414264
fbshipit-source-id: 376af2e91def033855f6ed72a9a9cc4369c33c7d
Summary:
Set duration=0 for android keyboard events. Brings actual implementation closer to existing flowtypes, and duration is set to 0 to minimize impact on existing keyboard event consumers.
Follow up to #24947, upon cpojer's [input](https://github.com/facebook/react-native/pull/24947#issuecomment-494681618) :)
## Changelog
[Android] [Added] - Set duration=0 for android keyboard events
Pull Request resolved: https://github.com/facebook/react-native/pull/24994
Differential Revision: D15449394
Pulled By: cpojer
fbshipit-source-id: d43096238bd38d189fbec54fc2d93f17010d9ddb
Summary:
This diff allows generating native events without any arguments with an event like:
```
{
name: 'onEnd',
optional: true,
bubblingType: 'bubble',
typeAnnotation: {
type: 'EventTypeAnnotation',
// note: no argument key
},
},
```
See the snapshot updates in the diff for the native code that will be generated �
Reviewed By: shergin
Differential Revision: D15403791
fbshipit-source-id: 925a49bb477eebb234e181df681f0d6b1d4e8cf1
Summary:
When running the RNTesterIntegrationTests from the XCode IDE or xcodebuild command line, its possible for tests to intermittently fail due to the warning `'Warning: Can\'t call setState (or forceUpdate) on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in the componentWillUnmount method.%s', '\n in RNTesterApp.` .
A setState() call could happen in the AsyncStorage callback after the component had unmounted: presumably because the test ran and concluded before AsyncStorage returned. Changed RNTesterApp.ios.js to maintain a _mounted field that is set and cleared in componentDidMount() and componentWillUnmount() and refrain from calling setState() if the flag is false.
## Changelog
[iOS] [Fixed] - Fixed RNTesterApp to not call setState() after the component has been unmounted.
Pull Request resolved: https://github.com/facebook/react-native/pull/24984
Differential Revision: D15447898
Pulled By: hramos
fbshipit-source-id: b01bc0a40a4f4d548aca0a4bb891ba3f4c8d0612
Summary:
This diff restores the original role of StateData as a dummy class that has only one purpose - designate that there is no state associated with the node.
I believe having an abstract StateData class for all data types is not necessary and actually slightly harmful. And here the reasons:
* Having virtual dispatch enabled for classes introduces some overhead, and it should be used only if it is absolutely necessary. In this case, we don't need to have virtual dispatch enabled for Data classes because it's already enabled for State classes; therefore all virtual resolution is done there and that's sufficient. No need to pay for what we don't need.
* Continuing the previous point, yes, we expect some API being exposed for Data classes (such as `getDynamic`), but introducing a base abstract class for that is *not* an idiomatic C++ solution; in C++ it's by design that most of the template contracts are actually duck-typed. This is a well-known design issue/concern that will be addressed with an effort called "Concepts" in C++20. Anyway, we should not use abstract classes as *only* indication of conformance to some interface.
* StateData does not introduce any convenience. As it is clear from several subclass implementations, we don't really use base methods from it.
* The previous issue actually happens especially because of the interface of StateData class. Consider constructor that accepts `folly::dynamic` and does nothing, it actually useless because it's impossible to use it unless it's called inside superclass's constructor. That's the case because C++ does not support virtual dispatch for constructors (for good).
* Avoiding subclassing StateData counter-intuitively enforces the desired conformance to imaginary interface: it does not compile otherwise.
Reviewed By: JoshuaGross
Differential Revision: D15342338
fbshipit-source-id: 1f04f7fc5247499e7cfc09cd4b3cccffdc0b6b06
Summary:
This PR cleans up some of our GitHub bots. The overall goal is to make the contribution process just a tad nicer.
### analysis-bot
* The bot will continue leaving GitHub Reviews when it finds lint issues, but will abstain from leaving inline comments if they would exceed 5 in number.
* The review comment left by the bot has instructions on how to reproduce the lint issues locally. This will educate PR authors on how to run lint and fix the issues without unnecessarily spamming the PR with 50+ comments, while still providing useful reviews to authors when only a handful of lint issues slip by.
* Code moved to `bots/` directory for ease of discovery and co-location with pull-bot.
* Added `yarn lint-ci` command. This seems like the right choice: it's running `yarn lint` and other linters, and it is only intended to run on CI.
* It's still possible to run `yarn lint-ci` locally, though the script will stop short of posting a review to GitHub unless the necessary envvars are provided.
* Added `yarn shellcheck` command. This can be run locally, though it requires `shellcheck` to be installed.
* Outside of this PR, I added instructions on using shellcheck to https://github.com/facebook/react-native/wiki/Development-Dependencies
* Updated Circle CI config to use these new commands, and streamlined the `analyze_pr` step.
* Documented analysis-bot in `bots/README.md`.
### pull-bot
* Bumped `danger-js` dependency. No breaking changes found in this minor bump from what I can tell.
* Documented pull-bot in `bots/README.md`.
### misc
* PR template: don't use jargon.
## Changelog
[Internal] [Changed] - GitHub Bots cleanup
Pull Request resolved: https://github.com/facebook/react-native/pull/24923
Differential Revision: D15399744
Pulled By: hramos
fbshipit-source-id: 32632e775f8554424072270e3f98542de84bfb8c
Summary:
UIView+ComponentViewProtocol is useless without it. Conformance to the protocol is only purpose of this category.
We didn't run into this issue because we have never used that yet.
Reviewed By: mdvacca
Differential Revision: D15419953
fbshipit-source-id: 84a430397e886c941d35075d9754eae5748c3a3f
Summary:
For some components, we will have state as soon as the ShadowNode is created that may be meaningful. In those cases, ViewManagers should be able to use State to create or preallocate views.
FB: This will be used in following diffs for Litho support.
Reviewed By: mdvacca
Differential Revision: D15343702
fbshipit-source-id: 8fd672251cb88dea662b5cae5a9efc96877d28a9
Summary:
We're working on a custom EditText that supports some rich text editing, and one of the places where our logic has to be different from the textinput provided by RN is the text setting logic:
https://github.com/facebook/react-native/blob/7abfd23b90db08b426c3c91b0cb6d01d161a9b9e/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactEditText.java#L377
However, some of the important members are private and our subclass cannot access them (we work around this now with reflection). It would be nice if we could work with them directly, either using getters and setters or by changing the access. Let me know what you think about this. Thanks.
## Changelog
[Android] [Added] - allow custom maybeSetText logic for ReactEditText subclasses
Pull Request resolved: https://github.com/facebook/react-native/pull/24927
Differential Revision: D15431682
Pulled By: cpojer
fbshipit-source-id: 91860cadac0798a101ff7df6f6b868f3980ba9b1
Summary:
`YGNode::setAndPropogateUseLegacyFlag` was only used for debugging purposes.
Here, we replace it with a free function in `Yoga.cpp`.
Now that we have events, the diffing functionality should go into a separate debugging package and be implemented in terms of an event listener. Let's do that as soon as we can support multiple listeners.
Reviewed By: SidharthGuglani
Differential Revision: D15316863
fbshipit-source-id: db929eba7c2de8aa1550e362dd2c175929c0070e
Summary:
Fixes broken ios/android e2e tests for CI.
Changes:
1. Use `npm pack` instead of `yarn pack` during e2e test
2. Update test string assertions in ios/android e2e tests
3. Use `Step One` as candidate for source code replacement to test for page changes (since the "Welcome to React Native" string exists in the `Header` component instead of being on `App.js`)
## Changelog
[Internal] [Fixed] - Fix ios/android e2e tests
Pull Request resolved: https://github.com/facebook/react-native/pull/24974
Differential Revision: D15431539
Pulled By: cpojer
fbshipit-source-id: 054af2c2fff6bbdb2263c15d7f5cd416aaa507fd
Summary:
This pull request enhances the Keyboard API event emitter for Android upon `keyboardDidHide` by returning a `KeyboardEvent` with a meaningful `endCoordinates` property (instead of emitting a null as of current implementation). This change standardizes the `keyboardDidHide` keyboard event emission across both iOS and Android, which makes it easier for developers to use the API.
In particular, the semantics of `endCoordinates` emitted during the `keyboardDidHide` event on Android will match nicely with semantics of the same event emitted on iOS:
- `screenY` will be height of the screen, as that the keyboard has collapsed to the bottom of the screen
- `screenX` will be 0, as the keyboard will always be flush to the sides of the screen
- `height` will be 0, as the keyboard has fully collapsed
- `width` will be the width of the screen, as the keyboard will always extend to the width of the screen
Also, the flowtypes for `KeyboardEvent` have been further improved and are more explicit to better highlight the different object shapes (see `IOSKeyboardEvent` and `AndroidKeyboardEvent`) depending on the platform.
## Changelog
[Android] [Added] - Return endCoordinates for keyboardDidHide keyboard event
Pull Request resolved: https://github.com/facebook/react-native/pull/24947
Differential Revision: D15413441
Pulled By: cpojer
fbshipit-source-id: aa3998542b7068e9852467038f57310355018379
Summary:
Easy diff to refactor the sComponentNames map out of the FabricUIManager class.
This is a necessary clean-up to perform a slightly major refactor of the Fabric classes
Reviewed By: JoshuaGross
Differential Revision: D15421769
fbshipit-source-id: 3be73a6e20b338c8cea23ef0c88db417df7e3aa9
Summary:
Quick diff to refactor RootTag for surfaceId in Binding.cpp class
This is the first diff to start moving away from rootTag naming in Fabric
Reviewed By: JoshuaGross
Differential Revision: D15421770
fbshipit-source-id: 7bca7782f96be3d7148ee93f5d5a3a54e0d768dd
Summary:
In order to remove the config pointer from nodes, we have to keep track of whether the node is using web defaults.
This information fits into one bit that we can place in padding (i.e. no extra memory needed).
This allows us to get rid of config usage withing `YGNode` with some exceptions:
- `iterChildrenAfterCloningIfNeeded` -- this function will simply receive the configuration, or the cloning callback.
- `setAndPropogateUseLegacyFlag` -- will be removed in D15316863
- in `YGNode::reset` -- will go away utomatically once we remove the config pointer
Reviewed By: SidharthGuglani
Differential Revision: D15391536
fbshipit-source-id: 0fa0d0805c6862bd741fe4a7d9b637ed534f56a4
Summary:
The iOS end-to-end tests are currently broken. I'm disabling them to bring the tests back to green and unblock other PRs, until they can be fixed.
## Changelog
[Internal] [Removed] - Disable iOS e2e test
Pull Request resolved: https://github.com/facebook/react-native/pull/24962
Differential Revision: D15415872
Pulled By: hramos
fbshipit-source-id: 1a146a2eb36d5bf9b4e1f8cc9daf9b3e4d0cfab1
Summary:
Fixes the e2e detox build step by manually overriding `PROJECT_ROOT` for the project's JS bundle build step.
After seeing [quite](https://github.com/facebook/react-native/issues/18472#issuecomment-428996279) [a](https://github.com/facebook/react-native/issues/18472#issuecomment-450485004) [few](https://github.com/facebook/react-native/issues/15432#issuecomment-417310668) [comments](https://stackoverflow.com/a/49506072) suggesting running some variant of the `react-native bundle` manually on your own so as to build the jsbundle required as part of the build step for RNTester project...
The main issue I found was that the working directory in which `react-native-xcode.sh` executed the CLI bundle step was not correct. The `PROJECT_ROOT` was not resolving to the root of the `react-native` project directory, but instead to something to the effect of `/Users/gibson.cheng/IdeaProjects/react-native/../..` - of which of course the build step would not be able to find the `react-native` project to run the build against.
I'm not sure if new generated `react-native` projects require this manual override, so I only applied it to the RNTester project. Reviewers are welcome to correct my understanding and solutioning to this matter :)
hramos, if this works, perhaps there would not be a need to push through with #24936. Also, this contributes to #23561.
## Changelog
[Internal] [Fixed] - Fix build-ios-e2e build step
Pull Request resolved: https://github.com/facebook/react-native/pull/24953
Differential Revision: D15415850
Pulled By: hramos
fbshipit-source-id: baaff09f81f01be4da1608e0b2898d037db35c23
Summary:
Updates the paragraph component to use State instead of Local Data, part of the path to a Fabric TextInput 💯
## Changelog
[General] [Changed] - Fabric: Use State instead of Local Data for Paragraph
Pull Request resolved: https://github.com/facebook/react-native/pull/24873
Differential Revision: D15410979
Pulled By: shergin
fbshipit-source-id: 3c9517d2495a64c4dbd213b6efb5ff55287900e3
Summary: Allows iOS users to prefil from keyboard if they support safari autofill
Differential Revision: D15385599
fbshipit-source-id: 35d8a7a04c44d23d2aa27dffa02035b68818db7a