Is there any way to reset `targetContentZIndex` after a `ContentTransform` animation is done in `Ani...

# compose

[andrew]

Is there any way to reset targetContentZIndex after a ContentTransform animation is done in AnimatedContent?

[andrew]

I came up with a hacky solution here, not ideal, if there’s a way to reset this, that’d be great

[Doris Liu]

Curious what's your use case for needing to reset it?

[andrew]

I'm implementing a stack navigator with transitions, I need to make sure when popping, the previous screen in the stack doesn't overlay the old current screen

[andrew]

Right now I'm just basing it off of the size of the history

[Doris Liu]

Having the zIndex based on the size of the stack would be a good choice for your use case. How and when would you want to reset the zIndex if we had a way to reset it? I'm assuming you are trying to reset the zIndex for the outgoing screen?

[andrew]

My thinking was to expose an initialContentZIndex to go alongside target

[Doris Liu]

What would you reset it to?

[andrew]

You can see the current behavior of it here, so you can visualize the zindex

22-03-07-18-53-50.mp4

[andrew]

initial zIndex would be 0 whereas the target zIndex would be -1

[andrew]

That way the previous, initial screen, would still be elevated

[andrew]

Currently what I’m doing

[Doris Liu]

That sounds nice in the ideal scenario. What if the animation gets interrupted and there are more than one outgoing screens?

[andrew]

Hmmmmm, that’s a good point

[andrew]

In this case, keeping it based on history size is ideal

[Doris Liu]

(The question above was one of the things that we factored into this design.) It's entirely possible there are better solutions than what's provided. 🙂 I'm open to new ideas

[andrew]

Is there any kind of perf drawback with zindex?

[andrew]

Especially with really large ones?

[andrew]

I guess as long as you have relevant data captured within this scope, it’s probably better to use that

[Doris Liu]

Do you mean perf drawback in the fully obstructed cases where there is a rich screen underneath?

[andrew]

No, because there would be no screen underneath technically, until a transition occurs

[andrew]

I just mean if you set a really high zindex level in general, is there any limitations with that?

[andrew]

With how drawing is handled, etc?

[Doris Liu]

I don't think the specific zIndex value matters much to performance. The zIndex eventually comes down to a sorting: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]ommonMain/kotlin/androidx/compose/ui/node/LayoutNode.kt;l=394

[andrew]

Good to know!

[Doris Liu]

Pretty cool demo btw! 😍

[andrew]

Thank you, my manager gave me the blessing to rewrite our react native app, we’re kinda sick and tired of the performance overhead and tooling effort associated with it

[andrew]

The react native app has an inconsistent design system as well, so the goal is to get it up to RealPage’s RAUL v3 design language spec

[Doris Liu]

Inconsistent design as well?

[Doris Liu]

Oh, as well as the perf

[andrew]

Yup, plus, the codebase feels kinda thrown together in places, poor patterns in use, poor state management

[Doris Liu]

Sounds like you have a fun project on your hand. 😉

[andrew]

And don’t get me started on React Native’s bridge concept 😆

[andrew]

It has been so far, I’ve been itching for more excuses to use compose other than just hobby projects

[andrew]

Being able to do the little things, and still have this perform with almost 0 jank… it’s been really fulfilling

[Doris Liu]

Glad to hear that. Let me know if you have any other questions/suggestions on animation. As I was just thinking about it, there's another interruption scenario during the screen transition, which is going back before the push onto the stack is finished, then all of a sudden the incoming screen becomes outgoing, and vice versa. We definitely don't want the zIndex to be swapped in that case - zIndex jump almost never looks good

[andrew]

Yeah, as of now though, I haven’t seen any kind of major zindex jumping with using the stack, but any sanity check would be a huge help 😛

[Doris Liu]

This design is forcing zIndex to be considered more holistically.

[Doris Liu]

Yeah, as of now though, I haven’t seen any kind of major zindex jumping with using the stack, but any sanity check would be a huge help

Yea, this design doesn't allow one to muck with zIndex on outgoing content. But it is possible to cause a zIndex jump in an interrupted animation, where the outgoing screen becomes the new target with a new zIndex.

[andrew]

That should have a lesser zindex still, since the stack is smaller at time of eval though, right?

[Doris Liu]

if you use the stack size as the zIndex, it should be the same.

[Doris Liu]

(unless you keep the transient entry that is currently exiting in the stack)

[andrew]

I’m not keeping it currently, but that’s also why theres the +1 and -1 offsets on the zIndex added to the stack size

[andrew]

That bit is handled internally by the transition system

[Doris Liu]

In that case I would expect the current size of the stack to be sufficient, maybe that's what history.size + 1f is?

[andrew]

Yeah, that is to compensate for the loss of the current item

[andrew]

Though, -1 probably wouldnt be needed then

[andrew]

-1 is definitely not needed

[andrew]

@Doris Liu did you have any say on the Swipeable implementation used in material?

[Doris Liu]

Mostly in terms of influencing design through the shape of lower level animation APIs. Why

[andrew]

Is there any reason why the internal progress is documented to return 1F when currently 0, but not actually animated? It’s not all that clear to me, seems counterintuitive

[andrew]

I ripped the current impl from the material code, but there seems to be indication of it potentially moving to foundation, I just wanted to know if this behavior was absolutely set in stone?

[Doris Liu]

The SwipeProgress seems to be experimental, so definitely not set in stone. I'd recommend putting your feedback in a bug. The documentation says when it's not animating, the from/to would be the same, so the progress fraction won't matter that much I assume?