Just a cautionary tale, when using `AnimatedConten...
# compose
z
Just a cautionary tale, when using
AnimatedContent
(and its variants); if the
targetState
changes at all, even if it doesnt result in a new animation running, there will be additional recompositions as a result (I was seeing 2-9, instead of 1). I learned this the hard way, Id normally specify what I wanted to render as the
targetState
and use
transition.contentKey
to key it correctly; stripping out the stuff not directly related to the animation made an immense difference. Ill share some more details in the thread for anyone interested, I dont think this is a bug, but rather me misunderstanding how it works - hopefully it can save you from doing the same mistake as I did!
What I wound up doing is strictly using targetState for things that instruct which animation should be used.
Copy code
AnimatedContent(
    targetState = size,
    transitionSpec = Transition,
    content = { size ->
        // Content for size
    }
)
And if theres any other data associated with size in this case, Id store it elsewhere outside of the targetState... e.g. in a remembered value, etc.
i
You mean you won't use the size given from the lamda?
z
Ill still use the size in the lambda, but consider that theres a ton of other data accompanying that specific size (which really doesnt matter to the animation itself); thats what Im referring to as not being directly included in the AnimatedContent at all.
c
cc @Doris Liu