Open caseycrogers opened 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:
Scenario 2:
Scenario 3:
Scenario 4:
My intuition here is that we need the following behavior:
size=1
is an exception to the above and is always retained before and after keyboard collapse/expandI'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.
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 theTextField
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:
false
?)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.