Summary:
1. Generated `RCTComponentViewHelpers.h` file was not being exported.
2. argument declaration was within `if RCT_DEBUG` directive which meant in production it was stripped.
changelog: [internal]
Reviewed By: TheSavior
Differential Revision: D18266846
fbshipit-source-id: 4c13b8ee9cf4cb3b7486ba7cfef0c64bc46b2360
Summary:
This diff introduces the flag IS_DEVELOPMENT_ENVIRONMENT that will be used in Fabric to control the logging of props, localData and state ONLY during development.
Using DEBUG mode to control the logging of this kind of data is not enough.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18290351
fbshipit-source-id: cf0824bd15b9f1c509bbb284b85761166099bc42
Summary:
A very common pattern I've seen in RN codebase:
- (instancetype) init {
[[NSNotificationCenter defaultCenter] addObserver:self ...]
}
- (void) dealloc {
[[NSNotificationCenter defaultCenter] removeObserver:self ...]
}
From Apple:
https://developer.apple.com/documentation/foundation/nsnotificationcenter/1413994-removeobserver?language=objc
> If your app targets iOS 9.0 and later or macOS 10.11 and later, you don't need to unregister an observer in its dealloc method.
RN targets iOS9+
Changelog: [Internal][Cleanup] Remove unneeded NSNotification center removeObserver
Reviewed By: shergin
Differential Revision: D18264235
fbshipit-source-id: 684e5f5555cec96b055b13cd83daaeb393f4fac9
Summary:
We are moving away from `setNativeProps` in favour of commands API.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D17765031
fbshipit-source-id: fcfe3fe68abb3e49e2dd7a102db598ade749acde
Summary:
A couple of minor and patch updates to the `eslint-config` package, to avoid warnings and errors with the generated code of the latest RN version templates, such as:
```
warning "react-native-community/eslint-config > eslint-plugin-react@7.12.4" has incorrect peer dependency "eslint@^3.0.0 || ^4.0.0 || ^5.0.0".
warning "react-native-community/eslint-config > eslint-plugin-react-native@3.6.0" has incorrect peer dependency "eslint@^3.17.0 || ^4 || ^5".
```
`yarn check` outputs the following errors:
```
error "react-native-community/eslint-config#eslint-plugin-react-native#eslint@^3.17.0 || ^4 || ^5" doesn't satisfy found match of "eslint@6.6.0"
error "react-native-community/eslint-config#eslint-plugin-react#eslint@^3.0.0 || ^4.0.0 || ^5.0.0" doesn't satisfy found match of "eslint@6.6.0"
```
By adding the missing `"license"` field, from now on this also avoids the following warnings:
```
warning package.json: No license field
warning react-native-community/eslint-config@0.0.6: No license field
```
## Changelog
[General] [Fixed] - Fix eslint-config peer dependency warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/27085
Test Plan:
- Publish current `master` package locally (`0.0.6` is [not published](https://www.npmjs.com/package/react-native-community/eslint-config) yet!)
- Create new RN 0.61.3 project, set `eslint-config` to local package, observe errors/warnings running `yarn`/`yarn check`
- `yarn lint` passes cleanly
- Update dependencies (as in this PR), republish locally
- Update RN test project to new `eslint-config` package, **observe no more errors**
- `yarn lint` still passes cleanly
Differential Revision: D18298733
Pulled By: cpojer
fbshipit-source-id: 9a550365521fbaa4b940bc8c02cbeb345d8900b6
Summary:
Fix `react.gradle`'s handling of the case where a configuration isn't explicitly specified by the parent project - e.g. before importing to `build.gradle` files:
```groovy
apply plugin: 'com.android.application'
// Nothing to define:
// project.ext.react = [
// ]
apply from: "../../node_modules/react-native/react.gradle"
```
This is a _ridiculously_ subtle change but it is nevertheless important, as, combined with other groovy quirks, it can result in an overall misbehaviour of the build script.
### Source of the bug
Currently, when a react build config _isn't_ specified by the user, RN's `react.gradle` falls back to `[]` (i.e. in [this line](https://github.com/facebook/react-native/blob/81a6b6ed3c54498f6f2148c106846352405949bf/react.gradle#L8)). In groovy, `[]` stands for an empty _array_ (actually, an empty `ArrayList` instance). The config, however, is expected to have the nature of a `Map`.
### Effects of the bug
As a bottom line, whenever a configuration isn't specified, the evaluation of [the condition](https://github.com/facebook/react-native/blob/81a6b6ed3c54498f6f2148c106846352405949bf/react.gradle#L184) as to whether the bundling task in question should be enabled, results in the following build-time exception:
```
FAILURE: Build failed with an exception.
* Where:
Script '/Users/...../node_modules/react-native/react.gradle' line: 179
* What went wrong:
A problem occurred configuring project ':app'.
> Could not create task ':app:bundleDebugJsAndAssets'.
> Could not find method enabled() for arguments [[]] on task ':app:bundleDebugJsAndAssets' of type org.gradle.api.tasks.Exec.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 9s
```
I'm not much of a Groovy person, but while digging in, I've learned that it has the following odd attribute to it:
When accessing a non-existing property of an empty `ArrayList` in a bean-like fashion (i.e. as `array.property1` rather than `array.getProperty('property1')`), a new empty array is returned. This only holds true for _empty_ arrays, as illustrated by the following snippet:
```groovy
def emptyArr = []
def arr = [40, 2]
def result1 = (emptyArr.uninitializedProp == null)
println "$result1, ${emptyArr.uninitializedProp}" // ==> false, []"
def result2 = (arr.uninitializedProp == null) // ==> MissingPropertyException
println result2 // Never reached
```
While this whole scheme could be a bug, it's nonetheless effective in both the latest 2.x.x groovy version and in 2.1.0 (which is the oldest one that seems to be available for download nowadays). The point being is that its a behavior that's sticked.
Note that other evaluations of `config` properties (e.g. [lines 10-19](https://github.com/facebook/react-native/blob/81a6b6ed3c54498f6f2148c106846352405949bf/react.gradle#L10)) in the script are not effected by this as they are initially only examined in a boolean form, rather than using a null comparison; "Lucky" for us, empty arrays evaluate to `false`.
### Fix
Simply fallback to a groovy map rather than an array whenever `config` hasn't been specified. Namely, initialize it to `[:]`, which results in a new `HashMap` instance, rather than `[]`.
### Workaround
Until effectively fixed, can be worked-around by explicitly setting config to an empty map before the react gradle script is imported by the user:
```groovy
apply plugin: 'com.android.application'
project.ext.react = [:]
apply from: "../../node_modules/react-native/react.gradle"
```
## Changelog
[Android] [Fixed] - Fix 'Could not create task ':app:bundleDebugJsAndAssets'.' error in project with no react config
Pull Request resolved: https://github.com/facebook/react-native/pull/27101
Test Plan: Mostly regression is required here. I've myself ran this over a project with an empty config and the app has launched successfully in both `release` and `debug` flavors.
Differential Revision: D18298542
Pulled By: cpojer
fbshipit-source-id: 88b4715b75f190003c4813e5324a5094a7779f67
Summary:
Currently we generate Java ViewManager interfaces and C++ classes for iOS regardless whether the component is supported on platform or it isn't. This adds an option to exclude either iOS to Android in order to avoid this.
Changelog: In codegen it is now possible to exclude one or the other platform
Reviewed By: rickhanlonii
Differential Revision: D18217185
fbshipit-source-id: 1c569b92c92a5b991c96b0abdff6b8ed395e449f
Summary:
Updates the return type of `createAnimatedComponent` to reflect the new behavior (where we forward the ref to the internal component).
I also improved the type annotation for `Props` so that we can still enforce that only valid prop names are supplied. (We still do not check the prop values because we do not currently have a good strategy for typing the "animated versions" of those.)
Changelog:
[General] [Changed] - Flow types for Animated components now validates prop names and yields the new component instance.
Reviewed By: TheSavior
Differential Revision: D18290473
fbshipit-source-id: 8c629ab6aff009ebe6dabca1683c99a357869977
Summary:
Changes `createAnimatedComponent` so that a `ref` assigned to an Animated component will now be forwarded to the internal component. Previously, a ref to the internal component was accessed using the `getNode` method. The `getNode` method is now deprecated and will return the same `ref` but show a deprecation error.
Changelog:
[General] [Changed] - Refs on an Animated component are now the internal component. The `getNode` call has been deprecated.
Reviewed By: TheSavior
Differential Revision: D18290474
fbshipit-source-id: 5849809583a17624a89071db8be1282a12caedf3
Summary:
This diff implements an optimization / fix in the mounting layer of Fabric Android to ignore the "deletion" and "creation" of views for the same tag in the same commit.
This operation is adding ~100 ns for every commit (I measured this using a release APK running in a real device). I created a QE to enable / disable this optimization and to measure the performance impact of this change in production
Changelog: Implement optimization in mounting layer of Fabric
Reviewed By: JoshuaGross
Differential Revision: D18279240
fbshipit-source-id: d6fdeb2a9676bcfaf47886893eed5024bf86204b
Summary:
This diff adds a new parameter in Binding class to configure the collapsing of Delete-Create Mounting instructions. This is necessary to fix T55696973.
I'm configuring this in order to measure the cost of this fix in produiction environment.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18279239
fbshipit-source-id: b7743f6364b66d19c9ae7309919926debf574213
Summary:
Deletes `__skipSetNativeProps_FOR_TESTS_ONLY` in favor of a `process.env_NODE_ENV` check (which will be eliminated from production builds).
Changelog:
[General] [Removed] Removed `__skipSetNativeProps_FOR_TESTS_ONLY` from Animated components.
Reviewed By: TheSavior
Differential Revision: D18289739
fbshipit-source-id: 7c1f7a29f2b88821d358227a07eec778773e418a
Summary:
Cleans up all the Jest tests to minimize spurious console output.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D18289690
fbshipit-source-id: cdcecca879b3b85d3dccf9e0ab617ea7dc1e0777
Summary:
Simplifies `Animated` by removing `defaultProps` in favor of composition and a more isolated fix for scroll components.
Changelog:
[Breaking] Removed second defaultProps argument from createAnimatedComponent.
Reviewed By: TheSavior
Differential Revision: D18289648
fbshipit-source-id: 4e91c34297c3231f2bf691da74a7a624ca0b4f29
Summary:
Easy diff to extend logging in FabricUIManager class
Changelog: Add extra logging in Fabric Android
Reviewed By: shergin
Differential Revision: D18277487
fbshipit-source-id: 387bdb4b237bdbdc0d65263c1f125ad5c9e26b18
Summary:
Before this change, all methods `ShadowNode::getComponentHandle()` and `ShadowNode::getComponentHandle()` returned the values directly from a `ComponentDescriptor` (via `ShadowNodeFamily`). Now, we store/cache those values in ShadowNodeFamily object (and ShadowNode's methods use that).
We need that to ensure that calling those methods doesn't access the `ComponentDescriptor` object because it's difficult to guarantee that this object overlives all `ShadowNode`s. This is especially important when we build `ShadowView`s from `ShadowNode`s: this might happen way after the code is already deallocated and the only living objects are MountingTransactionCoordinator and essentially two pointers to root nodes of before and after trees (that still needs to be mounted).
This diff introduces no actual changes in the ownership model.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D18290024
fbshipit-source-id: 4135a277515a84b053fe0d0dde48fba59bf2aae3
Summary:
Expands `TouchableWithoutFeedbackInjection` as `TouchableInjection` for use in testing out new implementations of all five `Touchable.Mixin` components.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D18278876
fbshipit-source-id: d511bdecefe38579f03a9d5ad52011f7cd71f4c0
Summary:
Adds some missing props to the type definition for `View`.
Also, changed some of the callbacks to return `mixed`. (Sometime in the near future, we should align on this for event callbacks.)
Changelog:
[Changed] Revised View Event Callback Types
Reviewed By: TheSavior
Differential Revision: D18278877
fbshipit-source-id: a36d5c1c9b9aed6718bd2abb024700a08a9deaeb
Summary:
Fixes an issue in LogBox that allowed users to try to dismiss warnings/errors when there was a fatal or syntax error up.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18285678
fbshipit-source-id: 9d137fab63405c28b2bfa94a35c11c2f63b6d085
Summary:
I kept on running `USE_FRAMEWORKS=1 update-pods && open RNTesterPods.xcworkspace` and adding missing dependencies until `RNTesterPods` started compiling without failure.
**Note:** I made sure to only commit the podfile changes from `update-pods`, **without** `USE_FRAMEWORKS=1`.
Changelog:
[iOS][Fixed] - Fix all RN Podspecs
Reviewed By: fkgozali
Differential Revision: D18284535
fbshipit-source-id: 44d288ae0e52dd2cbbe26bebe7df73ce05644b5d
Summary:
Original commit changeset: 4b18a931a2e4
The original PR wherein these changes were introduced was problematic. When you expose headers that use C++ from the Yoga podspec, they get automatically imported in the Yoga umbrella file. This causes compilation errors, most likely because it's possible for non-c++ files to import these headers (i.e: RCTConvert.m).
I didn't dig into this too much, but since Fabric still doesn't fully compile in OSS, I think it's reasonable to revert this PR for now. cc Kevin Gozali.
Changelog:
[iOS][Fixed] - Undo Fabric-related podspec change
Reviewed By: fkgozali
Differential Revision: D18284536
fbshipit-source-id: a90454b945af0235424dc56408400cd35efd4e7a
Summary:
Looking at the crash reports from T46487253:
1. This crash happens only with TurboModule-compatible NativeModules.
2. Users who experience this crash are in the TurboModules test group.
Therefore, the crash happens while trying to load TurboModules.
The stack trace of the crash includes [this lookup via the NativeModule system](https://fburl.com/diffusion/vxj9goz5). When TurboModules are enabled, we can only start executing this line if one of two things are true:
1. The TurboModuleRegistry is null in CatalystInstanceImpl.
2. The TurboModuleRegistry isn't null but the NativeModule returned by the TurboModuleRegistry is null.
We can protect against 1 by asserting that when `ReactFeatureFlags.useTurboModules` is `true`, `mTurboModuleRegistry` is not null. Once this check lands, unless there's a race with setting `ReactFeatureFlags.useTurboModules`, we should be able to rule out 1.
Changelog:
[Added][Android] - Assert TurboModuleRegistry isn't null before using it in CatalystInstanceImpl
Reviewed By: PeteTheHeat
Differential Revision: D18211935
fbshipit-source-id: de88c033425c474ef80b73386b7182b1d3bb382f
Summary:
This diff adds Fast Refresh support for dismissing LogBox syntax errors. We don't dismiss all errors because once a syntax error is fixed you'll still want to see the covered fatals, errors, and warnings.
If you actually full reload, then it falls back to the native redbox.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278889
fbshipit-source-id: f109ca1d6c34aa3eda6e434deca66f8ce5e02ce0
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
Summary:
In the next diff we'll introduce syntax errors, which we don't show stackframes for since they don't make sense. This diff removes the Stack Frame section when there are no stack frames available.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278831
fbshipit-source-id: 0a6ad5c3b7fed76123b6ad3ccfc8f3f0b044bda2
Summary:
This diff adds handling to fatal errors such as thrown exceptions by popping them full screen and not allowing the user to dismiss them. They say that they're "Fatal Errors" and explain that "Fatal errors require a reload".
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18257185
fbshipit-source-id: ca051027b19c3cd2410ae59764d7b98a78f08dca
Summary:
Quick diff to avoid the logging of Props, State and localData in Fabric Android.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18277486
fbshipit-source-id: 462335e7dadaab2bd39a8ede6318f52f95dfb53a
Summary:
In previous implementation, `setNativeProps` was called before `render`. These two methods can change value of `selectedIndex` and it matters in which order they arrive in native.
This was fine in Paper because 1st selectedIndex is set from `setNativeProps` with wrong value and then correct value comes from props.
However in Fabric, 1st selectedIndex comes from props (this is the correct one), and 2nd comes from command which has the incorrect value.
changelog: [internal]
Reviewed By: TheSavior
Differential Revision: D18240118
fbshipit-source-id: dca897306d3e858b9175b2f81356c76f5a0f79e2
Summary:
The `StatusBarManager` NativeModule does not have a uniform API on iOS and Android. In particular, the `setStyle` and the `setHidden` methods have an additional parameter on iOS:
```
/**
* - statusBarStyles can be:
* - 'default'
* - 'dark-content'
* - 'light-content'
*/
+setStyle: (statusBarStyle?: ?string, animated: boolean) => void;
/**
* - withAnimation can be: 'none' | 'fade' | 'slide'
*/
+setHidden: (hidden: boolean, withAnimation: string) => void;
```
If we keep the NativeModule spec the same between the two platforms, we'd have to keep the second parameter optional for both methods. This works for `setHidden`, because the second parameter is a string, and optional strings are allowed. However, for `setStyle`, the second parameter is a number, and we don't support optional numbers/booleans on Android in the NativeModule system. If we keep the optional number, then the following check triggers in our RedBox tests on iOS, which makes them fail: https://fburl.com/diffusion/b7adezd9.
So, since the two specs are sufficiently different, I figured that the easiest path forward is to split them apart.
Changelog:
[iOS][Changed] - Separated NativeStatusBarManager into NativeStatusBarManager{IOS,Android}
Reviewed By: PeteTheHeat
Differential Revision: D18214161
fbshipit-source-id: 6fd8b8c5f576244b5b90ee47faa7f50508c5e1d3
Summary:
Using compiler flag -fvisibility=hidden and explicitly setting visibility to default to public methods
#Changelog:
[Internal] [Yoga] Use compiler flag -fvisibility=hidden for reducing yoga binary size
Reviewed By: astreet
Differential Revision: D18029030
fbshipit-source-id: 545e73f9c25f3108fc9d9bb7f08c157dbc8da005
Summary:
We suspect that the re-registration of `ComponentDescriptorProvider`s during Bridge reloading might cause crashes in Fabric core. That happens because the re-registration process replaces already existing and being used ComponentDescriptors in the managed registries with the exact same new ones, which forces old ones to be deallocated and all pointers to them invalid. (On of the fundamental Fabric design decision is that `ShadowNode`s don't own/retain ComponentDescriptors.)
It seems was already indirectly addressed in application code on iOS but still fixing that in the core is valuable.
Android implementation does not use reactive component registration, so it was already fine.
As the follow-up diff, we plan to remove "removing" capabilities from ComponentDescriptorRegistry and ComponentDescriptorProviderRegistry to make it even more future-proof.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18273683
fbshipit-source-id: 7615627842855f078a3fdf3049f5511f59700972
Summary:
This diff finally uses all facilities from the previous diffs to build an implementation of `RCTMountingTransactionObserving` protocol which does *not* require using expensive Objective-C runtime features.
In the coming diffs, we will see how it can/should be used.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18217101
fbshipit-source-id: 34f411dcb527dc81570c2f2833ce13b40e1450db
Summary:
See the comment in RCTMountingTransactionObserving first.
I think we have to add this to the iOS mounting layer to be able reasonably easy implement things like:
* MovableNavigationBar: seems, currently we don't handle the situation when the container was mounted first and the nested scroll view second.
* TTI component: It does not have access to telemetry.
The protocol is meant to replace `RCTSurfacePresenterObserver`.
Changelog: [Internal] Fabric-specific change.
Reviewed By: mdvacca
Differential Revision: D16270107
fbshipit-source-id: 2d4bdb7d0092cc214cc433fc633e41e58f6677df
Summary:
RCTComponentViewClassDescriptor is a pretty much the same as RCTComponentViewDescriptor but for *classes*. RCTComponentViewFactory uses a map of those data structures to create RCTComponentViewDescriptor instances (which reflects the same properties) efficiently.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18217103
fbshipit-source-id: ab7ab6b0712048d0085b61a3604b284b1fb5a68b
Summary:
This diff introduces RCTComponentViewDescriptor - the container for a view and associated with this view properties which mounting infra uses for bookkeeping (and recycling) views.
The previous implementation used raw Objective-C pointers to `UIView`s to store and manipulate them. The new way has a bunch of advantages:
* It allows using high-performant C++ data collections for storing views and their properties (in future diffs).
* The new approach allows us to avoid hacks around NSMapTable (such as ` [_registry setObject:componentView forKey:(__bridge id)(void *)tag];`) that were needed because NSMapTable wasn't designed for our use-case.
* Dealing with `RCTComponentViewDescriptor` which stores a pointer to a view sometimes is actually more efficient than dealing with those pointers themselfs because we can deal with `const &` to a descriptor which does not require a ref-counter bump.
* A new approach is much more flexible, it allows us to store additional data alongside view instances which we will use in coming diffs.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18217102
fbshipit-source-id: 063e6c7df794a2e1fd690c194fb31ad6833eaba7
Summary:
In addition to already exiting method `componentViewByTag`, this diff adds a new one `findComponentViewWithTag` which does pretty much the same thing but returns `nil` in a case when it cannot find a view with a given tag. The first method now returns a non-nullable object, whereas the second (new) one return nullable.
We need this to explicitly designate call-sites that are resilient to such kind of errors, where such errors are expected because of still-existing consistency problems (because of some legacy implementation approaches).
At the same time, for the call-sites where a missing view situation is unrecoverable, we should throw early and stop paying for nullability overhead.
In the future diffs, we will change the internal implementation of the registry where the price for dealing with nullability will be actually meaningful.
This is the first diff on the road to an implementation of `RCTMountingTransactionObserving` protocol.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18217099
fbshipit-source-id: dc50033ecadd43c43c5a65fed62649a1a7acf2b5
Summary:
This method has no any usages.
Changelog: [Internal] Fabric-specific, internal change.
Reviewed By: sammy-SC
Differential Revision: D18217100
fbshipit-source-id: 7aabd9e83413c2a1040bdd6c1510d6e4a4c6446a
Summary:
With tvOS (Apple TV) now residing in a separately maintained fork, this removes the residual props from React Native. This only includes the JavaScript changes. The Objective-C changes will come later.
Specifically, the following props have been removed:
- `isTVSelectable`
- `tvParallaxProperties`
- `tvParallaxShiftDistanceX`
- `tvParallaxShiftDistanceY`
- `tvParallaxTiltAngle`
- `tvParallaxMagnification`
Note that `hasTVPreferredFocus` is still being used by Android TV, so it remains.
Changelog:
[Removed] Apple TV View Props
Reviewed By: TheSavior
Differential Revision: D18266278
fbshipit-source-id: 9d1448bf2f434a74e6eb23c70d3a37971e406768
Summary:
Omitted 'own'.. from 2nd para 3rd line.
Added comma in 3rd line after 'developing tools' under the "Upgrading" topic.
bugfixes>> Bug fixes in 7th line under topic "How to contribute".
## Changelog
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/26879
Differential Revision: D18268598
Pulled By: cpojer
fbshipit-source-id: fa64854cd7fbf049524042effe7a5f4a1d0d6a04
Summary:
Exports these events in a canonical manner so that they can be used in future refactors.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D18257693
fbshipit-source-id: aac40277df8a88224c8df29caa04ffc9a6db0a22
Samuel Susla
David Vacca
Peter Argany
Frieder Bluemle
Amit Davidi
Stanislav
Tim Yung
Valentin Shergin
Dmytro Kasianchuk
Rick Hanlon
Ramanpreet Nara
Sidharth Guglani
Priyanshu2001