-
Notifications
You must be signed in to change notification settings - Fork 29.1k
SnackBar with action no longer auto-dismiss #173084
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
base: master
Are you sure you want to change the base?
Conversation
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.
Code Review
This pull request correctly implements the dismissible
property for SnackBar
to control whether it dismisses after a timeout. The implementation is straightforward, and the new functionality is well-covered by a new test case. I've found one minor issue with a leftover debug print statement that should be removed.
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.
I'm wondering if the default behavior of a Snackbar with an action still timing out should be kept. Although changing the default will be a breaking change.
/// | ||
/// Defaults to true. If false, the snack bar is still there even after the | ||
/// timeout, unless the user taps the action button or the close icon. | ||
final bool dismissible; |
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.
Not sure if dismissible is the right term, since tapping the action button dismisses the snackbar even when dismissible
is false. I think the timeout vs. non-timeout is what makes this API distinctive.
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.
Thanks for helping review the change! Then maybe dismissAfterTimeout
or autoDismiss
? I'm bad at naming. Any better names are welcome!
I'm wondering if the default behavior of a Snackbar with an action still timing out should be kept.
The main concern is the breaking change. If we change the default, we might need to inform developers to change all existing use cases. Just checked the specs on M3 website, it mentioned auto-dismiss though. Maybe we can disable the auto-dismiss if action/close icon is not null? WDYT @victorsanni @chunhtai :) ?
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.
Any better names are welcome!
Maybe something like canTimeout
or shouldTimeout
?
Maybe we can disable the auto-dismiss if action/close icon is not null?
The spec says "Snackbars with actions should remain on the screen until the user takes an action on the snackbar, or dismisses it." So we might have to change the default and inform developers. I opened #173127 to check how bad the breaking change will be.
But irrespective of that I think the new API is definitely useful.
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.
I'm confused by the spec. I read through it and in some places it suggests that the snackbar always dismisses by itself, even with an action. Maybe there's someone material to clarify?
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.
maybe persist
?
If the spec is contradicting itself, you can file an issue using the template from here https://buganizer.corp.google.com/issues/394084228
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.
Filed a ticket: b/438264879
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.
I just renamed the property and will wait for responses from the material team:)
883566c
to
f81edef
Compare
@@ -289,6 +289,7 @@ class SnackBar extends StatefulWidget { | |||
this.showCloseIcon, | |||
this.closeIconColor, | |||
this.duration = _snackBarDisplayDuration, | |||
this.persist = false, |
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.
What if developer wants it to not persist, but talkback is on? I think this may need to be nullable and if it is null, we can derive it from either action not null or accessibleNavigation is on. If it is set, we should respect it no matter what.
9c7dbf7
to
da486ab
Compare
973b93b
to
6991c52
Compare
@@ -459,6 +460,14 @@ class SnackBar extends StatefulWidget { | |||
/// * <https://material.io/design/components/snackbars.html> | |||
final Duration duration; | |||
|
|||
/// Whether the snack bar will stay or auto-dismiss after timeout. | |||
/// | |||
/// If true, the snack bar is still there even after the timeout, until the |
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.
maybe remains displayed
or remains visible
? To be more descriptive.
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.
Done
/// If true, the snack bar is still there even after the timeout, until the | ||
/// user taps the action button or the close icon. If false, the snack bar | ||
/// will be dismissed after the timeout. If this is null but the snackbar | ||
/// action is not null, the snackbar will persist as well. |
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.
Since we are not relying on screen reader on/off. We can make this non-null and do something like
SnackBar(
bool? persist
): this.persist = perisit ?? action != null;
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.
this will mean snackbar with action never auto-dismisses. which is a breaking change. Is this intended?
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.
yes, since this is the material guideline, we should make it the default and communicate to the developer.
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.
I wasn't too sure before because I was waiting for material team's response, but now they do. so we should go with this breaking change
/// | ||
/// If true, the snack bar is still there even after the timeout, until the | ||
/// user taps the action button or the close icon. If false, the snack bar | ||
/// will be dismissed after the timeout. If this is null but the snackbar |
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.
Maybe
If not provided, this is set to true if [action] is not null
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.
also consider separate each if
sentence into a new paragraph for readability
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.
Done
SnackBar
dismissible after timeout
Migration guide: flutter/website#12329 |
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.
LGTM, just one minor comment
@@ -198,23 +198,12 @@ class ScaffoldMessengerState extends State<ScaffoldMessenger> with TickerProvide | |||
Queue<ScaffoldFeatureController<SnackBar, SnackBarClosedReason>>(); | |||
AnimationController? _snackBarController; | |||
Timer? _snackBarTimer; | |||
bool? _accessibleNavigation; | |||
late bool? _accessibleNavigation; |
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.
why do we need late
? or do you forgot to remove the nullable?
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.
When I removed the block of code in didChangeDependencies
, I got this lint rule to add late to _accessibleNavigation
. Seems we still need it to control whether SnackBars have animation when it's sliding in and out.
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.
Or change it to bool _accessibleNavigation = false;
?
Fixes #173000
This PR updated the default behavior for Snackbar with action:
persist
forSnackBar
.Pre-launch Checklist
///
).