Commit Graph
18 Commits
Author SHA1 Message Date
Mathieu Acthernoene 7a6c7a462a feat(android): Edge-to-edge Modal (navigationBarTranslucent prop) (#47254)
Summary:
The future of Android is [edge-to-edge](https://github.com/react-native-community/discussions-and-proposals/discussions/827) and to make the React Native developer experience seamless in this regard, the ecosystem needs to transition from “opaque system bars by default” to “edge-to-edge by default.”

Currently, there's no easy way to have edge-to-edge modals, as they are implemented using `Dialog` instances (a separate `Window`) and only provide a `statusBarTranslucent` prop.

I tried to implement it in [`react-native-edge-to-edge`](https://github.com/zoontek/react-native-edge-to-edge) by listening to the `topShow` `UIManager` event. But if it works well when there's a defined animation, we can see a quick jump when there's none, because there's too much delay before the event, and edge-to-edge cannot be applied quick enough to the dialog window.

### react-native-edge-to-edge implem with animation (no jump)

https://github.com/user-attachments/assets/4933a102-87a5-40e4-98d9-47f8c0817592

### react-native-edge-to-edge implem without animation (jump)

https://github.com/user-attachments/assets/e4675589-08fe-44fe-b9d8-0a6b3552b461

 ---

For this reason, and because listening to event feels a bit hacky, I think it will be better to go for a new prop directly on RN Modal component: `navigationBarTranslucent`

> [!NOTE]
> `navigationBarTranslucent` cannot be used without `statusBarTranslucent`, as setting both enable edge-to-edge, like [AndroidX would do](https://github.com/androidx/androidx/blob/androidx-main/activity/activity/src/main/java/androidx/activity/EdgeToEdge.kt) and it would requires extra (and unecessary, given the direction Android is taking) work to find a way to keep the status bar opaque but the navigation bar transparent that work on Android 6 to 15+

### Additional infos

- Colors used for the buttons navigation bar in the PR are the default Android ones ([light](https://github.com/androidx/androidx/blob/androidx-main/activity/activity/src/main/java/androidx/activity/EdgeToEdge.kt#L37) and [dark](https://github.com/androidx/androidx/blob/androidx-main/activity/activity/src/main/java/androidx/activity/EdgeToEdge.kt#L42))
- Compared to the Google implementation, the light scrim is applied from `O_MR1` to `Q` (and not `O` to `Q`) as the [`android:windowLightNavigationBar`](https://developer.android.com/reference/android/R.attr#windowLightNavigationBar) style attribute is not available on `O` (it can only be applied programmatically on API 26).

## Changelog:

[ANDROID] [ADDED] - Add navigationBarTranslucent prop to Modal component

Pull Request resolved: https://github.com/facebook/react-native/pull/47254

Test Plan:
Run the tester app, toggle `navigationBarTranslucent`:

https://github.com/user-attachments/assets/286d173b-35a5-4951-9105-f9f7562d6764

-----
did some additional testing with RNTester using different justification

|flex-start|flex-end|
|https://pxl.cl/5Rd20|https://pxl.cl/5Rd21|

Reviewed By: javache

Differential Revision: D65103501

Pulled By: alanleedev

fbshipit-source-id: ef6473ecd785976d3e26c77bbc212222ec96c9f2
2024-11-06 21:09:36 -08:00
Sam Zhou 723a37cb26 Replace most of the remaining React.AbstractComponent in react-native (#47143)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47143

In order to adopt react 19's ref-as-prop model, we need to eliminate all the places where they are treated differently. `React.AbstractComponent` is the worst example of this, and we need to eliminate it.

This diff replaces most of the remaining `React.AbstractComponent` in react-native.

Changelog: [Internal]

Reviewed By: alexmckenley

Differential Revision: D64701145

fbshipit-source-id: c765674fdf59812895c4fae43df97cf8b9d24f05
2024-10-21 15:48:25 -07:00
Phillip Pan 2ffd31bbd7 set modal rendered state to false on unmount (#47078)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47078

Changelog: [Internal]

in fabric, we've found a scenario where this modal state update is required to cleanup all artifacts from the modal presentation views. it is safe to add this back, as it was originally removed for a scenario that no longer exists.

Reviewed By: shwanton

Differential Revision: D64388550

fbshipit-source-id: f13571260379554b0126c379ace9f9e1b81866be
2024-10-17 22:09:43 -07:00
Alan Lee 7aeff18970 rename overlayColor to backdropColor in Modal (#46523)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46523

the name change [commit](https://github.com/facebook/react-native/pull/46322/commits/64ee5712f7aa9a3df84589146d00f81bac6d945c) was not properly imported from last diff for https://github.com/facebook/react-native/pull/46322/

redoing the name change: overlayColor -> backdropColor

Changelog:
[general][Fixed] - rename overlayColor prop in Modal to backdropColor

Reviewed By: christophpurrer

Differential Revision: D62760028

fbshipit-source-id: 92d6e8f002c92f4e13136542dce946434516988e
2024-09-16 16:11:55 -07:00
shubhamguptadream11 4e1d7015c1 feat: add overlayColor prop to modal component for customisable background overlay (#46322)
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'.**

![simulator_screenshot_4F112217-7AD5-4030-8A18-6260AD32988A](https://github.com/user-attachments/assets/52f16ef2-874b-487c-908b-1aa2a1b8fafb)

Reviewed By: cipolleschi

Differential Revision: D62201559

Pulled By: alanleedev

fbshipit-source-id: e990d7f18f5edf61f0107026ea899c5f22d47bfd
2024-09-16 09:29:00 -07:00
Rubén Norte 74c9ef8fde Remove incorrect state update during unmount in Modal (#46218)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46218

Changelog: [internal]

https://github.com/facebook/react-native/pull/42975  added some logic to fix modal on iOS for Paper but introduced a state update in `componentWillUnmount`. Doing this is incorrect and we've seen cases where it leads to forcing passive effects synchronously, which can affect performance.

This removes that unnecessary call to update the state, because the component will be unmounted anyway.

Reviewed By: bgirard

Differential Revision: D61813988

fbshipit-source-id: bb203578376d86a907544fa62a0d04e93ca132ef
2024-08-26 15:54:18 -07:00
Tim Yung 3965b7d78b RN: Fix Test Case Isolation in Modal-test.js (#45195)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45195

Configure `Modal-test.js` to reset modules between test cases so that there is better isolation, making the tests easier to reason about and to debug.

Changelog:
[Internal]

Reviewed By: javache

Differential Revision: D59097729

fbshipit-source-id: 3b9260283e171ff7fa6b7ffc56685f703875291e
2024-06-27 07:26:04 -07:00
Rob Hogan 1e11257670 Make jest/renderer create helper async in prep for concurrent (#44995)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44995

Use our existing abstraction around `react-test-renderer`'s `create` and make it asynchronous, to allow for wrapping `create` in `act` in a subsequent diff, and using the async API per guidance in https://react.dev/reference/react/act?#await-act-async-actfn .

Changelog: [Internal]

Reviewed By: yungsters

Differential Revision: D58647827

fbshipit-source-id: f81cf382892ef5ba14b452bd32980c98bd7ef03b
2024-06-16 16:55:21 -07:00
Tim Yung 19dc990aa1 RN: Delete Shallow Renderer Cases in Image-test.js (#44977)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44977

These Jest unit test cases were making assertions about shallow rendering, but that shallow rendering is now deprecated.

Changelog:
[Internal]

Reviewed By: robhogan

Differential Revision: D58643060

fbshipit-source-id: a61dfcf6cd778a8556aec874fd5e42f8e11f2be2
2024-06-16 12:15:49 -07:00
Riccardo Cipolleschi 4236538cbd Fix dismissal on the Old Architecture
Summary:
The recent change to make onDismiss work on Fabric broke the Modal on Paper (see [this comment](https://www.internalfb.com/diff/D52959996?dst_version_fbid=236415652884499&transaction_fbid=896066412296150)).

This change will fix that behavior.

The problem was that we were resetting the `isRendered` state only when the Modal receives the event from the Event emitter AND if it has the `onDismiss` callback set.
However, we should hide the component in any case if the ids match, and invoke the onDismiss if it is set.

## Changelog
[iOS][Fixed] - Make sure that Modal is dismissed correctly in Paper

Reviewed By: janeli-100005636499545

Differential Revision: D53686165

fbshipit-source-id: a1de0b29dca7c099e9fa0282ec80cae9a8fd6bc3
2024-02-13 10:51:12 -08:00
Riccardo Cipolleschi c7a0dff760 Make Modal's onDismiss work on Fabric. (#42601)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42601

After S390064, the OnDismiss event for Modal from D52445670 was reverted.
The diff was too big and caused the SEV, so we are trying to reimplement it gradually to make sure we don't brake anything.

The most important thing for our short term goal is to make the `OnDismiss` work only for iOS (following the official docs, Android never supported it) for Fabric (Bridge and Bridgeless).

We also want to minimize the changes t the JS infrastructure, so we are trying not to alter the JS APIs.

## The Problem:
The reason why the onDismiss event does not work is because, as soon as the `visible` property is turned to `false`, the component is removed by the React tree.
When this happens, Fabric deallocate the ShadowNode and the EventEmitter. Therefore, the event is not fired.

## The Solution:
We made this work by "delaying" when the component need to be removed from the reacat Tree.

Rather then rendering or node or not based on the `visible` props, we are introducing a `State` object that keeps track when the Modal is rendered or not.

The `state.isRendering` property is set to `true` when the `visible` prop is set to `true`.
For iOS, when `visible` prop is set to `false`, instead, we wait for the Native side to actually dismiss the View and to invoke the event. When the event is fired, we manually set the `state.isRendering` property to false and the Modal can be considered dismissed.

Notice that this makes also useless to have the Modal Native's snapshot to simulate that the modal is still presented.

## Changelog:
[iOS][Fixed] - `onDismiss` now work on iOS with Fabric, in both Bridge and Bridgeless mode.

Reviewed By: sammy-SC

Differential Revision: D52959996

fbshipit-source-id: 365ca1d0234e3742df9db87007523d1a4a86079f
2024-02-08 02:22:36 -08:00
Rubén Norte 26e33a5f17 Back out "Revert D52919566: [RN] Move codegen root directory from Libraries to src"
Summary:
Changelog: [internal]

bypass-github-export-checks

Reviewed By: huntie

Differential Revision: D52958335

fbshipit-source-id: 24403cdae650fdd4ec0c739b912f69bd6cd5aaad
2024-01-22 09:47:08 -08:00
Himanshi Goyal 692f7275bc Revert D52919566: Move codegen root directory from Libraries to src
Differential Revision:
D52919566

Original commit changeset: 6de8a2d2b607

Original Phabricator Diff: D52919566

fbshipit-source-id: dc25ec0072b436c2b61bc36bd70c8ea12ab2b5c0
2024-01-22 06:53:20 -08:00
Rubén Norte 5e8ce6ca5e Move codegen root directory from Libraries to src (#42402)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42402

Now that we have 2 top level directories for JS files in the `react-native` package, we need to choose where to put the native module and native component specs, because our current infra only supports a single directory.

The options we had are:
1. Keep specs in the current directory (`Libraries`). This is a problem because it encourages us to keep adding modules in this "deprecated" directory.
2. Move specs to the new `src` directory. This requires moving the current files, but from now only we can create new specs in a private directory.
3. Modify the infra to allow multiple directories. This changes the public API for something it's likely only going to be used here.

In this PR I went for option 2) because it's the most future-proof, even though it requires a little bit more work now. I created a script to automatically copy all the specs for modules and components to `src/private/specs/components` and `src/private/specs/modules`, and changed their current locations to serve as a proxy for the new location (to avoid breaking a potentially public API).

`src/private/specs` isn't meant to be their final location. We should probably still colocate native module/component specs with the rest of their code, but we can do so when we move the code from `Libraries` to `src/private`.

Changelog: [internal]

Reviewed By: cortinico

Differential Revision: D52919566

fbshipit-source-id: 6de8a2d2b6077e4f884386567721c6bd2b88a5d3
2024-01-22 04:05:20 -08:00
Erica Klein a58ec074b6 Back out "Send Modal onDismiss event on iOS (Fabric) and Android" @bypass-github-export-checks
Summary:
~~Original commit changeset: f419164032c3

Original Phabricator Diff: D52445670

bypass-github-export-checks

Changelog: [Internal]

Reviewed By: makovkastar

Differential Revision: D52932743

fbshipit-source-id: ea37270998213de0ae732477e0fb99b47aae7cd5
2024-01-20 05:57:48 -08:00
Bernhard Owen Josephus 314cfa8c91 Send Modal onDismiss event on iOS (Fabric) and Android (#42014)
Summary:
1. Modal onDismiss is not working on iOS (Fabric).
2. Modal onDismiss is currently only available on iOS. On Android, we don't have a way to know when exactly a modal is dismissed.

Currently, the onDismiss is emitted using a device event as a workaround to the RCTModalHostView unable to receive the component event as it's already unmounted when visible is false.

This PR removes the workaround and keeps RCTModalHostView mounted until the onDismiss event is emitted from the host and sends the onDismiss event on Android.

bypass-github-export-checks

## Changelog:
[ANDROID] [ADDED] - Added support for Modal onDismiss prop
[IOS] [FIXED] - Fix onDismiss is not working on Fabric
[General][Breaking] - The public API of Modal has changed. We don't have anymore a NativeModalManger turbomodule; RCTModalHostViewNtiveComponent's Prop does not require to pass an identifier anymore.

Pull Request resolved: https://github.com/facebook/react-native/pull/42014

Test Plan:
1. Run rn-tester
2. Open the Modal example
3. The second example shows the counter for the show and dismiss count
4. Show and dismiss the modal and verify the count is incremented correctly

https://github.com/facebook/react-native/assets/50919443/108bfb26-c8f6-43b2-ac40-f0b46e48771b

Reviewed By: javache, sammy-SC

Differential Revision: D52445670

Pulled By: cipolleschi

fbshipit-source-id: f419164032c3bef67387200778b274299bf0659f
2024-01-16 09:31:34 -08:00
Maciej Jastrzebski 468a13635a fix: do not render mocked Modal when visible=false (#39157)
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
2023-08-29 19:54:11 -07:00
Ruslan Lesiutin 714b502b0c | RN Monorepo | Migrate to package (#36434)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36434

Changelog: [Internal]

This is a squashed stack of 18 commits, starting from D43202126

allow-large-files

Reviewed By: cortinico

Differential Revision: D43977381

fbshipit-source-id: 0da552ddb85f2f61a0be0ef071915b35f3f8555c
2023-03-17 05:03:25 -07:00