-
-
Notifications
You must be signed in to change notification settings - Fork 299
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
Dismiss snackbars programmatically #20
Comments
@james-cordeiro In a nutshell, you'd like to be able to close a snackbar programmatically right? |
Apologies @iamhosseindhv for the delay. Essentially, yes. |
Hi, is this already implemented? I see it referenced in the CHANGELOG file but not in the PRs/recent commits. If not, I have prepared it in a local copy:
|
Hey @xiromoreira, it's not implemented yet. I use Sounds good a PR is always welcome. 👍🏼 |
When is this scheduled for release? |
@nthgol PR #47 for this been added to master and will be published when I add examples to the doc website. I suppose in less than a week. |
Currently, the only way around closing a currently opened snackbar (with autoHideTimeout set to 999999999) is to call the function again setting the timeout to 0 but this creates a "flash" of the snackbar before immediately disappearing because what the function actually does is on every call it adds to the snackbar queue before removing it immediately. With "open: true" paced before passed in "...options" then at least we can pass in "open: false" which will create a new snackbar to the "queue" still (which is not ideal) but at least this way we can avoid the "flash". This is only useful in situations where you set the max snacks to 1 - for example to create permanent bar notification such as "You are currently offline" for PWA apps which then disappears when the user is back online by enqueing a new snackbar. This is not the ideal solution but changing the order props allows for this slightly better UX to avoid the flash.
The ideal solution however, would be that the "handleEnqueueSnackbar" function returns the queue id so that subsequent calls that pass in the queue ID can target that same snackbar in the queue and force life cycle changes of the underlying snackbar instead such as "open: false" (which can then remove it from the queue to - perhaps another option). For example the signature could be "handleEnqueueSnackbar(message, options. id = null){...}", ID is last so that it is still backwards compatible or make it a part of the options.
Note: the ID cannot be sequential (i.e. array position) so once the snackbar messages reaches 4 then the next message gets the ID 2 (array being 0 based) and of course the ID's for the previous snacks will change so ideally, if the enqueu method is called passing in an ID (perhaps a timestamp id) that no longer exists then simply null is returned and action ignored.
The text was updated successfully, but these errors were encountered: