Summary:
Now we tweak more props in order to prepare for new flattening algorithm.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20212254
fbshipit-source-id: 7391155072f93046e78fbecf4bb4b42cb1caacdc
Summary:
This is a part of migration staterted in D19390813.
There is no need to have those as const. The whole *Props object is usually const (and when it's not, props should not be too).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20212255
fbshipit-source-id: 87f3d8e7a94c6626bd9b0fc304f75e915dd73d4c
Summary:
I propose this change because we (and a lot of other people, I'd guess) pass an `async` function as a parameter to `onRefresh`. Because the `async` function returns a `promise`, flow is reporting an error. I think the type checking here can be relaxed either all the way to `any` (because RN does not care here what we return) or to `void | Promise<void>` to account for async functions.
looking at https://github.com/facebook/react-native/commit/fb7b2d353356f67a3149c19ad733d46ec6842767#diff-a9c5687ae65236ba3e7f34bfdcdec81d seems like the second is preferred
## Changelog
[General] [changed] - relax RefreshControl's onRefresh flow typing
Pull Request resolved: https://github.com/facebook/react-native/pull/28167
Test Plan: * flow passes
Reviewed By: hramos
Differential Revision: D20196529
Pulled By: TheSavior
fbshipit-source-id: bb5a314bcfb5fb9c8ab71eccb449f1322aeebacb
Summary:
Changelog: [Internal]
Use LayoutContext to pass `fontSizeMultiplier` down to ParagrapShadowNode.
Reviewed By: shergin
Differential Revision: D20184596
fbshipit-source-id: 3965a127069a21328ed19cb3f9732f0a2d1c4d58
Summary:
In order to build dynamic text sizing, `LayoutableShadowNode::measure` needs to accept `LayoutContext`
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D20184598
fbshipit-source-id: 8928b59d51948caf3654f40049212a89a91dceb6
Summary:
In order to build dynamic text sizing, we need to pass layoutContext to `yogaNodeMeasureCallbackConnector`
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D20184597
fbshipit-source-id: 9df7da4bef8cbad3bc87d63ed0c5aa5f420dbc11
Summary:
This diff fixes the RN Android codegen to support null values for Color typed props.
This was already supported but it recently changed as part of D20169335, when we added the new prop type "color".
changelog: [internal]
Reviewed By: TheSavior
Differential Revision: D20213689
fbshipit-source-id: 42d624de3d1296582f4dcc9c7decd0c02aacca98
Summary:
What's changed:
* `end()` now returns the pointer to the imaginary element after the very last one (which is aligned with STL);
* `erase()` now swaps the removing and the last elements and shrinks the size of an array.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19965405
fbshipit-source-id: 92eedf38d55be35a0d9ab6120634b51c8d6e4674
Summary:
Turns out that dispatchMountItems was reentrant, meaning that something (in particular, updateState) could cause mount items to be queued up which would then be executed synchronously, out-of-order, in the middle of the previous dispatchMountItems call.
We will continue to monitor this and see how often we're reentering: T63181639 and via any soft exceptions that are logged.
For context, there are currently three ways dispatchMountItems gets called: 1) On every UI Tick in the UI thread, in a loop; 2) via animations, via synchronouslyUpdateViewOnUIThread, which happens to fail a *lot* currently; 3) when there is a commit on the UI thread, like with a Java->C++ state update. We must account for reentrance and failure in all three cases and make sure the `mInDispatch` flag is reset after success or failure in all of those situations.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20170160
fbshipit-source-id: 834f1d9b65000caa7f2eea4849e5e7951d2b6be6
Summary:
In heap snapshots, it was found that really large (20 MB) strings representing network data
were being logged as part of `Systrace.beginEvent` strings from `MessageQueue` in DEV mode.
To combat this, use `JSON.stringify` with limits to keep the depth, strings, arrays, and objects
in check.
Changelog: [Internal] Change `stringifySafe` to have max limits on string size
Reviewed By: yungsters
Differential Revision: D20016501
fbshipit-source-id: e123016557bc154e4210e0b4df44360570da8016
Summary:
D19837753 updated the native platforms to support complex color objects however the diff failed to build when going through this code path (as we do at Facebook).
This updates the automatic PropSetter classes to go through the new Color handler.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: mdvacca
Differential Revision: D20169335
fbshipit-source-id: 8eb9c8b48b1840832b3aec9ffcb83c3cf614ce0e
Summary:
$title
Now that the codegen handles the new PlatformColors, regenerating the checked in native component files.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: mdvacca
Differential Revision: D20175914
fbshipit-source-id: fa7b8e5139dcfe06f49582d7810fae12e1e1fb4b
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
Summary:
Tracing isn't supported in OSS builds, so use `hermes/hermes.h` instead
of `hermes_tracing.h` to avoid pulling in any unnecessary dependencies.
Changelog: [Internal]
Reviewed By: dulinriley
Differential Revision: D20201826
fbshipit-source-id: 4c2977db191bb9a1a82310888a435b761629169b
Summary:
This line was and apparently has always been triggered from the
HermesExecutorFactory. We just didn't notice because we didn't build with
assertions.
Changelog: [Internal] Don't crash on load when assertions and Hermes are enabled
Reviewed By: dulinriley
Differential Revision: D20163138
fbshipit-source-id: af672bb51eeb1833f3e27ad9a00921731c345fc5
Summary:
Changelog: [Internal] Throw error when setting Animated value to undefined.
Background:
ReadableNativeMap removes keys that have undefined values. Somewhere some animation is setting the value to be undefined.
Follow up: Find a way to warn generally that undefined values are being set for maps that become ReadableNativeMaps
Reviewed By: JoshuaGross
Differential Revision: D20169325
fbshipit-source-id: 404b727dc238703ebe5f71a0939340d5f1b3b211
Summary:
Bumps `promise` from 7.1.1 to 8.0.3. The package [hasn't changed significantly between these two versions](https://github.com/then/promise/compare/7.1.1...8.0.3). This is part housekeeping, part making it easier to make PRs to `promise` and then upgrade after they're merged.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D20094814
fbshipit-source-id: d8933bd39aa3e9f9b19e4d5a09b0828ecc032085
Summary:
Clearing `props` and `state` (which we don't use) allows avoiding retain cycles.
The memory leak was caused by a retain cycle:
AttributedString -> Fragment -> ShadowView -> PharagraphState -> TextLayoutManager -> Cache -> AttributedString.
We don't use `props` and `state` parts of `ShadowView` inside `AttributedString`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20182791
fbshipit-source-id: 2ddc5d53a1cb594e3d1cc39933e8958eb6425389
Summary:
We recently bumped our engine requirement in https://github.com/facebook/react-native/issues/28174 but are still installing an older Node version.
## Changelog
[Internal] [Fixed] - Install Node 10 as is required for `test_ios_e2e`
Pull Request resolved: https://github.com/facebook/react-native/pull/28199
Test Plan: `test_ios_e2e` should start building again.
Reviewed By: cpojer
Differential Revision: D20170498
Pulled By: hramos
fbshipit-source-id: 59822c50d38307f69824721db36a2c45185dd248
Summary:
Adding `xcscheme` files for iOS template back in. They were removed in https://github.com/facebook/react-native/issues/26471 after https://github.com/facebook/react-native/issues/25451. We have reverted the change on `.gitignore`, as this directory is supposed to be in git, but we didn't revert the removed files. Now they are back as well.
You can also see here that the two files are still missing, they got removed on rc.0 and are still missing on rc.3.
https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.0-rc.3
## Changelog
[iOS] [Changed] - Add `xcscheme` files for iOS template back in.
Pull Request resolved: https://github.com/facebook/react-native/pull/28198
Test Plan: `init` a nre project, and check if the files are there or not. The paths are `ios/MyApp.xcodeproj/xcshareddata/xcschemes/MyApp.xcscheme` and `ios/MyApp.xcodeproj/xcshareddata/xcschemes/MyApp-tvOS.xcscheme`
Reviewed By: cpojer
Differential Revision: D20179447
Pulled By: TheSavior
fbshipit-source-id: b0f08c0f32d6bb7630179bc2fe46d9ac10f6c1d7
Summary:
This diff implements serialization and deserialization of text attachments as part of the calculation of layout of text components
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20087251
fbshipit-source-id: dbcbd22f856aadace14343205548154ea80c8464
Summary:
ez diff to remove TODO to support inlinew Views in Fabric + venice
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20088698
fbshipit-source-id: bd7cbbd76a8c13edf94d4eecac0dd670ccd0d209
Summary:
We are currently unintentionally including both libhermes-executor-release.so
and libhermes-executor-debug.so in all OSS RN builds.
RN tries both in turn, but since they both exist and the release executor is compatible
with the debug build, we always get the release executor without debug functionality.
While we sort this out, switch the load order. Since the debug executor is not compatible
with the release build, so it'll fail to load and try the next one.
ChangeLog: [Android] Fix Hermes debugger being disabled by default
Reviewed By: mhorowitz
Differential Revision: D20163828
fbshipit-source-id: ee4d87f40e42a7c8eedfdb7e1fc17eb3e5966ba5
Summary:
Changelog: [internal]
# Problem
We have node A with N children.
Calling cloning constructor on `YogaLayoutableShadowNode` causes new `yogaNode_` to be created.
However if `fragment.children` is nil in cloning constructor, which basically says children were not changed, then the existing children's `owner` becomes invalid.
# Solution
In the clone constructor, always call `updateYogaChildren`. This updates yoga children with the new `owner`.
Reviewed By: JoshuaGross
Differential Revision: D20139582
fbshipit-source-id: 3932694d4381b601df07dd8a57887ce7c09f1582
Summary:
The sizes of attachments are legit parts of `AttributedString`s identity, so we need to incorporate it into the equality test.
We need that to make measurement cache work correctly with inline views.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20151505
fbshipit-source-id: ae47c24a753eab1e497fcfaa93de557ffb30d874
Summary:
This is a redo of D16969764, with a few extensions.
## Changes
1. Move `RCTDevLoadingView.{h,m}` to `CoreModuels/RCTDevLoadingView.{h,mm}`
2. Extract ObjC API of `RCTDevLodingView` into `RCTDevLoadingViewProtocol` in `ReactInternal`.
3. Create API `RCTDevLoadingViewSetEnabled.h` in `ReactInternal` to enable/disable `RCTDevLoadingView`
Changelog:
[iOS][Added] - Make RCTDevLoadingView TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D18642554
fbshipit-source-id: 6b62e27e128d98254b7a6d018399ec1c06e274fc
Summary:
Make the Android app bundle size report more legible, and update existing reports if possible.
## Changelog
[Internal] [Changed] - Update existing app bundle size report if possible
[Internal] [Changed] - Generate table for APK sizes report
Pull Request resolved: https://github.com/facebook/react-native/pull/28169
Test Plan:
- App bundle size reports should be updated when possible
- Android apk sizes should be reported using a table
Reviewed By: cpojer
Differential Revision: D20141490
Pulled By: hramos
fbshipit-source-id: 3fc1b808b27e893c0a3e4e34eafc39094448799c
Summary:
`nativeId` type is `NSString`, not `NSNumber`. The `.h` file already has the proper type but `.mm` had a wrong one.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D20135465
fbshipit-source-id: e5f9fbf4940d3883334c910f96f0aa850a069d8c
Summary:
This is step 3 in creating a new DevSupportManager with a better async API for loading the JS bundle from Metro.
Right now DevSupportManagerImpl calls a method on its ReactInstanceManagerDevHelper delegate when the JS bundle is done being downloaded from the server. However, I want to move to a callback-based method for bridgeless mode (similar to packager status). In this diff, I'm adding a protected method that uses a callback, and then calling that from `reloadJSFromServer` with a callback that calls the delegate, to preserve existing behavior.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19871102
fbshipit-source-id: 2dbb6b91c5b927df86c3db42aa11e080d57ea78e
Summary:
This is the second step in creating a new DevSupportManager impl with more async-friendly APIs for bundle loading, which I'll use in bridgeless mode. This diff creates a new interface, AsyncDevSupportManager, and two implementations, mirroring what we currently have.
This new interface doesn't define any methods yet.
Changelog: [Android][Changed] Specify DevSupportManager.setPackagerLocationCustomizer in DevSupportManager impls
Reviewed By: mdvacca
Differential Revision: D19870812
fbshipit-source-id: 042a43e1a3055aba6d7325f948060300b5bf17f3
Summary:
This is the first step for adding my own async APIs for DevSupportManager to use in bridgeless mode.
To avoid having to add these APIs to the DevSupportManager interface + both of its implementations, I'm instead splitting DevSupportManager into a base class + final impl so I can more easily share logic with the new impl I'll create.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D19846619
fbshipit-source-id: c67b0231f4e6581fb484f9a4899ed0b7f08fb684
Summary:
We will soon be enforcing that flow suppressions will only apply when on an error's primary location ([post](https://fb.workplace.com/groups/179614562644215/permalink/559286354677032/)). This diff uses the codemod created in D20008770 to move all suppression comments to their primary locations in the `xplat/js` flow root, and deletes suppression comments that are not on any primary locations.
This diff was generated with:
```
~/fbsource/fbcode/flow/packages/flow-dev-tools/bin/tool suppression-primary-locations --json-file ~/www/errors.json ~/fbsource/xplat/js
hg st -n | xargs grep -l -P '@(partially-)?generated' | xargs hg revert
hg st -n | xargs grep -l 'format' | xargs prettier --write
```
Changelog: [Internal]
bypass-lint
Reviewed By: dsainati1
Differential Revision: D20122544
fbshipit-source-id: d94e409aadb18bb399a1ddbf9f3f2494fe4fb54c
Summary:
Looks like there could be cases when the NativeHirearchyManager may be asking if it should animate on a view that has been removed. Adding a null check
Changelog:
[General] [Fixed] - Check null values in shouldAnimate
Reviewed By: makovkastar
Differential Revision: D20063054
fbshipit-source-id: 5b3b1c27b9aba57a592bd8d4e27a970cf0912b5d
Summary:
Run clang-format and add .clang-tidy with `clang-diagnostic-*` to several more directories in order to catch any problems.
Changelog:
[Internal]
Reviewed By: shergin
Differential Revision: D19860169
fbshipit-source-id: 7785aab010c8e6945cc6b5c9b68cb8ee0cdbb7fa
Samuel Susla
Valentin Shergin
Vojtech Novak
David Vacca
Joshua Gross
Riley Dulin
Eli White
Tom Underhill
Will Holen
Luna Wei
Janic Duplessis
Moti Zilberman
Tommy Nguyen
Pavlos Vinieratos
Mihai
Kevin Gozali
Pieter De Baets
Arjan Zuidema
Mo Gorhom
Ramanpreet Nara
Tommy Nguyen
Emily Janzer
Hans Halverson
Ram N
Héctor Ramos
Jason Safaiyeh
