flutter / flutter

Flutter makes it easy and fast to build beautiful apps for mobile and beyond
https://flutter.dev
BSD 3-Clause "New" or "Revised" License
164.32k stars 27.11k forks source link

Auto-expand draggable sheet on focus #126594

Open caseycrogers opened 1 year ago

caseycrogers commented 1 year ago

Initial feature request/issue report: https://twitter.com/RobertBrunhage/status/1655890369932935169

Is there an existing issue for this?

Use case

I have a bottom sheet that starts at half height and contains a TextField. When the user taps on the TextField to type something, I want the sheet to expand to it's max extent to give the user room to type with the keyboard now displayed.

Proposal

The above can be done by listening on the focus scope and manually manipulating the draggable sheet's scroll controller, but this is tedious for a pretty basic feature. My proposal is that we add an "expand on focus" feature that:

  1. Is gated behind a bool in sheet's contructor (defaults to false?)
  2. Expands the sheet to it's max size when a child of the sheet is focused

Open question: what should the sheet do when it loses focus? Shrink back to it's initial size? Shrink back to the size it had before it was focused? Should these behaviors kick in even if the user has interacted with the sheet since it was focused? My current thought is to do nothing on un-focus as the desirable behavior here is a bit ambiguous and the developer can implement their own logic if it's desirable here. If developers request a default behavior on unfocus it can be added later.

caseycrogers commented 1 year ago

I've got the PR finished and ready for review, except that after playing with it, it feels like pretty crummy UX that the sheet doesn't collapse itself when the keyboard is hidden again.

The customer (see Twitter thread linked in issue) has pointed out that what they really want is for a sheet that retains it's pixel-size on keyboard open and close. This definitely sounds like a better user experience, but I'm not sure how to handle the edge cases sanely: Scenario 1:

  1. The sheet is taking up the full screen, no kb
  2. Kb is expanded
  3. Kb is collapsed Q. What height is the sheet? A. Fullscreen

Scenario 2:

  1. Sheet is almost full screen, no kb
  2. Kb is expanded, sheet now takes up Fullscreen
  3. Kb is collapsed Q. What is the height of the sheet? A. Height from step 1???

Scenario 3:

  1. Same as scenario 2, but user drags sheet down a little between 2 and 3 Q. What is the height of the sheet? A. ???

Scenario 4:

  1. Same as scenario 2, but user drags sheet to fullscreen between 2 and 3 Q. What is the height of the sheet? A. ???

My intuition here is that we need the following behavior:

  1. The sheet retains it's exact pixel size (rather than fractional size) across keyboard collapse/expand
  2. size=1 is an exception to the above and is always retained before and after keyboard collapse/expand

I'm going to demo this out and see how it feels. However, I'm not sure there's a coherent way for this to interact with the snap system given that snaps are defined in terms of relative size.