Summary:
Following the discussion on https://github.com/facebook/react-native/issues/46505, this PR aims to allow mixte type configuration (String and/or Array of String) during the post installation of pods.
## 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] - allow pods mixte type settings on post-install
Pull Request resolved: https://github.com/facebook/react-native/pull/46536
Test Plan: `packages/react-native/scripts/cocoapods/__tests__/utils-test.rb` test suits was updated to support array and works as expected
Reviewed By: shwanton
Differential Revision: D62870582
Pulled By: cipolleschi
fbshipit-source-id: c0ace6d9d20e6609ceae5aafd236d97fc9e86ddf
Summary:
This pull request replaces the use of mkdirp with Node.js's built-in fs.mkdirSync({ recursive: true }) function, which is available in Node.js version 10.12.0 and above. This change reduces the number of external dependencies and simplifies the codebase by using the native capabilities of Node.js.
The motivation behind this change is to remove the unnecessary mkdirp dependency, as Node.js natively supports recursive directory creation since version 10.12.0. This streamlines the code and reduces the reliance on external libraries.
## Changelog:
[INTERNAL] [REMOVED] - Replaced mkdirp with fs.mkdirSync({ recursive: true }) in build scripts and codegen. Requires Node.js 10.12.0 and above.
Pull Request resolved: https://github.com/facebook/react-native/pull/46388
Test Plan: I ran the build and codegen scripts locally with Node.js version 10.12.0 and above after replacing mkdirp, ensuring the scripts work as expected. No issues were encountered, and all processes, including directory creation and file handling, function correctly.
Reviewed By: cortinico
Differential Revision: D62852488
Pulled By: huntie
fbshipit-source-id: 76f44102a80b499521c156308d276a17d279ce38
Summary:
This PR does some further cleanup on the flags passed to cocoapods.
I've moved `boost_compiler_flags` and `folly_dep_name` to `helpers.rb` file.
## Changelog:
[INTERNAL] [FIXED] - move boost compiler flags and folly dep name to centralized config
Pull Request resolved: https://github.com/facebook/react-native/pull/46513
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D62846105
Pulled By: cipolleschi
fbshipit-source-id: dff07ddb49f1f4b559125f2ed8508b32f08d4975
Summary:
This PR is a small fix for the indentation of `tsconfig.json`
## Changelog:
[INTERNAL] [FIXED] - fix for the indentation of `tsconfig.json`
Pull Request resolved: https://github.com/facebook/react-native/pull/46529
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D62845892
Pulled By: cipolleschi
fbshipit-source-id: 52a0309027350cd9bba8c2c158887b23ea093876
Summary:
Due to `set -e` shell option, missing `xcrun` may cause the setup script to fail on Linux.
Also makes the script continue even if the glog `./configure` call does not succeed.
### Related
- Follow-up to https://github.com/facebook/react-native/pull/44417
## Changelog:
- [Internal] [Fixed] - react-native: make missing xcrun not throw in `ios-configure-glog.sh`
- [Internal] [Fixed] - react-native: accept failing glog ./configure in `ios-configure-glog.sh`
Pull Request resolved: https://github.com/facebook/react-native/pull/46358
Reviewed By: cortinico
Differential Revision: D62851737
Pulled By: cipolleschi
fbshipit-source-id: 3ed76a81b6f428a1697c364698a0dfdd3bbb74f2
Summary:
In this PR https://github.com/facebook/react-native/issues/45560 the BUNDLE_COMMAND initialization was removed while it is still being used. Without it, building from Xcode throws unknown options error for Physical iOS devices.
I have just brought back the initialization from the PR before that, so the bundle phase is successful.
## Changelog:
[IOS][Fixed] - Add back the BUNDLE_COMMAND
Pull Request resolved: https://github.com/facebook/react-native/pull/46495
Test Plan: I have bundled release builds in Xcode. Everything seems to be fine.
Reviewed By: cortinico
Differential Revision: D62846877
Pulled By: cipolleschi
fbshipit-source-id: 3f07e8c0bc5acf98177582f1fee9a55ae77b31a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46527
Changelog: [Internal]
**Context**
- `DefaultTurboModuleManagerDelegate.kt` was being stripped by redex since there was no direct dependency.
- This was causing a crash in prod builds
```
Trace: java.lang.RuntimeException: Unable to create application com.facebook.mobilehome.MobileHomeAppShell: java.lang.ClassNotFoundException: Didn't find class "com.facebook.react.defaults.DefaultTurboModuleManagerDelegate" on path: DexPathList
```
**Change**
- Annotate `DefaultTurboModuleManagerDelegate.kt` with `DoNotStripAny`
- Don't strip `DoNotStripAny` annotated classes
Reviewed By: mdvacca
Differential Revision: D62766339
fbshipit-source-id: 7d9bfa04e252c392b94f739443bacf34f593e481
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46166
## This Diff
This removes some of the legacy utilties used for background manipulation, no longer used anywhere (and very rarely used externally from some previous tests). These conflict with BackgroundStyleApplicator, which should be used instead.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog:
[Android][Breaking] - Remove ReactViewBackgroundManager and ReactViewBackgroundDrawable
Reviewed By: sammy-SC
Differential Revision: D61658084
fbshipit-source-id: 611f6d78fa4859574c063e9f0395c3dadc1588cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46168
## This Diff
This removes the legacy path from ReactScrollView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61658081
fbshipit-source-id: d6db43e25faf8e1ebd42d2816c7a915b3ed9404e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46161
## This Diff
This removes the legacy path from ReactHorizontalScrollView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61658082
fbshipit-source-id: 98cab5dfcad8beee6d131fcfe122313730a6f665
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46162
## This Diff
This removes the legacy path from ReactEditText and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61658080
fbshipit-source-id: 6ac7c5ed230e44fe307640a730e076b903e0674a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46171
## This Diff
This removes the legacy path from ReactTextView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61658083
fbshipit-source-id: b753d4eb45091aa31ea870a684c35b71c1ee5036
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46159
## This Diff
This removes the legacy path from ReactViewGroup and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61657251
fbshipit-source-id: 6d00a1cac79450d306cf28446e6397d31ceffb19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46167
## This Diff
This removes the legacy path from ReactImageView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61657253
fbshipit-source-id: 96cf1160e466de78c2f133f0e4fb2d9b2e7cf478
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46524
There's an interesting behavior in Animated where we effectively perform an O(N + M) traversal of the Animated graph, calling `__makeNative` on each "input", which in turn tends to call `__makeNative` on each "output" (so we revisit the current node M times when calling `__makeNative` on the M inputs). In practice, the behavior is still O(N), because M is small and finite (most Animated nodes have 1 or 2 inputs).
All that said, some platforms (e.g., react-native-windows) rely on this revisiting behavior, where on the first visit, we recurse the node to its inputs, and on the subsequent visit, we update the `_platformConfig` value without recursion (see https://github.com/facebook/react-native/pull/32736 for the original change adding platformConfig).
A recent change to AnimatedWithChildren (https://github.com/facebook/react-native/pull/46286) eagerly invokes `__getNativeTag` on AnimatedWithChildren in the initial recursion step, which forces materialization of the NativeAnimated node *before* it's `_platformConfig` is set.
There is certainly some refactoring that needs to be done to improve all this, but for now, this change reverts to delay the call to `__getNativeTag` until after at least one `__makeNative` occurs on an input.
## Changelog
[General][Fixed]: Order of operations related to platformConfig propagation in NativeAnimated
Reviewed By: yungsters
Differential Revision: D62768179
fbshipit-source-id: ca9d911503e0630bc3a1309b21f9686aa77ac8b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46509
With ARG_DISABLE_HOST_LIFECYCLE_EVENTS it's possible to conditionally set mDisableHostLifecycleEvents when the ReactFragment gets created.
## Changelog:
[Android][Fixed] ARG_DISABLE_HOST_LIFECYCLE_EVENTS in ReactFragment to allow unmounting a surface without destroying ReactHost.
Reviewed By: rozele
Differential Revision: D62714185
fbshipit-source-id: b6518ff67a9644421b8fe9c7cdc2aa6d62a23651
Summary:
This PR adds an ifdef to declare `supportedInterfaceOrientations` only on iOS as this property does not affect other platforms causing a build issue.
## Changelog:
[IOS] [ADDED] - declare supportedInterfaceOrientations only on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/46512
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D62754746
Pulled By: javache
fbshipit-source-id: e2ca5d96cba87e611c48a87f10bf7831e9051646
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46508
Changelog: [internal]
This cleans up the "fixMissedFabricStateUpdatesOnAndroid" feature flag and enables the fix permanently.
This fixes some state updates in the Fabric shadow tree being missed in some edge cases.
See https://github.com/facebook/react-native/pull/45236 for context.
Reviewed By: rshest
Differential Revision: D62743019
fbshipit-source-id: c24ab8a49a97ca26e60efa2fa4bc6a21ccac52d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46515
Changelog: [internal]
This reduces the depth of the Systrace/Perfetto blocks by 1 removing this unnecessary nesting. If for some reason `ShadowTree::tryCommit` runs more than once, it will still show up.
Reviewed By: bgirard, sammy-SC
Differential Revision: D62499855
fbshipit-source-id: 48cce7532a308221c22d04de874870be509fe315
Summary:
This PR removes `available` for `RCTKeyWindow` after minimum version bump to iOS 15 this check is not needed anymore.
## Changelog:
[IOS] [REMOVED] - remove available for RCTKeyWindow check
Pull Request resolved: https://github.com/facebook/react-native/pull/46510
Test Plan: CI Green
Reviewed By: rshest
Differential Revision: D62752434
Pulled By: javache
fbshipit-source-id: 7b7745d4f27128cdb66053f7fa1cc234435eac31
Summary:
Solves these issues:
- https://github.com/facebook/react-native/issues/18398
- https://github.com/facebook/react-native/issues/12478
Solves this proposal: https://github.com/react-native-community/discussions-and-proposals/discussions/774
## 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
-->
[GENERAL] [ADDED] - added overlayColor prop to modal component for customisable background overlay
**Motivation:**
Currently, the React Native Modal component only allows the background to be set to either `transparent` or `white`. This limits the ability to dim the background or apply custom colors, which is essential for creating a more polished and user-friendly interface.
**Change Log:**
Modal Component Enhancements:
- Introduced a new optional prop `overlayColor` to the Modal component.
- Updated the background color logic to prioritize `overlayColor` when transparent is `false`.
- Ensured backward compatibility by defaulting to `white` when `overlayColor` is not provided.
Pull Request resolved: https://github.com/facebook/react-native/pull/46322
Test Plan:
- Test the changes on both iOS and Android devices/emulators to ensure consistent behavior.
- Added example in **rn-tester** app
**Sample screenshot with custom overlayColor passed as 'red'.**
Reviewed By: cipolleschi
Differential Revision: D62201559
Pulled By: alanleedev
fbshipit-source-id: e990d7f18f5edf61f0107026ea899c5f22d47bfd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46506
Changelog: [Android][Fixed] Fixed incorrect scroll event/position for scroll views when doing a smooth scroll animation.
We tested this in production and the fix is safe to land.
Reviewed By: rshest
Differential Revision: D62738925
fbshipit-source-id: e1198dac76cf850dfa76a5cee1ef205d5b367d19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46511
changelog: [internal]
task is not used after this line of code. Let's avoid copy shared_ptr's copy constructor.
Reviewed By: rubennorte
Differential Revision: D62751612
fbshipit-source-id: 92b0da44972b200870ef66f3a8482fbde55052ac
Summary:
This reverts commit 0cb97f0261.
Revert this commit that adds a `post install` script for a couple of reasons:
1. (EDIT: This turns out to be unrelated) The `postinstall` script causes `yarn install` to fail on React Native macOS, where we use Yarn 4. I'm not entirely sure why, but I probably won't debug it for the rest of the reasons.
2. `postinstall` scripts (at least inside Microsoft) are viewed as a security risk. Any package in your dependency tree can get compromised, add the phase, and run arbitrary code. This has happened in the past with React Native past if I recall correctly. As such, we disable `postinstall` scripts in many of our repos (including `rnx-kit` and `react-native-test-app`).
3. The issue this is trying to solve is to help newcomers avoid a stale cache when they switch branches in the React Native monorepo and only run `yarn install`. I think it would be sufficient to add some documentation somewhere that it is expected one runs `yarn && yarn build` to use this repo locally? That's a fairly common practice in monorepos, at least ones inside Microsoft.
## Changelog:
[INTERNAL] [SECURITY] - Remove post install script phase in the React Native monorepo
Pull Request resolved: https://github.com/facebook/react-native/pull/46420
Test Plan: CI should pass
Reviewed By: christophpurrer, robhogan, cortinico, rshest
Differential Revision: D62755022
Pulled By: huntie
fbshipit-source-id: bf94ed33e3e451ea337ef7a6984f7ba964d0b212
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46462
While adding D62583337, I noticed that `react-native` doesn't specify `babel-jest` as a dependency, despite referencing it in the included `jest-preset.js` — instead this would need to be installed by the template/project.
If we want to change this in future, we should consider a separate `react-native/jest-preset` package. However, I strongly believe this is the right location for this dependency: installing `react-native` = all parts of it work.
(Note that in the React Native monorepo, we are using `dependencies` for both dev and runtime deps in packages.)
Changelog: [Internal]
allow-executable-binary
## allow-executable-binary: Bypassed as this is a managed JavaScript dependency that is pre-existing in other parts of the codebase
Reviewed By: robhogan
Differential Revision: D62583665
fbshipit-source-id: 8bbcc8736e2740e45793d7b7e225ccfd1ca7f898
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46502
changelog: [internal]
At the moment, Linking module has undocumented restriction that if you call it twice when Android Activity is not available, it will return with an error.
This is unnecessary and can be handled more sensibly.
Reviewed By: javache, yungsters
Differential Revision: D62708123
fbshipit-source-id: 79a6beb70e834e631f7bedaf6a64076b050a7daa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46484
We recently realized that we don't have TS types for Codegen.
These are needed to let our users use these types when writing Specs in TS
## Changelog
[General][Added] - Add CodegenTypes for TS
Reviewed By: christophpurrer
Differential Revision: D62644516
fbshipit-source-id: 92bb7e8998d31806f6eb63319fb6d406fcd65ad8
Summary:
Following one of my previous PRs: https://github.com/facebook/react-native/pull/45176 I'm adding same conditionals to another module.
StatusBar API is supported on this platforms:
| Platform | Support |
| ------------- | ------------- |
| macOS | ❌ |
| tvOS | ❌ |
| visionOS | ❌ |
| iOS/iPadOS | ✅ |
## 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
-->
[INTERNAL] [ADDED] - Conditionals for iOS only code in RCTStatusBarManager.mm
Pull Request resolved: https://github.com/facebook/react-native/pull/45896
Test Plan: CI Green / Make sure everything works as before
Reviewed By: cortinico
Differential Revision: D62579943
Pulled By: cipolleschi
fbshipit-source-id: 0c198c7732d253993638d825ca83be076bb09b90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46452
`babel-plugin-codegen` transforms `codegenNativeComponent`s by expending it with a whole set of many commands (~40 lines) that don't have a good equivalent on the source file.
Currently these lines are pointing to random parts of the due to a bug that causes the source maps to be incorrect and confusing.
Instead, I point all these generated lines of code to the default export as the only line that can represent them.
This way, if an error is thrown from that generated code it would point to that export.
If the users are confused by how it works, there's a comment in the function that is used in the default export in these that explains it:
```
// If this function runs then that means the view configs were not
// generated at build time using `GenerateViewConfigJs.js`. Thus
// we need to `requireNativeComponent` to get the view configs from view managers.
// `requireNativeComponent` is not available in Bridgeless mode.
// e.g. This function runs at runtime if `codegenNativeComponent` was not called
// from a file suffixed with NativeComponent.js.
function codegenNativeComponent<Props>(
componentName: string,
options?: Options,
): NativeComponentType<Props> {
```
The transformation is from all the types and exports after the imports:
[`MyNativeViewNativeComponent` for example](https://github.com/facebook/react-native/blob/773a02ad5d3cc38e0f5837b42ba9a5e05a206bf9/packages/rn-tester/NativeComponentExample/js/MyNativeViewNativeComponent.js#L4)
Which is roughly (ignoring all typing):
```
// types and exports
export const Commands: NativeCommands = codegenNativeCommands<NativeCommands>({
supportedCommands: [
'callNativeMethodToChangeBackgroundColor',
'callNativeMethodToAddOverlays',
'callNativeMethodToRemoveOverlays',
'fireLagacyStyleEvent',
],
});
export default (codegenNativeComponent<NativeProps>(
'RNTMyNativeView',
): MyNativeViewType);
```
to roughly:
```
var React = require('react');
var nativeComponentName = 'RNTMyNativeView';
var __INTERNAL_VIEW_CONFIG = {
uiViewClassName: 'RNTMyNativeView',
bubblingEventTypes: {
topIntArrayChanged: { /* */ },
topAlternativeLegacyName: { /* */ },
},
validAttributes: {
opacity: true,
values: true,
...require('ViewConfigIgnore').ConditionallyIgnoredEventHandlers({
onIntArrayChanged: true,
onLegacyStyleEvent: true
})
}
};
var _default = require('NativeComponentRegistry').get(nativeComponentName, () => __INTERNAL_VIEW_CONFIG);
var Commands = {
callNativeMethodToChangeBackgroundColor(ref, color) {
require('RendererProxy').dispatchCommand(ref, "callNativeMethodToChangeBackgroundColor", [color]);
},
callNativeMethodToAddOverlays(ref, overlayColors) {
require('RendererProxy').dispatchCommand(ref, "callNativeMethodToAddOverlays", [overlayColors]);
},
callNativeMethodToRemoveOverlays(ref) {
require('RendererProxy').dispatchCommand(ref, "callNativeMethodToRemoveOverlays", []);
},
fireLagacyStyleEvent(ref) {
require('RendererProxy').dispatchCommand(ref, "fireLagacyStyleEvent", []);
}
};
exports.default = _default;
exports.__INTERNAL_VIEW_CONFIG = __INTERNAL_VIEW_CONFIG;
exports.Commands = Commands;
```
Changelog: [Fix] Fixed source maps in Native Components JS files that use codegenNativeComponent
Reviewed By: robhogan, huntie
Differential Revision: D62443699
fbshipit-source-id: 522b4382736a8fed93a1bc687a78d6885fe7c9d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46473
This diff extends the renderer of react native to ensure that pre-allocated views that were never mounted on the screen are deleted as soon as the shadow node is deleted from JS
This feature is controlled by the ReactNativeFeatureFlag: enableDeletionOfUnmountedViews
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D62559190
fbshipit-source-id: 1af6785fc57256d12750db64489c9ecc6cf98c9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46488
React.Ref includes string | number to support legacy string ref, which will be killed in React 19. Therefore, the type is deprecated in Flow. This diff changes the type to use React.RefSetter instead.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D62649800
fbshipit-source-id: 81bcfbb052e2039b23829dac8de242bfb0fdca3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46498
Looks like this is still necessary because we still run into this error when using the Components tab when using React DevTools:
> TypeError: cyclical structure in JSON object
This effectively reverts https://github.com/facebook/react-native/pull/46382.
Changelog:
[General][Changed] - AnimatedNode (and its subclasses) once again implement `toJSON()`.
Reviewed By: javache
Differential Revision: D62690380
fbshipit-source-id: d5b7c1d156b49838abefe48a7d7b61471cc3488a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46500
We're in the process of adding the required native component to all apps we maintain.
Until that is fully completed, fall back to using View if the native component
doesn't exist.
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D62701331
fbshipit-source-id: d26c946af3a68231d0714e89d5e41be311399036
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46469
This causes VS Code to syntax highlight incorrectly, so let's use a type alias to workaround that limitation.
Changelog:
[Internal]
Reviewed By: tyao1
Differential Revision: D62595120
fbshipit-source-id: 97fc3caded51190a7840de91025eeb71c6290be8
Summary:
Before we were dividing proportionally and were noticing some truncation at the bottom. It seems that the truncation was disproportionately because of the way the metrics are calculated. Through guess and check, dividing equally between top and bottom seems to yield better results... 🤡
Changelog: [internal]
Reviewed By: NickGerleman, xunrongl
Differential Revision: D62665295
fbshipit-source-id: b1589c75251d68eaf75e32598ee84fbac457ae4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46487
Changelog: [General][Fixed] Fixed accuracy of FlatList estimations to determine what elements are visible in the rendering window.
This fixes a bug in FlatList where it thinks that some elements are visible in the rendering window, when they're not. Specifically, if a cell hasn't been laid out yet, it ignores all the information it already has on the ones that had, and estimates its position and offset based on the estimated size of the cells. In this case, if the first element has a larger offset because the list has a header, that offset is ignored in this case.
One observed result of this is that in a list where there's a header and a single cell that occupy the whole rendering window, FlatList thinks it needs to pre-render an additional element because the header is ignored.
Reviewed By: NickGerleman
Differential Revision: D62649060
fbshipit-source-id: 437bae79916707ca1d08784190508a9f7e36688e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46467
This diff introduces a new feature flag called ReactNativeFeatureFlag.enableDeletionOfUnmountedViews, which will ensure that pre-allocated views that were never mounted on the screen are deleted as soon as the shadow node is deleted from JS
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D62559188
fbshipit-source-id: 61f19a6dd38536de9f70fecc2937793681036f68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46478
These are all supported in the new arch (default as of 0.76), across all platforms. but were previously hidden from types, and undocumented.
I will make a pick request for this change, and we should then add these to documentation.
Changelog:
[General][Added] - Unhide new arch layout props
Reviewed By: cortinico
Differential Revision: D62616897
fbshipit-source-id: f6c2e71785284e667824a76918ccf2724adc4e98
MasGaNo
anirudh.bharti
Oskar Kwaśniewski
legobt
Vin Xi
Riccardo Cipolleschi
Shawn Dempsey
Nick Gerleman
Eric Rozell
Alan Lee
Vincenzo Vitale
Rubén Norte
Stephanie Nicholson
shubhamguptadream11
Samuel Susla
Saad Najmi
Alex Hunt
Pascoal Júnior
Vitali Zaidman
Rodolfo Gomez Sirimarco
David Vacca
Sam Zhou
Tim Yung
Kevin Gozali
Melissa Liu
Jorge Cabiedes Acosta