Skip to content

dialog [nfc]: Wrap showErrorDialog's return value #970

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

Merged
merged 2 commits into from
Oct 7, 2024

Conversation

PIG208
Copy link
Member

@PIG208 PIG208 commented Sep 28, 2024

As a result, showErrorDialog no longer returns a Future that can be mistakenly awaited. The wrapped return value offers clarity on how the Future is supposed to be used.

There is no user visible change because existing callers (other than lightbox's) that wait for its return value are all asynchronous handlers for UI elements like buttons, and waits unnecessarily.

See also discussion
#937 (comment).

@PIG208 PIG208 mentioned this pull request Sep 28, 2024
@PIG208 PIG208 requested a review from chrisbobbe September 28, 2024 04:56
@PIG208 PIG208 added the maintainer review PR ready for review by Zulip maintainers label Sep 28, 2024
Copy link
Collaborator

@chrisbobbe chrisbobbe left a comment

Choose a reason for hiding this comment

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

Small comments below, otherwise LGTM. Thanks!

Comment on lines 25 to 26
final Future<void> _closed;
/// Resolves when the dialog is closed.
Future<void> get closed => _closed;
Copy link
Collaborator

Choose a reason for hiding this comment

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

// Wait until the dialog is closed
await dialog.closed;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Happily, I think the comment is now redundant and can be swept away :)

@chrisbobbe chrisbobbe added integration review Added by maintainers when PR may be ready for integration and removed maintainer review PR ready for review by Zulip maintainers labels Oct 5, 2024
@chrisbobbe chrisbobbe requested a review from gnprice October 5, 2024 01:19
@PIG208 PIG208 force-pushed the pr-wrap-future branch 2 times, most recently from 1e20eba to 59fd8ae Compare October 5, 2024 06:52
@PIG208
Copy link
Member Author

PIG208 commented Oct 5, 2024

Thanks for the review! Updated the PR.

@PIG208 PIG208 force-pushed the pr-wrap-future branch 2 times, most recently from de48f34 to 59fd8ae Compare October 7, 2024 19:31
@chrisbobbe
Copy link
Collaborator

LGTM, thanks! Over to Greg.

PIG208 and others added 2 commits October 7, 2024 16:12
As a result, showErrorDialog no longer returns a Future that can be
mistakenly awaited.  The wrapped return value offers clarity on how the
Future is supposed to be used.

There is no user visible change because existing callers (other than
lightbox's) that wait for its return value are all asynchronous
handlers for UI elements like buttons, and waits unnecessarily.

See also discussion
  zulip#937 (comment).

Signed-off-by: Zixuan James Li <[email protected]>
Unlike ScaffoldFeatureController which inspired it, this class
doesn't offer a way to control the dialog, so it's not really
a "controller"; just call it DialogStatus.

A private final field with a public getter (of the same type)
is equivalent to just a public final field: nothing can set it,
and any library can get it.

Also generalize the description a bit: we currently use this
only for AlertDialog, but it'd apply equally well for any
dialog box.
@gnprice gnprice merged commit c5f4e93 into zulip:main Oct 7, 2024
@gnprice
Copy link
Member

gnprice commented Oct 7, 2024

Thanks to you both! Looks good; merging, with some tweaks to the interface on top:
c5f4e93 dialog [nfc]: Simplify new showErrorDialog interface a bit

@PIG208 PIG208 deleted the pr-wrap-future branch October 8, 2024 00:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integration review Added by maintainers when PR may be ready for integration
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants