This differs slightly from the Material spec in that it puts 15dp between the top of the drag handle and the top of the sheet, right, instead of 22dp?

Something that seems to work well in my project, where I'm building a custom drag handle for before this lands (zulip/zulip-flutter#12), is a SizedBox with height kMinInteractiveDimension (48dp) and the drag handle vertically centered in that. Here's a comment I've written in my draft:

      // In the spec, this is expressed as 22 logical pixels of top/bottom
      // padding on the drag handle:
      //   https://m3.material.io/components/bottom-sheets/specs#e69f3dfb-e443-46ba-b4a8-aabc718cf335
      // The drag handle is specified with height 4 logical pixels, so we can
      // get the same result by vertically centering the handle in a box with
      // height 22 + 4 + 22 = 48. We have another way to say 48 --
      // kMinInteractiveDimension -- which is actually not a bad way to
      // express it, since the feature was announced as "an optional drag
      // handle with an accessible 48dp hit target":
      //   https://m3.material.io/components/bottom-sheets/overview#2cce5bae-eb83-40b0-8e52-5d0cfaa9b795

For an interface that exposes dragHandleSize, that could be a nice way to conserve vertical space. I guess it would behave badly for callers that want a dragHandleSize taller than 48dp. But I think callers that depart that much from the specified height of 4dp aren't really using the interface as intended.

(In my case, the advantage I found was that kMinInteractiveDimension was a convenient constant to refer back to elsewhere in my code, where I needed to express the space belonging to the drag handle. In particular, I wanted the scrollable content of the sheet (in a DraggableScrollableSheet) to start out below the drag handle in the y-direction, but then be scrollable under the drag handle in the z-direction, with help from a Stack. So then the contents get clipped when they scroll off the top of the sheet, instead of getting clipped by an artificial-looking line below the drag handle.)

Thanks for the suggestion! I do agree using kMinInteractiveDimension here is better than hardcode 22

Great! 🙂 I see in the current revision 5f47c77fd a variable _kMinInteractiveSize has been added; is there a reason for using that instead of the existing global kMinInteractiveDimension?

Hi Chris, I didn't realize that there is a existing global kMinInteractiveDimension, thanks for pointing it out to me! I will use it.

The implication here is that each time dragHandleMaterialState changes, the entire BottomSheet, along with the _DragHandle gets rebuilt. Is that true?

Yes, that's true and I think it's acceptable.

Although we added dragHandle in M3, the bottom sheet is draggable as a whole, so for dragHandleMaterialState MaterialState.focused, I use the _handleDragStart and _handleDragEnd functions in the bottom sheet class to define whether dragHandle is focused.