[Snackbar] should be in root of document like Dialog?

[TrySpace]

When using Snackbar in a nested component, no amount of z-index is going to help it get on top.

Are there plans to make this work like dialog, so it will always be on top?

Is it also going to support prop open like the new Dialog, or will this mean problems with the timer?

[oliviertassinari]

Is it also going to support prop open like the new Dialog, or will this mean problems with the timer?

I'm currently working on it, see #2562.

When using Snackbar in a nested component, no amount of z-index is going to help it get on top.

We are using zIndex: 10, I think that we should instead use the muiTheme. I'm gonna take care of this.

Are there plans to make this work like dialog, so it will always be on top?

I don't think that we need to use the RenderToLayout component.
According to the material spec, we should only have on snackbar displayed at the time.
Hence, you should only have one instance of this component.

[TrySpace]

Cool, and yes, I only need one at a time, but when the snackbar is in a nested element, I think it will not be on top consistently if it is not placed in the root element? No matter how high the z-index, because of html hierarchy and ultimately depends on its parent's absolute and relative properties and a combination of it.

Or is z-index supposed to work differently when it's fixed, because it's fixed now and it's still behind its parent components, no matter what z-index I add to it.

Did you mean RenderToLayer like popover uses? Because I think that would be appropriate for this case. Because I think a Popover is also not supposed to be on screen multiple times, but in the end it's up to the programmer to make sure this doesn't happen, although some preventative measure could be handy, it also limits your freedom.

For example, if you would add two things consecutively very quickly, and only one Snackbar is allowed, you would miss the notification of the second added thing, while I would imagine having the second one slide over it is a visually intuitive thing, and is synchronized with the user's input. So in this case you'd be rendering multiple snackbars, but you'd only see the top, most recent one slide over the previous one temporarily.

[oliviertassinari]

@TrySpace I have just merged #2562 that should address your first point.
Regarding your second one.

For example, if you would add two things consecutively very quickly, and only one Snackbar is allowed, you would miss the notification of the second added thing, while I would imagine having the second one slide over it is a visually intuitive thing, and is synchronized with the user's input.

I still think that this should be handled by a single Snackbar. We could improve this existing behavior by adding a minimum time opened.
Right now, if the message or the action change will the Snackbar is opened, the Snackbar close and open with the new message ride away.
Is this answering your need?

when the snackbar is in a nested element, I think it will not be on top consistently if it is not placed in the root element?

You are probably right.
But, what's the use case of rendering a Snackbar in a nested element?

I have found an issue that may be linked #1824.

[tintin1343]

@oliviertassinari : Can this issue be closed? The linked issue is closed as well and it looks like you had already merged the PR to address the issue.

[oliviertassinari]

@tintin1343 If we close this issue, it would be a wontfix I'm fine with it.

[tintin1343]

Closing this issue. Refer to the above comments for more information.

[JesselJohn]

Hi. This was closed a long back but still, I feel nested fixed snackbars is still an issue. I have created a fiddle with scenarios I know https://jsfiddle.net/Zword/x13zwd9a/3/ . Using createPortal of 'react-dom' should fix this. I can make changes and raise a PR