Status Update
Comments
jo...@google.com <jo...@google.com> #2
Hi,
Thank you for your feedback. I understand that this is a frustrating experience - we aren't in a super easy spot with Swipeable. It currently has a number of critical bugs that need to be addressed first (we are working on this), which is why we are limiting the surface we are exposing for Swipeable in M3 for the time. Our plan for the coming months is to focus on this specific area and improve developer experience.
Material 3 for Jetpack Compose is still in alpha - this means we consider components production-ready, but the API shape is flexible while in alpha. This gives us space to iterate while getting real-world feedback from developers, which ultimately helps improve your experience. Copy-pasting source code for components that are not (fully) implemented or exposed in an alpha version can be a good thing to do in the meantime! Owning the source code while the API shape is still flexible gives you a number of benefits like ease of updating dependencies, even if the APIs change, and allows you to evolve your components in your own pace.
We are aware of your request to expose rememberSwipeableStateFor in M3 though and will do so when the time is right and Swipeable in a good enough spot. I will close this issue in favor of
bl...@gmail.com <bl...@gmail.com> #3
..and no such anger. Sorry about that. Agree, close this. And thank you for your considerations. :)
bl...@gmail.com <bl...@gmail.com> #4
Just asking, do you have a reference to the critical bugs in swipeable
? I'm using the M2 variant and I'm actually pretty happy with it... Curious about which issues I can expect with it.
jo...@google.com <jo...@google.com> #5
Of course - they are mostly related to how we handle anchors currently.
Check out
The current implementation works well for things like swipe to dismiss. What are your use cases?
bl...@gmail.com <bl...@gmail.com> #6
That makes sense, because that is what I'm using it for. :-) I wanted my UI screens to be swipeable a la Telegram (
Sadly the navigation
authors are
bl...@gmail.com <bl...@gmail.com> #7
I've noticed one little glitch. Velocity seems to be too high if I 'jiggle' the swipeable element and then release. See attached video: the pane is swiped all the way even though I wouldn't expect it to for such a small drag.
Maybe it's the same issue as
ni...@google.com <ni...@google.com> #9
Hi, we hear your frustration and as my colleague pointed out, we are balancing many factors when committing to API surfaces. Each API goes through multiple internal reviews and we do read through all feedback/bugs as input on what APIs we build next. We ask for patience and we appreciate the time you've taken to give us input from the community!
However, all-caps aggressive complaints like
to...@gmail.com <to...@gmail.com> #10
I hope you guys will public the swipe api in material3.
I still use both material and material3 because I need `Modifier.swipeable` which is available in material 2 but internal in material 3.
jo...@gmail.com <jo...@gmail.com> #11
sy...@gmail.com <sy...@gmail.com> #12
Also, it is not at all encouraging that methods such as swipeableV2 and swipeAnchors are internal. If they were available, it would be much easier for me to create my own implementation of a bottom sheet. I join the request to make useful APIs available.
jo...@google.com <jo...@google.com> #13
#12, the underlying APIs have been published in Foundation 1.6.0-alpha01
as AnchoredDraggable
. We are currently working on migrating the M3 components from SwipeableV2
to AnchoredDraggable
, which will make copying easier. The M2 components have been migrated and can be used as a reference in the meantime.
As for the BottomSheetScaffold
feature request: The current layering is very much intentional. Customizing anchor positions can alter the behavior of the component to not match Material Design guidelines, which the Material 2 and 3 libraries are providing implementations for. If your use cases or design systems call for different behavior, we recommend building your own component (as you have). I will leave your original issue to the Material team to comment on.
A note on the ability to copy-paste code: we always strive to make sure our code is as easily copyable as possible, but have to make tradeoffs. In the case of BottomSheetScaffold
, ModalBottomSheet(Layout)
and more, we decided to opt for bringing behavioral and stability improvements before committing to a public API. Hope this helps!
Description
PLEASE STOP MAKING ALL USEFUL APIS INTERNAL
PLEASE STOP MAKING ALL USEFUL APIS INTERNAL
PLEASE STOP MAKING ALL USEFUL APIS INTERNAL
When Compose was released, it was accompanied with confident gloating about how it was easy to mix and match components with different granularity on the UI layers. One aspect of this was that many implementation APIs are accessible to developers. To my horror, more and more APIs are marked internal in the Material 3 library. For example, all the
SwipeableState
APIs (i.e.rememberSwipeableState
and all associated classes / functions) are now internal, while they were public in Material 2. This forces me to copy-paste the exact library code for swipe state into my own project, just so I can get a reference to the swipeable state, and this seems kind of idiotic to me.PLEASE STOP MAKING ALL USEFUL APIS INTERNAL
PLEASE STOP MAKING ALL USEFUL APIS INTERNAL
PLEASE STOP MAKING ALL USEFUL APIS INTERNAL
Jetpack Compose component used: androidx.compose.material3:material3:1.0.0-alpha10
Steps to Reproduce or Code Sample to Reproduce: