Summary: Bump eslint-plugin-relay version to 1.3.10 which contains fix for JS errors that blocks enabling the rules.
Reviewed By: kassens
Differential Revision: D17052055
fbshipit-source-id: 74867c16d128d2c0767e92861575ffcbe20370cc
Summary: Convert this to a UIManager command
Reviewed By: TheSavior
Differential Revision: D16973257
fbshipit-source-id: 0e129c17926229fc20d020e3c0e52a36b0b405d2
Summary:
We noticed a repro-able crash in Ride in T52804960 on Android Q due to NaN being passed into setCameraDistance
on View
see Oleg's related post: https://fb.workplace.com/groups/rn.support/permalink/2682537011794897/
It looks like a generic fix or wrapper around View setCameraDistance might be planned in T48580247
But in the meantime, it kind of maybe seems reasonable-ish to say, ~~if the value of an input node is NaN, don't use it in the math for this node?~~ if a one of the inputs for this node evaluates to NaN, update that input node first? But I'm not super familiar with the Animations library so maybe that's not a good idea, idk.
From what I can tell in our specific error, it's coming from an InterpolatedNode A based off an AdditionNode B which tried to add a ValueNode C + a InterpolatedNode D, but D had only just been created and not had it's first update, so it's value was NaN, and so when B runs it's update value of C + NaN means B's new values is also NaN, and A's subsequent update based on that now comes out to NaN. Atleast that's what it seems like based on Log statements.
Reviewed By: olegbl
Differential Revision: D16960177
fbshipit-source-id: 99c8ca35be4b5e99f7c21db6733ebd622ae39d07
Summary:
This Diff is being posted for discussion purposes. It will not be ready to land until React DevTools v4 has been published to NPM.
Update React Native to be compatible with the [new version 4 React DevTools extension](https://github.com/bvaughn/react-devtools-experimental).
**Note that this is a breaking change**, as the version 3 and version 4 backends are **not compatible**. Once this update ships (in React Native) users will be required to update their version of the [`react-devtools` NPM package](https://www.npmjs.com/package/react-devtools). The same will be true for IDEs like Nuclide as well as other developer tools like Flipper and [React Native Debugger](https://github.com/jhen0409/react-native-debugger).
Related changes also included in this diff are:
* Pass an explicit whitelist of style props for the React Native style editor (to improve developer experience when adding new styles).
* Update `YellowBox` console patching to coordinate with DevTools own console patching.
* Also improved formatting slightly by not calling `stringifySafe` for strings (since this adds visible quotation marks).
Regarding the console patching- component stacks will be appended by default when there's no DevTools frontend open. The frontend will provide an option to turn this behavior off though:
{F168852162}
React DevTools will detect if the new version is used with an older version of React Native, and offer inline upgrade instructions:
{F169306863}
**Note that the change to the `RCTEnableTurboModule` will not be included in this Diff**. I've just turned those off temporarily so I can use v8+Chrome for debugging.
Reviewed By: rickhanlonii
Differential Revision: D15973709
fbshipit-source-id: bb9d83fc829af4693e7a10a622acc95a411a48e4
Summary: This diff adds support from `ScrollView::scrollEventThrottle` property on iOS.
Reviewed By: JoshuaGross
Differential Revision: D17000397
fbshipit-source-id: 93f23919a6a2588000c0eeca869171d1036348b6
Summary:
```
Welcome to Gradle 5.6!
Here are the highlights of this release:
- Incremental Groovy compilation
- Groovy compile avoidance
- Test fixtures for Java projects
- Manage plugin versions via settings script
For more details see https://docs.gradle.org/5.6/release-notes.html
```
## Changelog
[Android] [Changed] - Gradle wrapper 5.6
Pull Request resolved: https://github.com/facebook/react-native/pull/26079
Test Plan: Ran build and tests locally.
Differential Revision: D17054310
Pulled By: mdvacca
fbshipit-source-id: de7ba3a6d04058e51b8bc6a21d5a3f828ef8bc25
Summary: This expands the existing FABRIC overlay to also indicate "TM" if turbomodule is active.
Reviewed By: yungsters
Differential Revision: D16999391
fbshipit-source-id: 42eedb697636c1172e595bc7c1ace2a9367a13b8
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: [Android] [Fixed] - Make sure the default accessibility hint is read for buttons on Android.
Reviewed By: PeteTheHeat
Differential Revision: D16974987
fbshipit-source-id: e7b932041f82d41271d9393e651967789c05f38a
Summary:
https://github.com/facebook/react-native/pull/25990 fixed the `forceUpdate` method to actually update the component, but caused the useEffect to fire on every render, causing continuous updates after dimensions changed (e.g. from rotation).
This reworks things a bit to be a bit simpler and more idiomatic so it's not quite as confusing, and fixes the bugs.
## Changelog
[General] [Fixed] - Fix useWindowDimensions hook firing continuously after dimensions change
Pull Request resolved: https://github.com/facebook/react-native/pull/26008
Test Plan:
Aparently the Mobile Home app supports rotation on iOS now, so replaced it's content with the first `DimensionsExample` and confirmed with logging that `useEffect` fires exactly once, on initial mount, but the view still updates as expected when rotated:
https://pxl.cl/Hfds
Reviewed By: yungsters
Differential Revision: D16765269
Pulled By: sahrens
fbshipit-source-id: ef55d8a470dcfe87aa125d4c426bf01cfe0091a7
Facebook:
This technically culminates M8 for iOS in Venice :D
We're now rendering `View` and `Text` completely without the bridge!
Reviewed By: shergin
Differential Revision: D16950332
fbshipit-source-id: f8c896323756411f5ac97586c0d85fdd6e39ed40
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: Adds a way for the app to add information to an exception report before it is sent to native. This API is not final.
Reviewed By: rubennorte
Differential Revision: D16984151
fbshipit-source-id: 8450356d608e05deaed437e2a35094cd16962027
Summary:
Flatlist's `getItemCount` function is frequently called internally by VirtualizedList.
As with other functions, we can remove unnecessary operations with the `numColumns` value.
This makes it much more efficient.
## Changelog
[Internal] [Changed] - Better implementation for getItemCount on FlatList
Pull Request resolved: https://github.com/facebook/react-native/pull/26164
Test Plan: Not required
Differential Revision: D16989335
Pulled By: sahrens
fbshipit-source-id: b0075b2c2aeb9b9d7644c8bb18702a7cca8a4dce
Summary:
This one is fun.
# What?
Previously, the codegen'd constructor for a prop value in CPP was defined like so: `value(convertRawProp(rawProps, "value", sourceProps.value, value))`.
The fourth argument there is the default value of the result of `convertRawProps`. What that is saying is: the default value of `value` is `value` - the default value is itself.
The assumption was that because value is defined as `T value{someDefaultValue}` in the struct, in other words, because it has a default value in the `.h` file, that it will /start out/ being equal to `someDefaultValue`, and then be overridden later optionally, or be set to itself, which should be `someDefaultValue`.
However, that is not how initialization of class members in C++ constructors work. If a class member is in the member initializer list, [then the default value is not set](https://en.cppreference.com/w/cpp/language/initializer_list). That means that if the `defaultValue` as passed is /ever/ used, we incur undefined behavior.
# When is the defaultValue used?
The defaultValue is only used when no prop or a null value is sent from JS to C++: https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/ReactCommon/fabric/core/propsConversions.h?commit=becfded106d706e6028e705d7883483051061e9f&lines=60
In most cases, the `sourceProps.value` is actually used as a fallback (the previous props value). The first time props are ever constructed, `sourceProps` should have valid values since it goes through a different path where only the defaultValues from props.h are used.
# Why wasn't this crashing before?
Most codegen'd properties are ints, floats, doubles, and bools. They might get wacky values, but they won't crash. I wouldn't be surprised if this diff solves some subtle visual or layout bugs, but I have no evidence of this yet.
# How do non-codegen'd props.cpp initialize default values?
Same as this diff does: defaultValue should be explicit everywhere: https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/ReactCommon/fabric/components/scrollview/ScrollViewProps.cpp?commit=2813789c292dfdf1220b88f203af6b33ba9e42de&lines=51
# So... what have we learned?
C++ is tricky!
Reviewed By: yungsters, shergin
Differential Revision: D16955421
fbshipit-source-id: 75bb3f22822299e17df1c36abecdb6ce49012406
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:
@public
The mass majority of RCTUIImageViewAnimated uses are actually for static images. As such, we don't need to create a CADisplayLink.
Reviewed By: shergin
Differential Revision: D16945038
fbshipit-source-id: a7cb63000987d1ea7a8a9b4d596e1e474709d2ac
Summary:
To help determine how severe this issue is, put the fix behind a MC.
We will only pick the parent diff to the RC branch so that the fix immediately goes to master and we don't have to worry about fixing this any further.
Reviewed By: fkgozali
Differential Revision: D16940181
fbshipit-source-id: 91eb08181f82f51aea6a20b3fd489a33bdc0e424
Summary:
@public
CADisplayLink strongly holds onto its target, so you have to use a weak proxy object to pass the target into the CADisplayLink.
Previously we passed a weak-self point (i.e. weakSelf) but this did not have the intended effect, since the pointer to self would still be passed to CADisplayLink, and thus it would hold onto the RCTUIImageViewAnimated strongly.
So is weakSelf doing anything other than using self?
It is but it's very minor and not useful. In the case that the object got de-allocated between assigning self to weakSelf and creating the CADisplayLink, then we would pass a nil target. This is actually impossible though because we are running an instance method, so self is implicitly retained! So semantically it is something different but in practice it is the same as passing self through.
Notes:
* This system was added originally in https://github.com/facebook/react-native/pull/24822
* https://github.com/facebook/react-native/pull/25636 then "enabled" this system by deprecating existing approach
Reviewed By: fkgozali
Differential Revision: D16939869
fbshipit-source-id: 7a0e947896f23aa30ad074d1dcb4d4db7543e00a
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:
add script which proves that new codegen gives a similar code as old one.
How it works?
While creating a rule, it generates file which is bash script returning 1 or 0 depending if result of new and old codegen are the same (it's done by redirecting output of buck's cmd).
How js script works:
1. remove empty lines
2. remove comments
3. remove imports
4. sort lines (cause order of structs might be different so let's sort everything!)
5. remove namespaces (I grouped them in new codegen)
Reviewed By: RSNara
Differential Revision: D16827988
fbshipit-source-id: 0432144161e2dcf8ed4cbe2eeea712d062e3721d
Summary: This catches some errors about hooks being used at the top level in a module
Reviewed By: gaearon
Differential Revision: D16945591
fbshipit-source-id: 116ed24b4394b1f516a2ebcd75977d2ba5c57afb
Summary: In D16805827, I moved ImageLoader to CoreModules. In the process, I migrated usages of `[_bridge moduleForClass:[RCTImageLoader class]]` to `[_bridge moduleForName:@"ImageLoader"]`. These two APIs aren't equivalent, however, since `[_bridge moduleForClass:[RCTImageLoader class]]` by default lazily loads the requested NativeModule, but `[_bridge moduleForName:@"ImageLoader"]` doesn't. So, I had to explicitly set `lazilyLoadIfNecessary` to `YES` in all the call-sites I migrated, to ensure that ImageLoader is correctly initialized when necessary.
Reviewed By: PeteTheHeat
Differential Revision: D16948165
fbshipit-source-id: 434697637dfa5e32de1c398744f9c28c19a6fd94
Summary: Follow pattern laid out by Kevin in D16001262 to convert a Core OSS native module to use TM generated spec.
Reviewed By: RSNara
Differential Revision: D16016391
fbshipit-source-id: f517777be44c68367d786f04c50cf12f240eed00
Summary:
Certain turbomodules set `requiresMainQueueSetup` to true. This is b/c they use some fancy APIs in setup that need main queue.
TurboModuleManager mostly adhered to this restriction, the only case it didn't is when setting bridge. There is possibility that this happens on JS thread, which would crash the app for these certain TM. This diff fixes that.
Reviewed By: RSNara
Differential Revision: D16921644
fbshipit-source-id: 69b2410550360d3ccb03c0b71fb7dfccb889eda4
Summary:
Updates the babel parser to support exports that include flow types
Changelog:
[Internal]
Reviewed By: cpojer
Differential Revision: D16927086
fbshipit-source-id: 526efd911c2492a67f618d2d8ad199a7a5a235ff
Summary: There's an old hack in the C++ code that prevents TextInputs from being rendered by forcing them to render as Views instead. We don't need this anymore.
Reviewed By: shergin
Differential Revision: D16932795
fbshipit-source-id: 347df106f638c2bf936e2312f42bcb9310d72c6d
Summary: Give a more explicit message about why `number` isn't supported
Reviewed By: rickhanlonii
Differential Revision: D16926698
fbshipit-source-id: 292cb13aa11205e1350209178bde1977a2a7ad4c
Summary: When debugging supporting a Fabric component, a redbox was being shown without a title which resulted in an infinite redbox loop, followed by OOM. That isn't helpful so we just safely work around the null title while indicating what happened to aid in debugging.
Reviewed By: lunaleaps
Differential Revision: D16921053
fbshipit-source-id: df1f4a691df0c10de53c91e4a9356a04a9005a97
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: Missing space was causing this to show up as "themoduleForClass".
Reviewed By: shergin
Differential Revision: D16918867
fbshipit-source-id: c4bd19ca873d07e30e3fe8fc2c20277aab2d26d5
Summary: Fixes an issue where we weren't traversing all the way into object properties to find imports we may need
Reviewed By: TheSavior
Differential Revision: D16896674
fbshipit-source-id: f95a4f84e51265962ddfd2aeea9da717df033879
Summary: Adds support for generating structs for object properties that are objects or arrays
Reviewed By: TheSavior
Differential Revision: D16896143
fbshipit-source-id: 6682d047e218fc774c8d0593dc2c66fe73615be7
Summary: Adds a broken fixture for arrays nested inside of objects (fixed in the next diffs)
Reviewed By: TheSavior
Differential Revision: D16896138
fbshipit-source-id: 355a71352a78ca076c1de56304908e664772c200
Summary: Adds a fixture for generating nested array objects (fix is on the next diff)
Reviewed By: TheSavior
Differential Revision: D16858626
fbshipit-source-id: c9543f4f8ecc073fd840edd94d47bdc911eaa69e
Summary: ReadableArray doesn't have a .getFloat, so casting double to floats instead. This is consistent with how the prop conversion happens as well.
Reviewed By: makovkastar
Differential Revision: D16897600
fbshipit-source-id: e8c76558f030d291960b5790a262fa49a9f358e7
Tianyu Yao
Luna Wei
Peter Laraia
Brian Vaughn
Andres Suarez
Valentin Shergin
Frieder Bluemle
Kevin Gozali
Spencer Ahrens
Anda Bereczky
Dulmandakh
André Krüger
Peter Argany
Moti Zilberman
ifsnow
Logan Daniels
glevi@fb.com
Joshua Gross
Eli White
Mehdi Mulani
Rubén Norte
Michał Osadnik
Ramanpreet Nara
Anatolii Shevchenko
Rick Hanlon
SachinTotale
Albert Sun
