[Feature request] Expose AnimatedContentScope driving the animations into individual screens
StylianosGakis opened this issue · comments
Is your feature request related to a problem? Please describe.
With the addition of shared element transitions, it's convenient to be able to use the AnimatedContentScope which is driving the screen transitions to be able to animate an item going from one screen to another
Describe the solution you'd like
Just like androidx.navigation does here, which is to expose AnimatedContentScope to the composable content, Precompose could do the same and expose the AnimatedContentScope coming from here.
That way we can use this scope to drive other animations in our screens, including shared elements of course.
Additional context
You can see this in action in places like this https://x.com/GakisStylianos/status/1776691881243553937.
The change was in this PR, and in the linked lines is where the AnimatedContentScope from inside navigation was passed in to the .sharedElement() modifier to make this work.
wow shared element support! that's something that I've never expected, thanks for the PR!
Yup, quite exciting isn't it?
And because you're already using AnimatedContent under the hood you're at the right spot to let the library users use it, as long as you forward the AnimatedContentScope to them.
What are the API compatibility guarantees that you give to people using this library by the way? Would it suffice here to build a version of the library that always exposes the AnimatedContentScope and has the existing functions as deprecated and hidden?
If you are willing to do something like that which androidx.navigation did as well, then it's just a matter of seeing how they have implemented this too internally so that we don't wrap the rest of the destinations in this ugly empty AnimatedContent block.
And if you happen to be a bit too busy for this just let me know and I can try and dive into the internals a bit more to see if there's a good way to support this properly. No big promises but if it's not way too complex I might be able to pull it off.
API compatibility may not be a concern, as the deprecated and hidden existing functions looks good to me.
Before proceeding further, I'm curious whether androidx.compose.animation.SharedTransitionLayout requires Compose 1.7. If that's the case, it may not be suitable for multiplatform use until JetBrains releases Compose 1.7.
Yes that is indeed true, but my thought behind this is that PreCompose will not have to do anything to do with SharedTransitionLayout.
As long as PreCompose exposes the AnimatedContentScope into the composable which shows the destination's screen the callers can decide to use it or not use it, and they can also decide where their SharedTransitionLayout will live or if they will use it at all.
If you notice inside androidx.navigation they also have had nothing to do with those APIs. They just ship with this API of exposing the AnimatedContentScope and this simple enables users to use it if needed.
So SharedTransitionLayout being in alpha should not be a blocker for this proposed change here.
I made #312 as a PR which only does the real changes without the fluff around adding the sample in there.
When CMP properly ships the SharedTransitionLayout too then the samples can have an example for real. Until then we can skip that and just do the real change needed here.
I had some concerns for the API of a public interface changing, so let's make sure we get into the bottom of that before accepting or not that PR.
Fixed by #312