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

Dismiss snackbars programmatically #20

Closed
james-cordeiro opened this issue Nov 4, 2018 · 6 comments
Closed

Dismiss snackbars programmatically #20

james-cordeiro opened this issue Nov 4, 2018 · 6 comments

Comments

@james-cordeiro
Copy link
Contributor

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.

@iamhosseindhv
Copy link
Owner

@james-cordeiro In a nutshell, you'd like to be able to close a snackbar programmatically right?

@iamhosseindhv iamhosseindhv changed the title Target snackbar in the queue Dismiss snackbars programmatically Nov 4, 2018
@iamhosseindhv iamhosseindhv added the must have really? it's 2019 and still we don't have this feature? label Nov 4, 2018
@james-cordeiro
Copy link
Contributor Author

Apologies @iamhosseindhv for the delay.

Essentially, yes.

@iamhosseindhv iamhosseindhv added new feature and removed must have really? it's 2019 and still we don't have this feature? labels Jan 7, 2019
@xiromoreira
Copy link

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:

  • Allow custom key in enqueueSnackbar() options and return it or the default generated one
  • Expose handleCloseSnackbar in the Provider

@iamhosseindhv
Copy link
Owner

Hey @xiromoreira, it's not implemented yet. I use to be published section of the changelog as a todo list / heads up for upcoming features.

Sounds good a PR is always welcome. 👍🏼

xiromoreira pushed a commit to xiromoreira/notistack that referenced this issue Jan 9, 2019
@nthgol
Copy link

nthgol commented Jan 23, 2019

When is this scheduled for release?

@iamhosseindhv
Copy link
Owner

iamhosseindhv commented Jan 26, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants