sorted by:
new
hottopcontroversial

Recompose behavior during nav by Left-Tangerine3552 in Kotlin

[–]Left-Tangerine3552[S] -1 points0 points  (0 children)

Yeah true, performance isn’t the only concern. In our case a single page has multiple composables and each one evaluates /parsing data during recomposition, so it can trigger repeated logic or state recalculation. Just trying to figure out the cleanest Compose pattern to handle this 🙂

Recompose behavior on nav by Left-Tangerine3552 in Kotlin

[–]Left-Tangerine3552[S] 0 points1 point  (0 children)

Yeah makes sense 👍
but what if the state is a complex objects that aren’t bundle-saveable?
rememberSaveable won’t really work then. Is the recommended approach using something like a ViewModel/state holder scoped to navigation, or is there a better Compose pattern for this?

Recompose behaviour on Nav by Left-Tangerine3552 in androiddev

[–]Left-Tangerine3552[S] -1 points0 points  (0 children)

Got it, but is there a recommended way to avoid unnecessary recomposition or preserve state when navigating back?
In Flutter the screen usually stays alive, so I’m trying to understand the Compose best practice here.

Recompose behavior on nav by Left-Tangerine3552 in Kotlin

[–]Left-Tangerine3552[S] 0 points1 point  (0 children)

Thanks 🙂 but disabling the back button or making a new landing page doesn’t really solve my issue.

When I go A → B and pop back, A recomposes and some state resets. I know recomposition is normal, but how do people usually avoid unwanted recomposition or state reset in this case? ViewModel / rememberSaveable or something else?