`retain { ... }` in compose-runtime 1.10.0 :eyes: ...

# compose

[eygraber]

retain { ... } in compose-runtime 1.10.0 👀

https://android-review.googlesource.com/c/platform/frameworks/support/+/3452915

[Pablichjenkov]

Will this retire movableContentOf ?

[eygraber]

It looks like it could retire ViewModel 🤞

[agrosner]

Definitely get close to retiring viewmodel, if you can do DI in compose with compile time safety

[curioustechizen]

There was a blog post about this in a recent AndroidWeekly or KotlinWeekly.

[curioustechizen]

https://proandroiddev.com/exploring-retain-api-a-new-way-to-persist-state-in-jetpack-compose-bfb2fe2eae43

[Vilgot Fredenberg]

Does this add anything over remember { ... } if you handle all configuration changes? (With android:configChanges="allKnown" you will *never see activity restarts)

[agrosner]

This also works when views on backstack

[Pablichjenkov]

Vilgot is not just that. Think of a bottom navigation, a drawer or a ViewPager or Composable backstacks as Andrew mentioned. When one of the screens is off or inactive. It loses everything created using remember{}. You had to hoist the state to not lose it. But now, there is no need anymore

[Zach Klippenstein (he/him) [MOD]]

Completely unrelated to moveable content, ftr

[Pablichjenkov]

I agree, but wasn't movableContent used to workaround this scenario, where a Composable disappeared but you want to still have it in the composition.
Is not the main purpose of movableContent but it was used for this case.

[Alex Vanyo]

movableContentOf only allows moving pieces of composition around from one place in one composition, to another place in the next composition.

If movableContentOf isn't invoked for any period of time, all that state gets wiped away - so it can't be used for retaining like retain can

[Pablichjenkov]

I had it wrong thanks for the clarification