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
Summary: Adding this fixture in a standalone diff so it is easier to see the change on the next one.
Reviewed By: JoshuaGross
Differential Revision: D16852439
fbshipit-source-id: 3f167509b78ebb95f31e44fbf40e9551d4a5500b
Summary: The codegen has a bug with arrays that have objects that contain native primitives. This diff adds a fixture to demonstrate that bug. I don't change any behavior in this diff. This is just to make the change in the next diff easier to read.
Reviewed By: JoshuaGross
Differential Revision: D16846290
fbshipit-source-id: 06f477b9e3b77cbc1faee11c78d031b45c094d31
Summary: We weren't adding the local imports recursively as well. This is a similar change as was made when creating the CppHelpers.getImports in D16759170.
Reviewed By: rickhanlonii, JoshuaGross
Differential Revision: D16840667
fbshipit-source-id: 1090a774c9e96798d5900bc0b4bf1be29b3ba090
Summary: This code was added in D2442406 in Sep 2015. We have other ways to track the calls to these methods these days. I'm not even sure if this works anymore and it isn't called anywhere.
Reviewed By: JoshuaGross
Differential Revision: D16833299
fbshipit-source-id: cad70c06b149ed424122a9a464564835e7a877e5
Summary:
Removing default integration of Flipper from OSS till discussions happen.
To enable Flipper, just download the Flipper desktop app and uncomment the line in MainApplication.java. Flipper should automatically connect to your app.
Reviewed By: rickhanlonii
Differential Revision: D6654890
fbshipit-source-id: 692cf04fec3273703c0571d04f0100c0dbb8269b
Summary:
Related to this bug: https://github.com/facebook/react-native/pull/25769
Note I also had to add to the bottom of my podfile because RCTLinking had APPLICATION_EXTENSION_API_ONLY='YES' by default somehow.
```
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['APPLICATION_EXTENSION_API_ONLY'] = 'NO'
end
end
end
```
Pull Request resolved: https://github.com/facebook/react-native/pull/26077
Test Plan: Sandcastle should be sufficient.
Reviewed By: shergin
Differential Revision: D16860356
Pulled By: sammy-SC
fbshipit-source-id: 02cb3fd3f977420ccdc2991f0c3666ab0186b7bf
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
Ram N
Chet Corcos
