[Snackbar] Display stacked Snackbars

[ZeeshanTamboli]

• [x] I have followed (at least) the PR section of the contributing guide.

Resolves #1824 Resolves #18098

This is an opt-in feature.

This work is a replacement of notistack.

Demo preview: https://deploy-preview-31991--material-ui.netlify.app/material-ui/react-stacked-snackbars/

~Initial implementation and idea could be reviewed.~

~Should I move it to MUI lab? If yes, how to reuse the Snackbar component styles into SnackbarsProvider styles without duplicating code by exporting from mui/material to mui/lab but not providing it to user in mui/material?~

TODO

• [x] Implement other props in SnackbarsProvider.
• [x] Add tests
• [x] Improve docs
• [x] Fix typescript types (Remove @ts-expect-error and fix types)
• [x] Move to lab (files + docs) (https://github.com/mui/material-ui/pull/31991#issuecomment-1087294766)

---

Edit: Ready for review!

[mui-bot]

Netlify deploy preview

• docs/data/material/components/snackbars/snackbars.md

@material-ui/lab: parsed: +3.73% , gzip: +3.23%

Bundle size report

Details of bundle changes

Generated by :no_entry_sign: dangerJS against 67e94e0dccfcdd24abf9030f8792800e3e5231f4

[mnajdova]

Should I move it to MUI lab?

Yes.

If yes, how to reuse the Snackbar component styles into SnackbarsProvider styles without duplicating code by exporting from mui/material to mui/lab but not providing it to user in mui/material?

I wouldn't care for this just yet, let's duplicate. In the end we can simply extract the styles and import from the @mui/material package as you've already done.

[ZeeshanTamboli]

@mui/core I will be waiting for a review before I continue further to add tests.

[AmirMehr]

I have developed a simple Snackbar repo, you can add it to the MUI for showing multiple Snackbars. If you do so, no need to install notistack. Here is the repo: https://github.com/AmirMehr/MaterialNotify

[siriwatknp]

Thanks for kicking off this effort. I'd like to have some clarification on these questions:

Roll out strategy

My understanding is that this work is a replacement of notistack but it is still blur to me on other aspects apart from the implementation like the goal, plan, migration. I think these topics are quite as important as the implementation so we should be able to answer them before rolling it out to the public (even in the lab). Can you share what's on your mind?

UX

It is too stiff when the noti leave the screen. If you compare with notistack, it is more smooth.

https://user-images.githubusercontent.com/18292247/165260826-be84f384-b40b-4d8d-bb93-ca8d35e79765.mov

[ZeeshanTamboli]

@siriwatknp

Thanks for kicking off this effort. I'd like to have some clarification on these questions:

Roll out strategy

My understanding is that this work is a replacement of notistack but it is still blur to me on other aspects apart from the implementation like the goal, plan, migration. I think these topics are quite as important as the implementation so we should be able to answer them before rolling it out to the public (even in the lab). Can you share what's on your mind?

Yes, the APIs are mostly similar to notistack which is built on top of MUI Snackbar component. We should mention this in the doc like: Inspired by notistack.

Although it is discouraged to have multiple snackbars as mentioned in material design specification, 1. https://material.io/components/snackbars#usage, 2. https://github.com/mui/material-ui/issues/1824#issuecomment-278839071, many people still need to display multiple snackbars in their applications as per the discussion in mui/material-ui#1824 and the imperative API style as discussed in mui/material-ui#18098 which this PR tries to solve.

I think notistack will be focusing more on notifications without Material UI as per https://github.com/iamhosseindhv/notistack/issues/184 and https://github.com/iamhosseindhv/notistack/issues/421 (although it's in alpha still). Can't be sure when that will be released.

There will be no need to install a separate package outside of MUI once MUI itself supports it under @mui/material (See remove the dependency on notistack).

Many people still use notistack for the material design but we can focus more in terms of:

1. Customization with the APIs MUI uses for customizing components.
2. Supporting SnackbarsProvider in global theme.
3. Perhaps extend it to base apart from unstyled single Snackbar component?
4. Providing continuous maintenance. One example is that notistack still uses React class component under the hood (although it's not something that breaks anything).

Migration is not needed anywhere as this an opt-in feature using the Snackbar component.

UX

It is too stiff when the noti leave the screen. If you compare with notistack, it is more smooth.

I can take a look at this if it is agreed upon to support it in MUI even though there is notistack.

[mnajdova]

I strongly believe this is a feature we are leaking to have in house, for example Chakra UI, Ant design and Mantine all support it, so I would propose continuing the effort @ZeeshanTamboli (some inspiration can probably be taken from these libraries in terms of implementation).

I agree with @siriwatknp that we should have some migration story in mind from notistack to this new API, simply because we were the ones suggesting developers to use notistack in our documentation.

[ZeeshanTamboli]

UX

It is too stiff when the noti leave the screen. If you compare with notistack, it is more smooth.

@siriwatknp Did you compare notistack with https://deploy-preview-31991--material-ui.netlify.app/material-ui/react-multiple-snackbars/#maximum-snackbars? Our demo uses the Grow transition which is the default transition of Snackbar. What notistack has is a Slide transition towards the right direction. We have a transition section below.

I strongly believe this is a feature we are leaking to have in house, for example Chakra UI, Ant design and Mantine all support it, so I would propose continuing the effort @ZeeshanTamboli (some inspiration can probably be taken from these libraries in terms of implementation).

@mnajdova Implementation can be reviewed further from last time. I have implemented almost all of the cases. Anything which is important in the primary version that I missed can be added. For other cases, I think it can be added later one at a time after more feedback from users. Do check the implementation and the preview docs and let me know what you think.

I agree with @siriwatknp that we should have some migration story in mind from notistack to this new API, simply because we were the ones suggesting developers to use notistack in our documentation.

We can have a migration guide section in the docs. The installation steps involved, the API names from notistack to this, etc.

[ZeeshanTamboli]

@oliviertassinari

@ZeeshanTamboli I don't/won't have the time to dive into detail in this PR but for what I could see so far, we are on the right track 👍.

Great! I am excited to release this!

Out of curiosity, I have found some of the leader in this space: https://npm-stat.com/charts.html?package=react-hot-toast&package=notistack&package=react-toastify&from=2021-05-22&to=2022-05-22. Likely projects we can learn from.

Sure.

It seems that we miss the @mui/base story for this feature. I would be in favor we start there instead of with Material UI: so we build at the lower level first. The upvotes in iamhosseindhv/notistack#184 suggest that there could be a large audience for this

Yeah, but now since the work is already almost done with the Material Design, I would like to keep it in Lab. Having it unstyled would be really useful. However most of the time, I think devs can use the content prop to have their own custom components. Transition components (Slide, Grow etc) are the only MUI components this one is dependent on which can be removed in Base.

[ZeeshanTamboli]

I was facing a problem of either having no new end of line space in error-codes.json file by doing yarn extract-error-codes or prettier wanting it to have a space. So I ignored this file in the prettier script in https://github.com/mui/material-ui/pull/31991/commits/81bed3bcca62c4d141d2cc35fe3f5de2f80071c8.

[ZeeshanTamboli]

Should we remove notistack package dependency from the docs structure in this PR now that the demo has been deleted?

[samuelsycamore]

Following a conversation with @mnajdova today, I think that the documentation for the stacked snackbars should live within the main Snackbar doc, following the format of the Tabs doc—see the Experimental API section. From a DX perspective, it makes more sense to keep the reader on a single page. If they need to build a UI with this functionality, they're going to check the Snackbars page before all else, and we don't want to make them jump around between pages.

[ZeeshanTamboli]

Following a conversation with @mnajdova today, I think that the documentation for the stacked snackbars should live within the main Snackbar doc, following the format of the Tabs doc—see the Experimental API section. From a DX perspective, it makes more sense to keep the reader on a single page. If they need to build a UI with this functionality, they're going to check the Snackbars page before all else, and we don't want to make them jump around between pages.

Yes this is what @danilo-leal suggested in https://github.com/mui/material-ui/pull/31991#discussion_r876571307 to some extent but we want it to have it implemented in MUI lab in the first version. Having the components exported from lab but showcasing the demos in Core Snackbar component would be confusing I believe unless we want to make it part of core in the first version. We show a demo of it in the snackbars page here like the Tabs Experimental API.

[oliviertassinari]

Yeah, but now since the work is already almost done with the Material Design, I would like to keep it in Lab. Having it unstyled would be useful. However most of the time, I think devs can use the content prop to have their own custom components. Transition components (Slide, Grow, etc) are the only MUI components this one is dependent on which can be removed in Base.

@ZeeshanTamboli To be clear, my point was not about not having the API in the lab, I think that this is great. My main concern is that it's a new feature, only for Material Design.

From a higher-level consideration, we are moving toward @mui/material being entirely built on top of @mui/base in v6. So all features will first be available in MUI Base before Material UI or Joy UI. Now the question is, should we start now, as we have all the context of the logic in mind to structure the code to be compatible, or do we ship to the lab, and then, somebody else will take on this task? I think that the former option is much better because it's a lot harder to course correct at a later point in time. I would also +1 for making it a general rule, enforcing that any new features in Material UI should be only a styling layer on top of MUI Base so that we don't take steps backward on our target.

[ZeeshanTamboli]

Thanks for the reviews. Summarizing the discussion here since there are multiple things and will help us what steps we should take next in this PR.

1. I have addressed all of the review comments except https://github.com/mui/material-ui/pull/31991#discussion_r850105670 and https://github.com/mui/material-ui/pull/31991#issuecomment-1135612014.

2. Olivier suggesting to have it in Base as well along with Lab. I agree with his points seeing the upvotes in https://github.com/iamhosseindhv/notistack/issues/184#issue-505874617. I am just a bit hesitant doing it in this PR since Snackbar standalone component is not yet migrated (UnstyledSnackbar) as seen in https://github.com/mui/base-ui/issues/10. I can work on it in a follow up PR. Or do you mean to have unstyled SnackbarsProvider or something along the lines of https://github.com/iamhosseindhv/notistack/issues/421#issuecomment-903198460?

3. Moving all the stacked snackbars demos and docs in Core's Snackbar component page, instead of having it in Lab. My point was that the implementation is done in @mui/lab so should we still show all the demos in Core? We show a stacked snackbar demo in the main Snackbar page.

Let me know how I/we should proceed.

[mnajdova]

Thanks for the reviews. Summarizing the discussion here since there are multiple things and will help us what steps we should take next in this PR.

I have addressed all of the review comments except https://github.com/mui/material-ui/pull/31991#discussion_r850105670 and https://github.com/mui/material-ui/pull/31991#issuecomment-1135612014.

For useId. It is a hook, so if you want to use it outside of a component you cannot. But, you can get some inspiration from the useId implementation we had in v4 - https://github.com/mui/material-ui/blob/v4.x/packages/material-ui/src/utils/unstable_useId.js (before this hook existed in React).

On notistack I would say yes, if we have this API we should remove the demo. We can mention it as a inspiration maybe.

Olivier suggesting to have it in Base as well along with Lab. I agree with his points seeing the upvotes in https://github.com/iamhosseindhv/notistack/issues/184#issue-505874617. I am just a bit hesitant doing it in this PR since Snackbar standalone component is not yet migrated (UnstyledSnackbar) as seen in https://github.com/mui/base-ui/issues/10. I can work on it in a follow up PR. Or do you mean to have unstyled SnackbarsProvider or something along the lines of https://github.com/iamhosseindhv/notistack/issues/421#issuecomment-903198460?

I agree, having an unstyled Snackbar & SnackbarProvider would be great. Those can then be used in the lab for building the Material Design versions of them. I am fine with doing it in a follow up PR, or we can create a PR for adding the unstyled version, and put this one on hold till that one is done.

Moving all the stacked snackbars demos and docs in Core's Snackbar component page, instead of having it in Lab. My point was that the implementation is done in @mui/lab so should we still show all the demos in Core? We show a stacked snackbar demo in the main Snackbar page.

I understand the direction, I would have done the same if I didn't know that we already are doing this for some other component :) Having all of them on the same page will also help with discoverability for this new API.

Let me know what you think @ZeeshanTamboli, but just wanted to mention that overall this has been a great execution.

[ZeeshanTamboli]

Okay, I will proceed with the following steps in order:

1. • [x] Keep this PR on hold and create SnackbarUnstyled component. It would also solve a part of Base mui/base-ui#10 . It will contain docs with demos as well in MUI Base. mui/material-ui#33227
2. • [ ] Merge this UnstyledSnackbar component in this PR and use it here for stacked snackbars in the lab implementation. Build it with Material design.
3. • [ ] Continuing in this PR, create UnstyledSnackbarsProvider and have the docs for it in MUI base. Basically a stacked snackbars page within MUI Base docs. (Unstyled stacked snackbars)
4. • [ ] Use UnstyledSnackbarsProvider within SnackbarsProvider in the lab implementation.
5. • [ ] Move the docs demos from MUI Lab to MUI core. Material design stacked Snackbars page will be removed from lab and we will have stacked snackbars demos within Core Snackbar component page.

@mnajdova What do you think?

cc: @oliviertassinari @danilo-leal @samuelsycamore

[mnajdova]

@mnajdova What do you think?

Sounds great 👍

[Nic-S]

I read with pleasure about this new feature, if I may I would have a consideration. The main advantage of react-tostify is the fact that you can use it outside the lifecycle of a react component, two practical examples of this use might be:

• invoke the snackbar within an action if the application uses redux-toolkit or other state management (in this case perhaps you can mitigate by passing the result of the useSnackbars hook but would need to find a way not to pass it every time you invoke an action that requires a snackbar)
• invoke the snackbar inside an interceptor, for example an axios interceptor that handles some generic errors. @ZeeshanTamboli Is there a way to expose the show() and close() api for the above examples?

[ZeeshanTamboli]

I read with pleasure about this new feature, if I may I would have a consideration. The main advantage of react-tostify is the fact that you can use it outside the lifecycle of a react component, two practical examples of this use might be:

• invoke the snackbar within an action if the application uses redux-toolkit or other state management (in this case perhaps you can mitigate by passing the result of the useSnackbars hook but would need to find a way not to pass it every time you invoke an action that requires a snackbar)
• invoke the snackbar inside an interceptor, for example an axios interceptor that handles some generic errors.

Thanks @Nic-S for taking a look!

@ZeeshanTamboli Is there a way to expose the show() and close() api for the above examples?

I am not quite understanding your examples without a code example. Anyway, we want to first release this useSnackbars hook and then we can iterate more on it and add new features.

[FaabLondon]

Hello, thanks for this https://deploy-preview-31991--material-ui.netlify.app/material-ui/react-stacked-snackbars/#api in which version of mui/lab is it available? It does not seem to be available in 5.0.0-alpha.112 thanks

[jpsala]

Hello, thanks for this https://deploy-preview-31991--material-ui.netlify.app/material-ui/react-stacked-snackbars/#api in which version of mui/lab is it available? It does not seem to be available in 5.0.0-alpha.112 thanks

It's not there yet it seems :(

[jpsala]

Hi, there is a release date for this feature?

[ZeeshanTamboli]

Hi, there is a release date for this feature?

There is no release date. We are planning to build unstyled stacked snackbars first. And then we will rebuild this on top of that unstyled version.

[jpsala]

Hi, there is a release date for this feature?

There is no release date. We are planning to build unstyled stacked snackbars first. And then we will rebuild this on top of that unstyled version.

Thank you!

[ZeeshanTamboli]

@mui/core I moved the docs from Lab to Material UI Snackbar page.

[gnowland]

Hi, there is a release date for this feature?

There is no release date. We are planning to build unstyled stacked snackbars first. And then we will rebuild this on top of that unstyled version.

Current progress: https://github.com/mui/material-ui/pull/31991#issuecomment-1148374025

(Since the "progress" comment is now hidden under "Load more..." (thanks, github 🙄 -- upvote the "pinned comment" feature request: https://github.com/orgs/community/discussions/47912))

[gnowland]

Hi, there is a release date for this feature?

There is no release date. We are planning to build unstyled stacked snackbars first. And then we will rebuild this on top of that unstyled version.

@ZeeshanTamboli do we have to wait until all unstyled components (https://github.com/mui/base-ui/issues/10) are completed, or now that the unstyled snackbar component is complete is work on

2. [ ] Merge this UnstyledSnackbar component in this PR and use it here for stacked snackbars in the lab implementation. Build it with Material design.

(from https://github.com/mui/material-ui/pull/31991#issuecomment-1148374025) able to proceed and this component be available independently of all unstyled components being completed?