Support for bottom sheets from Material Design specs

[blake-mealey]

• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

It would be great to have an implementation of the Bottom sheet component from the 2019 Material Design specs (https://material.io/components/sheets-bottom/#). I didn't see an issue for it already so I figured I'd create this one to get the conversation started. I'd be potentially interested in helping to create that implementation, though not in the immediate future.

The specs break the component down into three types, which each have pretty distinct behaviour:

1. Standard bottom sheets

• These are permanently anchored to the bottom of the app and are elevated above the other content
• There are no guidelines on how these should look, other than that they should always be 100% width and anchored to the very bottom of the page

2. Modal bottom sheets

• These are sheets that appear after some user interaction and cover part of the screen, with a modal backdrop covering the rest of it
• Once open, they can potentially opened in "full screen" by swiping up
• They can be closed by swiping down or tapping on the backdrop
  • It's recommended to have some UI like a close button to close the fullscreen mode
• Again, there are very few guidelines on how these should look

3. Expanding bottom sheets

• These are a very specific UI component that appears at the bottom right of the screen and, when clicked, open a fullscreen modal sheet

I don't think it's necessary to provide a component for Standard bottom sheets, since this can already be achieved very easily, however it would be useful to have components for Modal bottom sheets and Expanding bottom sheets. Since they quite different, I think they should be separate components. I am more interested in the Modal bottom sheets which I have seen used much more in real applications and I think has more use cases, so I think that work should be considered a higher priority.

Since the specs don't give much direction on the visuals of the modal sheet, I think that should be completely left to the user, and only the behaviour should be implemented. Perhaps, with the exception of an optional bar element (not sure what to call it, see screenshots).

P.S. maybe we could call the bar element a "handle bar" or "handle" ?

Examples 🌈

Motivation 🔦

I think these are a really useful component which I've been seeing more and more in modern apps and I find are delightful to use. They are a great way to make options available to mobile users since it keeps things accessible to the thumbs at the bottom of the screen. It also helps to keep context with the activity you were in before opening the sheet. I would like to use something like this in one of my projects in the future.

I think the most complex part of implementing a bottom sheet is the swiping interactions and making them nice and fluid. If they don't work well, it loses much of its magic and delight-fullness. This is why I think it should be part of mui core, so that it is easy for developers to add a bottom sheet with solid behaviour with little effort.

[oliviertassinari]

@blake-mealey What's missing from the bottom drawer? https://material-ui.com/components/drawers/#swipeable-temporary-drawer

Note that most of our audience use React to write desktop dashboards & admins.

[blake-mealey]

Oh shoot, I did not see that component, thought I had checked everywhere to make sure you didn't already have this.

However, it isn't 100% what I need - I'm looking for the swipe up for fullscreen behaviour as well.

Your point about the audience of the framework is an interesting one, since I am using it for building a mobile-centered web app, and so my needs are definitely quite different from a desktop dashboard.

How difficult do you think it would be to extend the "swipeable temporary drawer" to include the fullscreen behaviour as a one-off for my project? Would it be easier for me to create a new component or start with the existing one?

[oliviertassinari]

Your point about the audience of the framework is an interesting one, since I am using it for building a mobile-centered web app, and so my needs are definitely quite different from a desktop dashboard.

I have seen most developers go with Flutter (Dart). I have personally started working on Material-UI for https://splitme.net/, a mobile app 🤷‍♂️.

---

Yes, you are right, the bottom sheet is different. I think that it would be interesting to support it. I would suspect we need a new component. Still, the logic will likely be close to the swipeable temporary drawer.

In #11546, you can find a hacky solution to support the backdrop. Flutter has an implementation it might be interesting to benchmark with.

[r3dm1ke]

A couple of use-cases from Material design spec where drawer probably would not be sufficient:

I think key features that drawer does not have are:

• It cannot be extended halfway, it will always be either fully open or fully closed
• Bottom sheet assumes another control that is visible at all times, similar to the AppBar. While doable with Drawer, it will require a lot of unnecessary complexity
• Bottom sheets can be full screen

And, slightly offtopic, there is a proposal to material design spec for side sheets

[r3dm1ke]

@oliviertassinari is that something that we would want to implement in the lab? If yes, I d open a draft PR so we can move the discussion/benchmarking there

[oliviertassinari]

@r3dm1ke Yes, I think that we can iterate on it in the lab :). However, I would be cautious not to have the core team invest too much time on it because:

• I believe it's a mobile-first type of component, something that resonates well with ~1/4 of the current audience of Material-UI.
• Ionic, which is supposed to be very mobile-focused, doesn't have it: https://ionicframework.com/docs/components. It suggests that if we want to improve mobile support, they might be some other items we could work on first, like screen transitions or refresher.

[ianaz]

Tried to get it to work as well using SwipeableDrawer (variant=temporary) by changing properties of the nested react-transition-group, but in the end it seem we need a change in code as I couldn't find any way to make react-transaition-group have a "min-height" or something. Any other suggestion?

Is it possible to put bounties on material-ui's issues?

[solaiagam]

Would like to see this on the lab or atleast a hacky version of Swipeable drawer.

[arpu]

could this be done with the modal mui implementation?