Update Drawer to support Material 3

[darrenaustin]

As part of the Material 3 specification there are updates to the Navigation drawer visuals:

Currently Flutter only has the Drawer widget, but it is pretty bare-bones. We should look into possibly creating a new NavigationDrawer. It would be good if that could be integrated with the NavigationDestination used by the NavigationBar as well.

[rydmike]

@darrenaustin even the current Drawer container widget has some challenges when it comes to being able to deliver a M3 themed version of it.

The M3 spec says the border radius on it should be "0,16,16,0dp corner radii", basically the visible corners should be rounded 16dp.

The current Drawer widget container is however used in Scaffold in both drawer and endDrawer property, and currently I see no way to make a DrawerThemeData that could correctly consider both the directionality of the ambient app and if the Drawer is being used in a Scaffold as a drawer or endDrawer and always get the M3 or desired border rounding on the correct visible corners.

Imo the visible edge corner shape should also be themeable ,so we can change the border radius, of course default would be M3 spec, when opting in on M3. Currently there is no way to correctly do this with its current theming capabilities, or perhaps I'm missing something.

[ArishSultan]

@rydmike @darrenaustin I think we will need to redesign the existing Scaffold or make a new Scaffold with material 3 capabilities since the current Scaffold is only capable of showing an elevated Drawer, since the drawer gets wrapped with DrawerController behind the scenes. there is no way to implement an always visible drawer using Theme only, the new Scaffold should also have support for NavigationRail.

Share your thoughts.

[bernaferrari]

@ArishSultan if you want to be radical, deprecate drawer and add sideMenu/navigationMenu to the Scaffold, which can be a Drawer that gets automatically expanded/shrinked depending on the screen size, or a rail that becomes navigation on phone.

[mhoad]

Just to quickly speak to the point @bernaferrari mentioned, just went through that process of getting that to work and it was much more painful than I would have anticipated for such a fundamental but of functionality, it feels like there is a lot of room here to improve the DX and the idea they mentioned is ultimately what I wish I could have done in the first place.

[elbeicktalat]

@darrenaustin even the current Drawer container widget has some challenges when it comes to being able to deliver a M3 themed version of it.

I don't think that is an issue caused by the actual Drawer, this issue is related to the Scaffold.

What I have tried:

• Use Directionality widget, but it doesn't works since it change the text direction also.

To solve this issue I suggest the following:
Edit: Since the drawers are a widget, so the first solution cannot work.

1. Add border radius property in the Drawer.
2. Add a new property to the Scaffold to determine the border radius of both drawers.

Thanks!

[elbeicktalat]

@rydmike I don't agree with you, the drawer widget is a very simple widget so to me it doesn't make a sense having a new one.

Yes it's more easy but not the best solution to me.

[rydmike]

@elbeicktalat I actually agree with you, it was @bernaferrari that suggested making a new one. Still a new additional drawer/menu widget with more out of the box features would also be useful, but for different reasons. In that case I think the existing simple Drawer container should still exist and be available as starting point for own custom menus, like today.

My comment was only concerning making the current Drawer have more theming properties. Could be something like visible corner radius, and screen edge corner radius (in addition to current general border radius, well Shape actually). Then when those widget props or theme props are used, let the widget figure out which corners should be rounded based on current directionality or if it is used in Scaffold drawer or endDrawer property. The last one might be tricky, since the widget itself or theme for it has no knowledge of that.

TLDR:
I just want to be able to Shape theme the Drawer border radius for its visible side, so correct side is rounded regardless of if Drawer is used in Scaffold drawer or endDrawer, and be directionality aware as well for these cases.

About theming widgets
There are a few widgets around that cannot be themed to get the same design and behaviour as their default un-themed design, because some of the default design behaviour is linked to logic when its theme is null, and that logic cannot be replicated when the theme is not null. This is imo poor design that should be avoided. The border radius on the FAB is an example of such a case, SnackBar is another one, they will need fixes for it. Can we please not make this widget such a case too.

[elbeicktalat]

I don't know if we could integrate the Navigation Destination used by the Navigation Bar only in one PR. since there is a lot to do.

[elbeicktalat]

This requires #108162

[hangyujin]

I created a doc to discuss about drawer/navigationDrawer in M3 , please feel free to comment!

https://docs.google.com/document/d/1tlgCIN5VYGM8LBT08y29OyeLb9EIhg2HgSo5UgmhXfk/edit?usp=sharing&resourcekey=0-FN54My8BuIgqRHhpshaEfg

[MarcusWichelmann]

@hangyujin Thanks for implementing this. But I think one important thing is missing here:

Is it possible to make the children of NavigationDrawer scrollable? I have more NavigationDrawerDestinations than might fit on every screen.

As the implementation looks like, this is not supported?

[MarcusWichelmann]

I also wonder how safe areas should be correctly handled in regard to scroling? Maybe the widget should provide a good default behavior for this?

[MarcusWichelmann]

Now reported here: #116782

[darrenaustin]

This drawer issue is fixed with #115668. The scrolling issue will be tracked in #116782.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.