Summary: It looks like codegen supports string enums as long as defaults are provided. Uncommenting the enums and removing TODOs.
Reviewed By: rickhanlonii
Differential Revision: D17196139
fbshipit-source-id: a076b1a25eb38b23cfd53fd92e8c42f121d08d6b
Summary:
This diff replaces the usage of UIManagerModule.playTouchSound() in Pressability and Touchable for the SoundManager.playTouchSound()
Previously landed and unladed: D16543433
Reviewed By: rickhanlonii, JoshuaGross
Differential Revision: D17170140
fbshipit-source-id: 33a8ca508ec31f034c76fb0ac4107150d43c608b
Summary:
We added the accessibilityState property as a more semantically rich way for components to describe information about their state to accessibility services. This PR removes the old accessibilityStates property.
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
## Changelog
[General] [Change] - Remove accessibilityStates property.
Pull Request resolved: https://github.com/facebook/react-native/pull/26168
Test Plan: Ensure that RNTester accessibility examples function properly on both iOS and Android.
Differential Revision: D17152891
Pulled By: cpojer
fbshipit-source-id: d71d3cf0f2e0846979d2ba104b6c69e4e5725252
Summary: Flow type for AndroidTextInput. This could theoretically be used for the interface codegen in the future, and I did use this to codegen the scaffolding for AndroidTextInput (see previous diffs).
Reviewed By: mdvacca
Differential Revision: D16926831
fbshipit-source-id: d01c2e041efb4151f6091dd0fea191989d133881
Summary: FlatList and VirtualizedList were typing this value as any instead of using the actual type from ScrollView. I started with that change and then fixed the type to solve the other callsites in the codebase.
Reviewed By: zackargyle
Differential Revision: D17089934
fbshipit-source-id: bfc22cec9993904d779cad37b1de7cb3c0484d2c
Summary:
Reverting D16909622 and D16909622 due to T53098065. This change made TouchableNativeFeedback a bit less resilient to non native components being passed as the child. We probably need to handle this migration a little bit safer.
Original commit changeset: 902528623742
Differential Revision: D17096765
fbshipit-source-id: e3fc1a21504459b6d7ea5442c4bc926bbd77379d
Summary: Convert this to a UIManager command
Reviewed By: TheSavior
Differential Revision: D16973257
fbshipit-source-id: 0e129c17926229fc20d020e3c0e52a36b0b405d2
Summary:
After some thought, we decided we don't need the flexibility of
separate horizontal and vertical props - it would be much nicer
to just have a single prop for the edge length and then the native
code can enable the booleans as appropriate.
Original PR: https://github.com/facebook/react-native/pull/26163
Original commit changeset: f72a9a890d90
Reviewed By: TheSavior
Differential Revision: D16997468
fbshipit-source-id: 7973262287a7ec2cee5957f8dc1806a0f28c1432
Summary:
Move RCTAccessibilityManager to CoreModules (since that's the only dir that supports TM).
Fixup some variable names to match spec.
Reviewed By: RSNara
Differential Revision: D16861739
fbshipit-source-id: a0a53b221dcc172979d1f2c83851ab92e23f2333
Summary:
Instead of dispatching the command with findNodeHandle and the UIManager, go through the new API. This is safe because codegenNativeCommands can work at runtime as well as with the babel transform.
Changelog:
[Internal]
Reviewed By: rickhanlonii
Differential Revision: D16909599
fbshipit-source-id: 90252862374290dbeb7202483fa585b6a7051c12
Summary:
The types we were using before weren't very strict and it had been on my list to fix this. I *think* this is the right type. With Flow's type first project having these exported types will be necessary anyways so we can just use that for the ref.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D16930573
fbshipit-source-id: 05c1e097794633a2cefa7384c9d81ab15a63d8af
Summary: Explicitly define the types of the getters in `react-native-implementation` so we can enable Flow's types-first mode for that file.
Reviewed By: cpojer
Differential Revision: D16937607
fbshipit-source-id: 2e4cf483043a53c5407254ffa2b3211d40211019
Summary: `ProgressBarAndroid` exported the wrong type and Flow wasn't catching some issues with it because they were hidden by a `$FlowFixMe` annotation. This exports the right type and fixes the bad usages.
Differential Revision: D16938853
fbshipit-source-id: 7ea4bbf379a010a76dc68ccb405e1f890d7e590a
Summary: Include AndroidTextInputNativeComponent so we can rely on codegen and flow typing in a future diff.
Reviewed By: TheSavior
Differential Revision: D16903634
fbshipit-source-id: 767d7c854533d641eb7fcb2147bf584621581411
Summary: This error is not actionable or valuable right now.
Reviewed By: cpojer
Differential Revision: D16859423
fbshipit-source-id: b25504a9556b4d3102b35b2bffcd2d01566e0399
Summary:
This pull request moves `Text`'s prop types to the `DeprecatedPropTypes` folder.
This was already partly in progress - there were redundant `TextPropTypes` and `DeprecatedTextPropTypes` files so I removed one, and made sure the version with the doc strings was the one used.
## Changelog
[General] [Deprecated] - Move `Text` component's proptypes to DeprecatedPropTypes
Pull Request resolved: https://github.com/facebook/react-native/pull/26055
Test Plan: Flow checks pass for iOS and Android
Differential Revision: D16801078
Pulled By: TheSavior
fbshipit-source-id: ef19300945d48d0a4a83d728ee32cdf7d1c0f0cc
Summary: This diff replaces the usage of UIManagerModule.playTouchSound() in Pressability and Touchable for the SoundManager.playTouchSound()
Reviewed By: yungsters
Differential Revision: D16543433
fbshipit-source-id: a2ba060bc480889c1e08c5c87086361e06974684
Summary:
This function was used by Touchable*. It was removed from the Touchables in D6494579 in 2017. The only remaining callsite was ImageBackground which is attaching a ref directly to the View so we know it is a native component.
This is needed for some setNativeProps cleanup
Reviewed By: sahrens
Differential Revision: D16796973
fbshipit-source-id: 19379094b3b91920efac4bf1969fc22d4b80bcc6
Summary:
The documentation from the Flow types' respective proptypes have been copied over to `TextInput`.
## Changelog
[Internal] [Changed] - Added documentation to TextInput's Flow types
Pull Request resolved: https://github.com/facebook/react-native/pull/26054
Test Plan: `yarn flow-check-ios` and `yarn flow-check-android` both pass.
Differential Revision: D16801435
Pulled By: TheSavior
fbshipit-source-id: 7f3d75ba149259d5bbf719375320e2e325188826
Summary:
This pull request moves `TextInput`'s proptypes to `DeprecatedTextInputPropTypes`. This is in line with what is happening with other components.
## Changelog
[General] [Deprecated] - Moved `TextInput`'s proptypes to `DeprecatedTextInputPropTypes`
Pull Request resolved: https://github.com/facebook/react-native/pull/26042
Test Plan: Flow checks pass.
Differential Revision: D16782322
Pulled By: cpojer
fbshipit-source-id: c5f9caa402c0c5cd878e7fff502d380c7b468cbd
Summary: We introduced NativeAccessibilityManager a while back. This diff makes sure that there are no usages of NativeModules.AccessibilityManager in our codebase.
Reviewed By: ejanzer
Differential Revision: D16714424
fbshipit-source-id: edebf0f7a0fab615aa1722406f9d538696bd65a0
Summary:
Need to add explicit type annotations in these areas to unblock types-first architecture for Flow. These are locations the codemod could not automatically handle.
I'll call out areas I need a close eye on in the comments.
Reviewed By: panagosg7
Differential Revision: D16659053
fbshipit-source-id: 167dd2abe093019b128676426374c1c62cf71e7f
Summary: The native change to support strings was made in D15912607 on June 21st. Migrating the JS callsites now to start passing strings instead of the constants.
Reviewed By: zackargyle, mdvacca
Differential Revision: D16703569
fbshipit-source-id: cb1d8698df55d2961cde1e2b1fbfcba086a03bb2
Summary:
We are working to remove constants from the view configs.
On June 21st I modified native to support both numbers and strings. D15911323
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D16697916
fbshipit-source-id: f346f37b2e664c2dd49e2a1308a0517f50284e4d
Summary:
`codegenNativeCommands` returns an object with functions for each command that has the previous behavior inside the React Renderer, and the new Fabric logic inside of the Fabric React Native Renderer.
Changelog:
[Internal] - Change AndroidDrawerLayoutNativeComponent to use JS codegen for commands
Reviewed By: rickhanlonii
Differential Revision: D16529887
fbshipit-source-id: 24a5307944a7f62e18482d60d26052fea3be2051
Summary: This diff implements the Turbo Module SoundManager, this will be used by following diffs of the stack
Reviewed By: JoshuaGross
Differential Revision: D16543430
fbshipit-source-id: 34ba545f54b759fe4e49d4e3c5f8867205de907c
Summary:
This diff allows for parsing more flexible AST format.
Reusing logic used for methods, I add similar support for props and commands in components. Now it's possible to define separated type for props and commands in another part of the file.
Also, extracted this method to another file for reusing purposes.
Added tests.
Reviewed By: rickhanlonii
Differential Revision: D16221445
fbshipit-source-id: 21553bf5ade66588dd7dc0320d25333260b0ada9
Summary: It's ok to put VLists in ScrollViews with different scroll directions.
Reviewed By: yungsters
Differential Revision: D16217209
fbshipit-source-id: 7b1c3e93c19867da7414ccda4cda8cc89d25d522
Summary:
We added a test to make sure button and accessibility actions would not have unwanted behavior. Additionally we added support for accessibility actions for all touchables. However we discovered that RCTTextView and possibly anything else that does not derive from RCTView does not support accessibility actions and need to be children off a component that does support it for it to not crash in ios. This became noticeable when TouchableWithoutFeedback only worked if text is a child of view on ios.
In a local branch we where able to modify RCTTextView to support accessibility actions and text no longer needed to be a child of view for it to work.
## Changelog
[General] [Added] - Button test with accessibility actions
[General] [Added] - Support for accessibility actions to all Touchables. With TouchableWithoutFeedback being a special case where text must be a child of view. (See AccessibilityExample.js for an example)
Pull Request resolved: https://github.com/facebook/react-native/pull/25582
Test Plan:
Test plan is testing in RNTester making sure the examples work
## Open Question
What would you say is the best practice for adding accessibility action support for all the components that do not extended from RCTView?
Reviewed By: cpojer
Differential Revision: D16192919
Pulled By: osdnk
fbshipit-source-id: 7d4e186ba1f30393f2b4d08a0e227b960f83586c
Summary:
returning type of Bubbling and Direct Event should be always void of Promise (if async). Other situations shouldn't be permitted.
Reformated all cases when it the function wasn't void.
Reviewed By: rickhanlonii
Differential Revision: D16165962
fbshipit-source-id: 7c1377c3ed4bd54a431a13e5bcda4f7ec0adf4dc
Summary: It's pointless to handle non optional key if value has withDefaul so I'm adding a rule into parser preventing from such cases
Reviewed By: lunaleaps
Differential Revision: D16166709
fbshipit-source-id: 38cef522b217917a3a4886d857720932f2ebb475
Summary:
Using Ricky's last changes I managed to subscribe for both new and old event name.
Fixed event to proper one for codegen in native code.
Reviewed By: TheSavior
Differential Revision: D16065660
fbshipit-source-id: b5d3762d673a34bbdf5a8e60ff4d51617c8adb81
Summary:
`WithDefault` appears not to be required to be prefixed with `?` because it's option value per se.
Fixed tests, removed `?` where needed, updated snapshots and review them. Added mechanism fro throwing error when `?WithDefault` found. Add tests for it.
Reviewed By: rubennorte
Differential Revision: D16048463
fbshipit-source-id: f55ed7454aacf0b8c42944a9b5c1037ad1b360fe
Summary:
This PR adds support for custom `StickyHeaderComponent` to be used in ScrollView (and by extension in FlatList, SectionList..).
Motivation: I've been working on a FlatList with hidable header that has a search field in it. Something like https://medium.com/appandflow/react-native-collapsible-navbar-e51a049b560a but using a FlatList w/ pull-to-refresh. The implementation can be found at https://snack.expo.io/vonovak/hidable-header-flatlist .
I used the `ListHeaderComponent` prop to render the custom header - as opposed to absolute positioning which is used in the linked article because I also need the loading indicator (I added `refreshing` and `onRefresh` for that) to show up above the header.
I proceeded by adding `stickyHeaderIndices={[0]}` to keep the header at the top, which seems to be the idiomatic way to do so. Then I added `Animated.View` with custom translation logic to the rendered header.
All appears to be working fine at the first sight - when you tap any item, you'll see it react to touch (red underlay). You'll also see the header becomes hidden if I scroll far enough and appears again after scrolling up. BUT - when you scroll down so that the header becomes hidden and tap the first visible item in the list, it will not react to touches! The reason is that `ScrollViewStickyHeader`
https://github.com/facebook/react-native/blob/9a84970c35d22b68fb3d8eac019c7f415a14c888/Libraries/Components/ScrollView/ScrollView.js#L984
has its own translation logic and when I tap onto the item at the top of the list, it seems like I'm tapping the item but I'm in fact tapping that `ScrollViewStickyHeader`.
I tried working around this by not specifying `stickyHeaderIndices={[0]}` and using `ListHeaderComponentStyle` prop (this needed some additional changes in https://github.com/facebook/react-native/blob/9a84970c35d22b68fb3d8eac019c7f415a14c888/Libraries/Lists/VirtualizedList.js#L786, and the animation is junky for some reason - as if the header always needed to "catch up" with the scroll offset, causing jitter) and `CellRendererComponent` (junky animations too), but concluded that allowing to specify custom `StickyHeaderComponent` is the cleanest way to make something like this work. I'm slightly surprised I needed to do all this to make such a usual pattern work - am I missing something?
## Changelog
[GENERAL] [ADDED] - allow custom StickyHeader in ScrollView-based components
Pull Request resolved: https://github.com/facebook/react-native/pull/25428
Test Plan: This is a minor change that should not break anything; tested locally.
Differential Revision: D16073016
Pulled By: cpojer
fbshipit-source-id: cdb878d12a426068dbaa9a54367c1190a6c55328
Summary:
It's not needed to keep required providing default values even if they are not actually relevant.
Here I add a support for `null`, `0` of `false` instead by default and remove throwing errors if no other default value provided.
Reviewed By: rubennorte
Differential Revision: D16049047
fbshipit-source-id: bc4961af3873190568f2753fc4ec975354896df5
Summary:
It appears that `(e: BubblingEvent<T>) = mixed` exists only in given context and it's pointless to keep in this way. It could be simplified to `BubblingEventHandler<T>` without any negative consequences and that's the motivation of this diff.
The only tradeoff of this decision is leaving an opportunity to declare Bubbling/Direct event in the top of the file bc then analysing the code becomes much more difficult. However, it's not used anywhere so it's not a problem now and probably any time.
Also, changes the names to `DirectEventHandler` and `BubblingEventHandler` which are more related to current state. The names were updated in many places in code.
Reviewed By: rubennorte
Differential Revision: D16054571
fbshipit-source-id: 741d075eb46b80bac8eb73a6b30fc0b448cb3902