Swipeable users, we're working on bringing Swipeab...

# compose

[jossiwolf]

Swipeable users, we're working on bringing Swipeable into Foundation. We have an API to configure the anchors based on the layout size and are looking for names!
More in thread! 🧵

[jossiwolf]

Here is the API - tentatively named Modifier.swipeAnchors. We are also considering renaming Swipeable to AnchoredDraggable.
We brainstormed some options but are also open to other ideas :)
1️⃣ Modifier.dragAnchors
2️⃣ Modifier.configureAnchors
3️⃣ Modifier.layoutAnchors
4️⃣ Modifier.draggableTargets
5️⃣ Modifier.withSwipeAnchors
6️⃣ Other - please comment

[gsala]

The function signature doesn’t have the possibleValues parameter from the KDoc

[jossiwolf]

Good catch - this is the correct one 🙂

[Stylianos Gakis]

I find the verb options quite confusing as it hints to something being done at that moment. Reading swipeAnchors makes it sound like you’re actually swiping something 😄

[Stylianos Gakis]

I just saw the twitter discussion, and I think the withSwipeAnchors feels like the best of all cases.
• It preserves the swipe name in there, indicating that it’s linked with the SwipeableState and should be used along with it. Which layoutAnchors and the other options don’t indicate
• It is not a verb which would make it look like you are actively swiping some anchors. Something which is not happening here, as this just setting the anchors themselves. withSwipeAnchors is pretty good at showing that imo
Just my 2c 😊

[Pablichjenkov]

There is a slight difference between swiping and dragging. Dragging should take no action after the finger/mouse is UP. Swiping implies some animation after the finger UP event based on the velocity of the touches. I am inclined for any names that contain swipe instead of drag because it is closer to what it does.

[eygraber]

I agree about not using a verb, but I don't think with* fits in with most other modifiers. I was thinking something like swipeableAnchors or draggableAnchors

[mgrazianodecastro]

swipeableAnchors feels good

[Joel Denke]

Oh sweet! swipeAnchor I think make most sense.
Very keen start doing my own bottomsheet implementation. Is the intention open up all current hidden swipeable state holders and such as well?
I am missing InteractionSource and gestureEnabled controlling. Like disable bottomsheet while other interaction happening on screen. Looking forward do custom scrim surface and custom swipe animation with offset progress.

[eddie]

I think swipeAnchors works just fine. Like many words in English, "swipe" isn't just a verb but it can also be a noun, and in either case here the more grammatically-relevant aspect is that it serves to modify "anchors". You could spend a long time trying to find an unambiguous alternative. For instance, you could call it gravityWells , because "gravity" is virtually always a noun and whether you're swiping or dragging the physical effect is the same, but then you'll still have people pointing out that "wells" can also be a verb. (And as if to prove my point, this message is already long enough.)

swipeAnchors is short and sweet while in this case still accurately conveying what is being contributed.