Summary:
X-link: https://github.com/facebook/yoga/pull/1350
Pull Request resolved: https://github.com/facebook/react-native/pull/39170
## This diff
This diff adds a top level `node` directory for code related to Yoga nodes and data structures on them (inc moving `YGLayout` to `LayoutResults`).
The public API for config handles is `YGNodeRef`, which is forward declared to be a pointer to a struct named `YGNode`. The existing `YGNode` is split into `yoga::Node`, as the private C++ implementation, inheriting from `YGNode`, a marker type represented as an empty struct. The public API continues to accept `YGNodeRef`, which continues to be `YGNode *`, but it must be cast to its concrete internal representation at the API boundary before doing work on it.
This change ends up needing to touch quite a bit, due to the amount of code that mixed and matched private and public APIs. Don't be scared though, because these changes are very mechanical, and Phabricator's line-count is 3x the actual amount due to mirrors and dirsyncs.
## This stack
The organization of the C++ internals of Yoga are in need of attention.
1. Some of the C++ internals are namespaced, but others not.
2. Some of the namespaces include `detail`, but are meant to be used outside of the translation unit (FB Clang Tidy rules warn on any usage of these)
2. Most of the files are in a flat hierarchy, except for event tracing in its own folder
3. Some files and functions begin with YG, others don’t
4. Some functions are uppercase, others are not
5. Almost all of the interesting logic is in Yoga.cpp, and the file is too large to reason about
6. There are multiple grab bag files where folks put random functions they need in (Utils, BitUtils, Yoga-Internal.h)
7. There is no clear indication from file structure or type naming what is private vs not
8. Handles like `YGNodeRef` and `YGConfigRef` can be used to access internals just by importing headers
This stack does some much needed spring cleaning:
1. All non-public headers and C++ implementation details are in separate folders from the root level `yoga`. This will give us room to split up logic and add more files without too large a flat hierarchy
3. All private C++ internals are under the `facebook::yoga` namespace. Details namespaces are only ever used within the same header, as they are intended
4. Utils files are split
5. Most C++ internals drop the YG prefix
6. Most C++ internal function names are all lower camel case
7. We start to split up Yoga.cpp
8. Every header beginning with YG or at the top-level directory is public and C only, with the exception of Yoga-Internal.h which has non-public functions for bindings
9. It is not possible to use private APIs without static casting handles to internal classes
This will give us more leeway to continue splitting monolithic files, and consistent guidelines for style in new files as well.
These changes should not be breaking to any project using only public Yoga headers. This includes every usage of Yoga in fbsource except for RN Fabric which is currently tied to internals. This refactor should make that boundary clearer.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D48712710
fbshipit-source-id: d28eae38469afa24a8cb03e4e75eeb8e431173c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39169
X-link: https://github.com/facebook/yoga/pull/1348
## This diff
This diff adds a top level `config` directory for code related to configuring Yoga and Yoga Nodes.
The public API for config handles is `YGConfigRef`, which is forward declared to be a pointer to a struct named `YGConfig`. The existing `YGConfig` is split into `yoga::Config`, as the private C++ implementation, inheriting from `YGConfig`, a marker type represented as an empty struct. The public API continues to accept `YGConfigRef`, which continues to be `YGConfig *`, but it must be cast to its concrete internal representation at the API boundary before doing work on it.
## This stack
The organization of the C++ internals of Yoga are in need of attention.
1. Some of the C++ internals are namespaced, but others not.
2. Some of the namespaces include `detail`, but are meant to be used outside of the translation unit (FB Clang Tidy rules warn on any usage of these)
2. Most of the files are in a flat hierarchy, except for event tracing in its own folder
3. Some files and functions begin with YG, others don’t
4. Some functions are uppercase, others are not
5. Almost all of the interesting logic is in Yoga.cpp, and the file is too large to reason about
6. There are multiple grab bag files where folks put random functions they need in (Utils, BitUtils, Yoga-Internal.h)
7. There is no clear indication from file structure or type naming what is private vs not
8. Handles like `YGNodeRef` and `YGConfigRef` can be used to access internals just by importing headers
This stack does some much needed spring cleaning:
1. All non-public headers and C++ implementation details are in separate folders from the root level `yoga`. This will give us room to split up logic and add more files without too large a flat hierarchy
3. All private C++ internals are under the `facebook::yoga` namespace. Details namespaces are only ever used within the same header, as they are intended
4. Utils files are split
5. Most C++ internals drop the YG prefix
6. Most C++ internal function names are all lower camel case
7. We start to split up Yoga.cpp
8. Every header beginning with YG or at the top-level directory is public and C only, with the exception of Yoga-Internal.h which has non-public functions for bindings
9. It is not possible to use private APIs without static casting handles to internal classes
This will give us more leeway to continue splitting monolithic files, and consistent guidelines for style in new files as well.
These changes should not be breaking to any project using only public Yoga headers. This includes every usage of Yoga in fbsource except for RN Fabric which is currently tied to internals. This refactor should make that boundary clearer.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D48710796
fbshipit-source-id: d548553f7ce872488ebdd697e0aceaa9a625df62
Summary:
X-link: https://github.com/facebook/yoga/pull/1349
Pull Request resolved: https://github.com/facebook/react-native/pull/39171
## This diff
This diff adds a `style` directory for code related to storing and manipulating styles. `YGStyle`, which is not a public API, is renamed to `yoga::Style` and moved into this folder, alongside `CompactValue`. We will eventually add `ValuePool` alongside this for the next generation style representation.
## This stack
The organization of the C++ internals of Yoga are in need of attention.
1. Some of the C++ internals are namespaced, but others not.
2. Some of the namespaces include `detail`, but are meant to be used outside of the translation unit (FB Clang Tidy rules warn on any usage of these)
2. Most of the files are in a flat hierarchy, except for event tracing in its own folder
3. Some files and functions begin with YG, others don’t
4. Some functions are uppercase, others are not
5. Almost all of the interesting logic is in Yoga.cpp, and the file is too large to reason about
6. There are multiple grab bag files where folks put random functions they need in (Utils, BitUtils, Yoga-Internal.h)
7. There is no clear indication from file structure or type naming what is private vs not
8. Handles like `YGNodeRef` and `YGConfigRef` can be used to access internals just by importing headers
This stack does some much needed spring cleaning:
1. All non-public headers and C++ implementation details are in separate folders from the root level `yoga`. This will give us room to split up logic and add more files without too large a flat hierarchy
3. All private C++ internals are under the `facebook::yoga` namespace. Details namespaces are only ever used within the same header, as they are intended
4. Utils files are split
5. Most C++ internals drop the YG prefix
6. Most C++ internal function names are all lower camel case
7. We start to split up Yoga.cpp
8. Every header beginning with YG or at the top-level directory is public and C only, with the exception of Yoga-Internal.h which has non-public functions for bindings
9. It is not possible to use private APIs without static casting handles to internal classes
This will give us more leeway to continue splitting monolithic files, and consistent guidelines for style in new files as well.
These changes should not be breaking to any project using only public Yoga headers. This includes every usage of Yoga in fbsource except for RN Fabric which is currently tied to internals. This refactor should make that boundary clearer.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D48710084
fbshipit-source-id: 20961aee30d54a6b0d8c1cc2976df09b9b6d486a
Summary:
This partially reverts commit 58adc5e4b9.
Using an absolute path in a podspec is wrong, and causes checksum issues when installs are ran on different systems.
Example:
`pod install --deployment --clean-install` breaks on non-matching checksums on CI because the absolute path is not the same in that environment.
```
Adding spec repo `trunk` with CDN `https://cdn.cocoapods.org/`
Verifying no changes
[!] There were changes to the lockfile in deployment mode:
SPEC CHECKSUMS:
React-debug:
New Lockfile: 419922cde6c58cd5b9d43e4a09805146a7dd13a8
Old Lockfile: 1ce329843d8f9a9cbe0cdd9de264b20e89586734
React-NativeModulesApple:
New Lockfile: a683b0c999e76b7d15ad9d5eaf8b6308e710a93e
Old Lockfile: f82356d67a137295d098a98a03be5ee35871b5a5
React-runtimescheduler:
New Lockfile: 79f8dff11acbe36aaeece63553680d7a8272af96
Old Lockfile: 16c5282d43a0df50d7c68ebf0218aeeb642a7086
React-utils:
New Lockfile: 4fabb3cba786651e35bc41e610b0698fa24cecff
Old Lockfile: e7e9118d0e85b107bb06d1a5f72ec5db6bddb911
ReactCommon:
New Lockfile: af30fb021799e18c85a8e30ce799e15607e82212
Old Lockfile: f04f86f33c22e05dbf875789ea522ee486dace78
```
And even tho the change fixed an issue with pnpm, the issue it introduces with cocoapods I think is a bigger one.
## Changelog:
[INTERNAL] - Revert commit that makes podfile unstable
Pull Request resolved: https://github.com/facebook/react-native/pull/39177
Test Plan: Tested locally that the hashes are stable
Reviewed By: NickGerleman
Differential Revision: D48773887
Pulled By: cipolleschi
fbshipit-source-id: 96bcdbadc17a24fa9a8669f569d004bee6a03521
Summary:
Note: this PR is related only to testing mocks provided by RN, and does not affect runtime code.
When building new Jest matchers for React Native Testing Library (https://github.com/callstack/react-native-testing-library/issues/1468) I've noticed that when rendering React Native in Jest using React Test Renderer the mocked `Modal` component renders host `Modal` element when `visible={false}`.
This seems to be incorrect as only visible modal should render any host elements. Not visible one should not render any host element even empty ones. Current mock implementation also contradicts the behaviour of non-mocked `Modal` which does not render `RCTModalHostView` in such case.
## Changelog:
[General] [Fixed] - Do not render mocked <Modal /> when `visible=false`
Pull Request resolved: https://github.com/facebook/react-native/pull/39157
Test Plan:
I've added test showing that non-mocked Modal renders to `null` and modifies the existing tests so that mocked Modal also renders to `null.`
Luna: I've updated relevant snapshots
Reviewed By: NickGerleman
Differential Revision: D48728277
Pulled By: lunaleaps
fbshipit-source-id: cf06495ad959e2d9549241b57f46f75d7beb9eae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39164
getNativeModuleIterator is not required to be public, reducing visibillity to package only
changelog: [internal] intenral
Reviewed By: arushikesarwani94
Differential Revision: D48691698
fbshipit-source-id: d319e7038b0307f1a474bdd449f3c50fd4f07f71
Summary:
## Changelog:
[Internal] -
This replaces object literal return types in `getConstants()` for core RN native modules with type aliases.
This is a valid change from the point of view of binary compatibility between native/JS, and provides a couple of benefits, such as clearer code in general, but also ability to employ C++ codegen for the corresponding types and their marshalling.
bypass-github-export-checks
Reviewed By: christophpurrer
Differential Revision: D48685992
fbshipit-source-id: f21358b12448d30a7b5e25e81f62ef77964d1fcd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38872
## Changelog:
[iOS][Breaking] - RCTTurboModuleRegistry is unavailable in RCTRootView and RCTSurfaceHostingProxyRootView
now after all the diffs in this stack, we can finally decouple the root views from the module registry, and remove the dependency from fabric root views on bridge.
for what i'm breaking, i only found this module library: https://github.com/flyskywhy/react-native-blob-util/blob/3d5155e11426fa458a9e2dbf7fe691cf9863ff01/ios/ReactNativeBlobUtil/ReactNativeBlobUtil.mm#L45. they can replace this with synthesize moduleRegistry API to get access.
for eventDispatcher, i didn't see anyone using this.
Reviewed By: mdvacca, cipolleschi
Differential Revision: D48179428
fbshipit-source-id: d08fbd0adf6177d56e32a0ce4b21b6acb0682a2d
Summary:
Adds extra printouts when running `npx react-native start`:
- The current React Native version.
- "Dev server ready" on `dep_graph_loaded` event (indicating that the server is ready to receive bundle requests from devices).
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D48778254
fbshipit-source-id: ebc0672d6b6791882fe0df2d9795eaf7c5a396d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39113
This diff makes Xcode build fail if `Build JS Bundle` script phase fails. Before that the script phase could fail silently resulting in subltle breakages. E.g. we could get seemingly working app that doesn't have proper jsbundle or source maps.
Changelog: [IOS][Fixed] - Fail Xcode build if Build JS Bundle script phase fails.
Reviewed By: motiz88
Differential Revision: D48562229
fbshipit-source-id: 247e271b1ce28061418bb7a8277dcabf3dcf99aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39128
`HERMES_ENABLED` was supposed to indicate wether hermes-engine pod is present in the project. It was initialized by grepping `hermes-engine` from `Podfile.lock`.
This is redundant because Hermes is enabled by default and it is sufficient to check that `$USE_HERMES != false` for cases that are Hermes specific.
Changelog: [Internal] - Remove usage of HERMES_ENABLED from react-native-xcode.sh
Reviewed By: cipolleschi
Differential Revision: D48600174
fbshipit-source-id: 522d4edb89517fd432cc159624a41219c9e00124
Summary:
- if an existing iOS project specifies `EXCLUDED_ARCHS`, these settings are overwritten by the `react_native_post_install` step as part of the Cocoapods install
- this can break the build of existing iOS apps that want to include React Native
- a previous PR (https://github.com/facebook/react-native/pull/38132) updated the Cocoapods utils to that we only update `EXCLUDED_ARCHS` when using Hermes
- this worked around the issue for apps that opted to use JSC
- however if you _do_ want to use Hermes (the default) this problem persists
### Existing Behaviour
- one of the functions called as part of the `react_native_post_install` step is `exclude_i386_architecture_while_using_hermes`
- see [/packages/react-native/scripts/cocoapods/utils.rb](https://github.com/facebook/react-native/blob/v0.72.1/packages/react-native/scripts/cocoapods/utils.rb#L56-L69)
```
def self.exclude_i386_architecture_while_using_hermes(installer)
projects = self.extract_projects(installer)
# Hermes does not support `i386` architecture
excluded_archs_default = self.has_pod(installer, 'hermes-engine') ? "i386" : ""
projects.each do |project|
project.build_configurations.each do |config|
config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = excluded_archs_default
end
project.save()
end
end
```
🐛 **However** 🐛
- this means existing projects that have `EXCLUDED_ARCHS` set, the existing value will be overwritten either to `"i386"` or a blank string
### Changed Behaviour
- appends `"i386"` to existing string if set, or just sets the value to `"i386"` if there is no existing value
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] don't override `EXCLUDED_ARCHS` when installing Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/39060
Reviewed By: dmytrorykun
Differential Revision: D48515441
Pulled By: cipolleschi
fbshipit-source-id: 8cb3c8b680d92272da0b106553179af051d0f84e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39148
This change adds another `DEFINES_MODULE` to React-ImageManager which is required to integrate with Swift.
## Changelog:
[Internal] - Add Defines modules for React-ImageManager.
## Facebook:
This work is required to collaborate with Expo on ExpoModules
Reviewed By: dmytrorykun
Differential Revision: D48648153
fbshipit-source-id: b06f049be2aedc9fb1ca4744fde0dda88cb74ece
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39185
Changelog: [Internal] - Fix incorrect pointer coordinates caching
In D48472486 I moved the updating of "previous" fields into the `handleHitStateDivergence` method which made sense considering that it's run on every event regardless but what I didn't take into account was the updating of the `mLastEventCoordinatesByPointerId` field. On `ACTION_HOVER_MOVE` events there's a filter that ensures that only move events that have a large enough distance are emitted (something that isn't done on iOS, hence why I didn't think of it), but after my changes in D48472486 it was updating `mLastEventCoordinatesByPointerId` **before** that hover move check, making the distance always 0 and never firing move events.
This diff fixes this by moving the updating of `mLastEventCoordinatesByPointerId` and `mLastButtonState` back to the end of `handleMotionEvent`.
Reviewed By: lunaleaps
Differential Revision: D48756372
fbshipit-source-id: 6f2e40366986ce8d1c6128e49bf3abd44137196d
Summary:
This PR is another one made with the intent to reduce the number of diffs between React Native and React Native macOS.
In https://github.com/facebook/react-native/commit/f7219ec02d71d2f0f6c71af4d5c3d4850a898fd8#diff-d091f6636e07dc62dd7d892489355707c43923ac15056fd2eb59d9a297d576a6 , we introduced `kRCTPlatformName`, which had already been in React Native macOS for a while (since we ifdef to either "ios" or "macos" in a number of places). This change moves the string up to a common header (dropping the "k" prefix) so we can refactor other strings that currently have a hardcoded "platform=ios" inside them.
## Changelog:
[IOS] [CHANGED] - Add RCTPlatformName to RCTConstants.h
Pull Request resolved: https://github.com/facebook/react-native/pull/39141
Test Plan: CI should pass
Reviewed By: NickGerleman
Differential Revision: D48656197
Pulled By: lunaleaps
fbshipit-source-id: b9ff08e2591d7553a1a452795f36d4405ddaa5b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39184
Previously, when `props.accessibilityValue` was enabled and other props were enabled, like `props.accessibilityRole`, that are used in the accessibilityValue for iOS, the value from `props.accessibilityValue` wasn't announced.
This is a problem for cases like radio button, which also needs to announce the placement of the radio button within a group, e.g. "[label], radio button, checked, 1 out of 3".
This diff fixes this problem by including the value from `props.acessibilityValue` within the method that builds the `accessibiityValue` for VoiceOver.
Reviewed By: cipolleschi
Differential Revision: D48534155
fbshipit-source-id: 176ba76ff772741a5cdc7d2a56c6cdfb92674477
Summary:
- when using the `useWindowDimensions()` hook in a component, it's possible for the hook to report incorrect sizes and not update as frequently as it should
- this is most applicable to apps built for iPad and macOS
- closes https://github.com/facebook/react-native/issues/36118
### Existing Behavior - https://youtu.be/NcV6kEDg20E
- either when resizing a React Native app to a different [Size Class](https://developer.apple.com/design/human-interface-guidelines/layout#Device-size-classes) or changing the Appearance, we dispatch an `RCTUserInterfaceStyleDidChangeNotification` notification
- these are then handled in the `interfaceFrameDidChange` method of `RCTDeviceInfo`
- this results in a `didUpdateDimensions` Device Event, which in turn updates the results of `useWindowDimensions()`
- see [RCTDeviceInfo.mm#L217-L232](https://github.com/facebook/react-native/blob/v0.72.0-rc.4/packages/react-native/React/CoreModules/RCTDeviceInfo.mm#L217-L232)
- and [Dimensions.js#L119-L124](https://github.com/facebook/react-native/blob/v0.72.0-rc.4/packages/react-native/Libraries/Utilities/Dimensions.js#L119-L124)
🐛 **However** 🐛
- if you are resizing without triggering a `UITraitCollection` change, the Dimensions reported by `useWindowDimensions()` can become stale, until you either:-
- hit a certain width that is considered a different Size Class
- change the Appearance
- background then resume the app
- make the app full-screen
### Changed Behavior - https://youtu.be/w9BevpZ2y08
- added a new `RCTRootViewFrameDidChangeNotification` notification
- the thinking here is to avoid additional overhead by re-using the same `RCTUserInterfaceStyleDidChangeNotification`
- maybe it's overkill?
- the new notifications are sent from an override of `setFrame` on `RCTRootView`
- the new notifications call the same `interfaceFrameDidChange` method of `RCTDeviceInfo`
- Dimensions are now reported correctly when resizing; even within the same Size Class
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Dimensions could be reported incorrectly when resizing iPad or macOS apps
Pull Request resolved: https://github.com/facebook/react-native/pull/37649
Test Plan:
**Reproduction: https://github.com/jpdriver/Dimensions**
or to recreate it yourself:-
- Generate a new project
- Change App.tsx
```
import * as React from 'react';
import {View, Text, useWindowDimensions} from 'react-native';
export default function App() {
const {width, height} = useWindowDimensions();
return (
<View style={{flex: 1, justifyContent: 'center', alignItems: 'center'}}>
<Text>Width: {width}</Text>
<Text>Height: {height}</Text>
</View>
);
}
```
- Open the iOS project in Xcode and enable iPad support
- Enable the iPad app to be used in any orientation
- Run the app
- Enable Stage Manager
- Drag one of the corners to resize the app
Reviewed By: javache
Differential Revision: D46335537
Pulled By: NickGerleman
fbshipit-source-id: 1533f511cf3805fdc9629a2ee115cc00e204d82c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39144
## Changelog:
[Internal] -
This adds more information into internal shadow tree consistency check error reporting, as well as some minor code refactorings.
Note that the code is run only in debug, and normally you don't trigger such issues, unless you look into a new platform implementation (which I did).
Reviewed By: javache
Differential Revision: D48643602
fbshipit-source-id: a6475f2f577c7b461622472af1c6855072ae319e
Summary:
Expose a `unstable_browserLauncher` option to `createDevMiddleware()`. This allows integrators to provide a custom implementation for opening URLs in a web browser, initially a `launchDebuggerAppWindow` method.
Customising the browser launcher implementation can be useful in cases where the dev server is running remotely and not on the developer's local machine.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D48647750
fbshipit-source-id: ebf34106ad27899024396b13b22ec4536aad05b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39149
Props structs are allowed to references RawValue keys multiple times, however this didn't work correctly if the key was formed out of a different combination of prefix/name/suffix, as the duplicate key entry would've been removed from the `RawPropsKeyMap`. Log an error in such scenarios to help identify these types of problems.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D48641819
fbshipit-source-id: 8cf71366cbf8ae6bee418a6c9d030ebd38784d52
Summary:
Given that the e2e tests are quite flaky, we want to reduce the flakyness making them non land blocking.
The idea is to:
1. always have them green in CircleCI
2. store the test logs in CircleCI artifacts, so we can explore them if needed.
3. use danger to read the artifacts from CircleCI and post a message to inform the user whether the Test ends up successfully or not.
## Changelog:
[Internal] - Make e2e tests non land-blocking. Use Danger to report the status of the E2E jobs
Pull Request resolved: https://github.com/facebook/react-native/pull/39129
Test Plan: CircleCI stays green, logs are uploaded as artifacts.
Reviewed By: rshest
Differential Revision: D48642955
Pulled By: cipolleschi
fbshipit-source-id: 185862f46c47d59f949743a9b893162b2bb3a651
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39155
[Changelog]: [Android][Fixed] Fix crash in CompositeTurboModuleManagerDelegate
CompositeTurboModuleManagerDelegate.cpp crashes as we pass in one or multiple
```
jni::alias_ref<TurboModuleManagerDelegate::javaobject> delegate
```
but don't retain a global reference to them. Fix use:
```
jni::make_global(delegate)
```
Differential Revision: D48670217
fbshipit-source-id: e805f28919918b2a867589dbb6e2a70d67dcd8c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39153
`FlatList`'s restriction on not changing the `onViewableItemsChanged` prop forces developers to violate the rules of React, risking bugs and blocking the rollout of other improvements such as React Forget.
This diff relaxes the validation specifically for the seemingly common case in which a developer passes just a onViewableItemsChanged prop instead of viewabilityConfigCallbackPairs. We use an anonymous closure to create a stable identity that will be passed down to the underlying VirtualizedList, where the closure calls the current `props.onViewableItemsChanged`. The intent of this diff is to alleviate the worst impacts of the current restriction with a correct if not ideal solution, giving us time to fix the API more holistically.
Feedback welcome!
## Changelog:
[Changed] - Allow passing different values to `FlatList.onViewableItemsChanged`
## Facebook
See https://fburl.com/workplace/9svfrytw for more context.
Reviewed By: NickGerleman
Differential Revision: D48656586
fbshipit-source-id: 5b0926deada25637786c4cf3b329607d9f515528
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39140
TurboReactPackage.getModule is nullable, although the internals of ReactNative requires this method to be non null (otherwise there will a NPEs)
I'm making TurboReactPackage.getModule no nullable, this is important to simplify API and future migration to kotlin
changelog: [internal] internal/
Reviewed By: cortinico
Differential Revision: D48588375
fbshipit-source-id: e510f76ea0271ff33ab2ebe6c76382c4781e1787
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39137
getNativeModuleIterator is not required to be public, reducing visibillity to package only
changelog: [internal] intenral
Reviewed By: philIip, rshest
Differential Revision: D48588376
fbshipit-source-id: 6cbff90a4c51d2af4b0693b84c1a674ea24b94d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39135
## Changelog:
[Internal] -
Expose constants type from DeviceInfo native module - this makes codegen generate the corresponding data structure, making the native module implementation shorter (in C++ in particular).
Reviewed By: christophpurrer
Differential Revision: D48620784
fbshipit-source-id: 40ae83ebec92e0a470c20ef1ad16f8392e2bf8b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39146
Adds Microsoft Edge fallback for the `/open-debugger` endpoint when no Chrome installation is found.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D48563386
fbshipit-source-id: 74baba7c03a062bd769b2f9ac0cc35bac0b2ae65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39136
## Changelog:
[Internal] -
`getConstants()` method for TM was enforced to only use object literals for the return type specs.
This limits flexibility, in particular those data structures can't be consequently exported and picked up by codegen (not even mentioning the potential need for copypasting those obejct literals around).
This relaxes this restriction.
Note that I've been digging into the development history in order to find out whether there was any particular historical reason for such a limitation, but couldn't find any, so I assume it was rather incidental.
Reviewed By: christophpurrer
Differential Revision: D48620652
fbshipit-source-id: 92d6ba531fc99fb9b25b4957ae123e7832f44ee4
Nick Gerleman
Koen Punt
Maciej Jastrzebski
Intl Scheduler
David Vacca
Ruslan Shestopalyuk
Phillip Pan
Alex Hunt
Dmitry Rykun
JP
Riccardo Cipolleschi
Vincent Riemer
Arushi Kesarwani
Saad Najmi
Carmen Krol
Pieter De Baets
Riccardo Cipolleschi
Ergul Azizler
Christoph Purrer
Joe Savona
Andrew Wang
Sam Zhou