Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for "preferred" AlertButton #32538

Closed
wants to merge 2 commits into from
Closed

Conversation

robbie-c
Copy link
Contributor

@robbie-c robbie-c commented Nov 4, 2021

Summary

Currently, with the Alert API on iOS, the only way to bold one of the buttons is by setting the style to "cancel". This has the side-effect of moving it to the left. The underlying UIKit API has a way of setting a "preferred" button, which does not have this negative side-effect, so this PR wires this up.

See preferredAction on UIAlertController https://developer.apple.com/documentation/uikit/uialertcontroller/

Docs PR: facebook/react-native-website#2839

Changelog

[iOS] [Added] - Support setting an Alert button as "preferred", to emphasize it without needing to set it as a "cancel" button.

Test Plan

I ran the RNTesterPods app and added an example. It has a button styled with "preferred" and another with "cancel", to demonstrate that the "preferred" button takes emphasis over the "cancel" button.

Simulator Screen Shot - iPhone 11 - 2021-11-04 at 09 48 35

@facebook-github-bot facebook-github-bot added CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. labels Nov 4, 2021
@react-native-bot react-native-bot added Platform: iOS iOS applications. Type: Enhancement A new feature or enhancement of an existing feature. labels Nov 4, 2021
@analysis-bot
Copy link

analysis-bot commented Nov 4, 2021

Platform Engine Arch Size (bytes) Diff
ios - universal n/a --

Base commit: 91728e2
Branch: main

@analysis-bot
Copy link

analysis-bot commented Nov 4, 2021

Platform Engine Arch Size (bytes) Diff
android hermes arm64-v8a 8,478,011 +292
android hermes armeabi-v7a 7,775,258 +293
android hermes x86 8,947,150 +284
android hermes x86_64 8,894,079 +294
android jsc arm64-v8a 9,791,896 +116
android jsc armeabi-v7a 8,752,619 +106
android jsc x86 9,740,725 +117
android jsc x86_64 10,341,586 +117

Base commit: 91728e2
Branch: main

Libraries/Alert/Alert.js Outdated Show resolved Hide resolved
Copy link
Contributor

@ken0nek ken0nek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems I have no permission to Approve but LGTM. Thank you!

@robbie-c
Copy link
Contributor Author

I don't believe the test failures were introduced in this PR - none of the failures in analyze_code were things touched by me, build_npm_package looks like a config problem, I'm less confident about test_ios_unit_hermes but it doesn't look related.

@robbie-c
Copy link
Contributor Author

Just rebased this to the most recent commit where CI passed

@robbie-c robbie-c changed the title Add support for "preferred" AlertButtonStyle Add support for "preferred" AlertButton Nov 15, 2021
@robbie-c
Copy link
Contributor Author

Is there anything I can do to help get this merged?

@ken0nek
Copy link
Contributor

ken0nek commented Nov 19, 2021

@robbie-c I think you are ready. We just need approval from React Native Team. I don't know how to get attention though...

@danilobuerger
Copy link
Contributor

@cortinico Hi, would it be possible to get this reviewed by the team?

@@ -122,6 +124,8 @@ class Alert {
cancelButtonKey = String(index);
} else if (btn.style === 'destructive') {
destructiveButtonKey = String(index);
} else if (btn.isPreferred) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@robbie-c shouldn't this just be an if? It shouldn't depend on the style?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair, whilst preferred and destructive seem mutually exclusive visually (it's been a while since I wrote this so I don't remember which one "wins" if you apply both), if we're just passing through flags to the iOS API in an unopionated way it makes sense to match it, so I'll make this change.

@facebook-github-bot
Copy link
Contributor

@lunaleaps has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

@danilobuerger
Copy link
Contributor

Hi @robbie-c, did you see my review comment?

Copy link
Contributor

@lunaleaps lunaleaps left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@robbie-c Thanks for adding this feature! For this change, we'll need to add a new method call for the new parameter to ensure we don't break for apps that use OTA. We'll need to conditionally check that the new native method exists on JS as well

@robbie-c
Copy link
Contributor Author

robbie-c commented Mar 19, 2022

Apologies @danilobuerger @lunaleaps , I'm just seeing these comments now.

@lunaleaps just to clarify what you mean - are you talking about adding a new native method (something like alertWithArgs2) that we'd call if it exists, but leave the original native iOS alertWithArgs unchanged for backwards compatibility.

What's the guarantees provided with OTA? Is it that new JS code always works with old native, or does it also need to hold true in the other direction as well. I'm just trying to judge how hard it would be to keep one alertWithArgs and make it compatible.

@lunaleaps
Copy link
Contributor

lunaleaps commented Mar 25, 2022

@robbie-c Yea can we add a new method with the new argument into the native module (turbo module) and type it as nullable. New JS needs to work with old native and only in that direction. In JS usage, you'd need also need to do a null check before using; also for the case of Android.

@robbie-c
Copy link
Contributor Author

Apologies for the delays on this - the day job is pretty busy and I'm doing 70-90 hour weeks most weeks so I'm not finding a lot of time for things like this

@ken0nek
Copy link
Contributor

ken0nek commented Jun 28, 2022

@lunaleaps @ryancat I have one question.

we'll need to add a new method call for the new parameter to ensure we don't break for apps that use OTA.

What is the fundamental difference between #33553 and this pull request?
It seems #33553 changes the native code and has no new method but it's already merged.

@react-native-bot
Copy link
Collaborator

This pull request was successfully merged by @robbie-c in 000bbe8.

When will my fix make it into a release? | Upcoming Releases

@react-native-bot react-native-bot added the Merged This PR has been merged. label Jul 22, 2022
danilobuerger added a commit to danilobuerger/react-native that referenced this pull request Jul 23, 2022
facebook-github-bot pushed a commit that referenced this pull request Jul 25, 2022
Summary:
See #32538 for the discussion

cc robbie-c

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[iOS] [Fixed] - Allow preferred Alert button regardless of the style

Pull Request resolved: #34253

Test Plan: Same test plan as PR mentioned above

Reviewed By: lunaleaps

Differential Revision: D38112619

Pulled By: cipolleschi

fbshipit-source-id: 2ac4fc6226a859e69f0df27913898effa5e092eb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Merged This PR has been merged. Platform: iOS iOS applications. Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. Type: Enhancement A new feature or enhancement of an existing feature.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants