-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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
Conversation
Base commit: 91728e2 |
Base commit: 91728e2 |
There was a problem hiding this 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!
I don't believe the test failures were introduced in this PR - none of the failures in |
Just rebased this to the most recent commit where CI passed |
Is there anything I can do to help get this merged? |
@robbie-c I think you are ready. We just need approval from |
@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) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
@lunaleaps has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
Hi @robbie-c, did you see my review comment? |
There was a problem hiding this 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
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 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 |
@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. |
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 |
@lunaleaps @ryancat I have one question.
What is the fundamental difference between #33553 and this pull request? |
This pull request was successfully merged by @robbie-c in 000bbe8. When will my fix make it into a release? | Upcoming Releases |
See facebook#32538 for the discussion
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
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.