Summary:
This diff initializes the codegen flow parser using a proposal for some new syntaxes in flow file to handle missing information like:
- Float vs Int32
- Bubbling Events vs Direct Events
- Default props
- Codegen options
- Specifying the component name
For a deep dive on the proposal see: https://fb.quip.com/kPYJAjCHxlgO
Note: there are still some todos to follow up with:
- Array props
- Enum props
- Object event arguments
Note also: the parser code is a little rough, I didn't want spend too much time cleaning it up before we agreed on the format
[General][Added] Add codegen flow parser
Reviewed By: cpojer
Differential Revision: D15417733
fbshipit-source-id: dd80887c0b2ac46fdc3da203214775facd204e28
Summary:
Changelog: [Android] [FIXED] - Fix backgroundColor top level prop of TextInput
This diff fixes two issues with the `backgroundColor` top level property of TextInput on Android:
* Now it is possible to set a **string** value for the top-level `backgroundColor` property of TextInput (crashed the app previously):
```
<TextInput backgroundColor="#ffccbb">Hello, React Native</TextInput>
```
* Now it's possible to set an **integer** value for the top-level `backgroundColor` property of TextInput (had no effect previously):
```
<TextInput backgroundColor={0xffccbbff}>Hello, React Native</TextInput>
```
A `customType = "Color"` annotation parameter must be provided for `ReactBaseTextShadowNode.setBackgroundColor(...)` since the color value must be previously processed in JS before sending it over the bridge to the native code. The JS code will parse the color value and return the proper ARGB color integer to the native platforms (https://fburl.com/uqup52tn).
Without providing the custom type for the background color, if a string value is set for the top-level `backgroundColor` property in the JS code, the Android code will crash since it expects an integer value for the color in `ReactBaseTextShadowNode.setBackgroundColor(...)`, but a string will be passed from JS without any conversion and there will be a `ClassCastException` thrown. If an integer value without the alpha component (like `0xffccbb`) is set, the Android native view would get an integer color value with its alpha component set to `0x00`, which means a transparent color.
On a side note: the alpha component of a color must always be set when using an integer value for `backgroundColor` since the JS code, while processing the color type, shifts the rightmost 8 bytes (alpha component) to the leftmost position. If those 8 bytes are not the alpha component, you will get the wrong color in the end. It doesn't seem to be a problem for string values of `backgroundColor` though.
Reviewed By: mdvacca
Differential Revision: D15453980
fbshipit-source-id: f3f5d9c9877cdbce79a67f2ed93ad4589576d166
Summary:
This diff fixes a bug on the update of accessibiltyState prop in RN Android.
In particular, this bug was reproducible when a view has an accessibiltyState = ['disabled'] and there was a state update to set the {accessibiltyState = {null}}. In this scenario, the BaseViewManager.setViewStates method did not update the view with the default values for accessibilityState
Reviewed By: sahrens
Differential Revision: D15446078
fbshipit-source-id: 75f160916e55f0ee469516db2fe9b0a7d4758cd8
Summary:
Right now calling FabricUIManager.addRootView() doesn't actually start running the application on Android. This diff:
1. Removes the #ifndef so that we actually call UIManagerBinding.startSurface() on Android
2. Passes through the JS module name from addRootView so we can render the surface (falls back to an empty string if not provided, which is the current behavior)
3. Adds an option for starting the surface using `RN$SurfaceRegistry` instead of `AppRegistry`, if that global property has been defined in JS. This is used for Venice (bridgeless RN)
Reviewed By: shergin
Differential Revision: D15366200
fbshipit-source-id: 4a506a589108905d4852b9723aac6fb0fad2d86e
Summary:
I just learned about Nuclide's auto-formatting (cmd-shift-c) and started using it in another diff, but I didn't want to pollute the diff with a bunch of formatting changes, so here we are.
I don't know if anyone else uses Nuclide's auto-formatting, or something else - happy to ditch this if that's not how we roll.
Reviewed By: shergin
Differential Revision: D15389601
fbshipit-source-id: e3b20acd073adf3cc7bab1f62d86c5b5dab8c4fc
Summary: Moves relevant JS files to fb internal, removes stuff we don't need in the RN repo any more. Android and iOS will happen in a follow-up.
Reviewed By: rickhanlonii
Differential Revision: D15468419
fbshipit-source-id: 39fffc22f87534e557788e398bbae575043353b6
Summary:
As currently defined, accessibilityStates is an array of strings, which represents the state of an object. The array of strings notion doesn't well encapsulate how various states are related, nor enforce any level of correctness.
This PR converts accessibilityStates to an object with a specific definition. So, rather than:
<View
...
accessibilityStates={['unchecked']}>
We have:
<View
accessibilityStates={{'checked': false}}>
And specifically define the checked state to either take a boolean or the "mixed" string (to represent mixed checkboxes).
We feel this API is easier to understand an implement, and provides better semantic definition of the states themselves, and how states are related to one another.
## Changelog
[general] [change] - Convert accessibilityStates to an object instead of an array of strings.
Pull Request resolved: https://github.com/facebook/react-native/pull/24608
Differential Revision: D15467980
Pulled By: cpojer
fbshipit-source-id: f0414c0ef6add3f10f7f551d323d82d978754278
Summary:
This replaces ToolbarAndroid with a cleaner, but very similar design and paves the path for removing ToolbarAndroid from core.
## Changelog
[Internal] [Removed] - ToolbarAndroid removed from RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/24999
Differential Revision: D15468053
Pulled By: cpojer
fbshipit-source-id: 21a58558b9ec371689bc994c2d888b81cff01126
Summary:
This is another step in moving RN towards standard path-based requires, updating more code to use path-based requires. See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
## Changelog
[General] [Changed] - Replace more Haste imports with path-based imports
Pull Request resolved: https://github.com/facebook/react-native/pull/25001
Differential Revision: D15467829
Pulled By: cpojer
fbshipit-source-id: 58c364bb4c1c757689907d5ed0d0f3fac0e22f3f
Summary:
Set `sizeMultiplier` to `1.0` if default value is `NAN`, otherwise, text cannot show properly.
## Changelog
[iOS] [Fixed] - Add NAN check for text font sizeMultiplier
Pull Request resolved: https://github.com/facebook/react-native/pull/24966
Differential Revision: D15466559
Pulled By: shergin
fbshipit-source-id: 6f8b47eb8e521cb120d7f351cba02dbf1c5411fd
Summary: This diff fixes the flow errors that surfaced from flow-typing DialogManagerAndorid and deleting NativeDialogManagerAndroid. I also migrated all imports of NativeDialogManagerAndorid to import the module from `react-native-implementation.js`.
Reviewed By: fkgozali
Differential Revision: D15440162
fbshipit-source-id: 2fdfb68104bc8ffb93c0c77fe15aacadc182f62f
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
Rick Hanlon
Oleksandr Melnykov
David Vacca
Emily Janzer
Christoph Nakazawa
Marc Mulcahy
Vojtech Novak
Eric Lewis
James Ide
zhongwuzw
Ramanpreet Nara
Uilque Messias
Michał Pierzchała
Spencer Ahrens
Blair Vanderhoof
Jean Regisser
Wojteg1337
michalchudziak
David Aurelio
Héctor Ramos
nossbigg
Tom Underhill
Valentin Shergin
Joshua Gross
Pedro Pessoa