I am seeing that a couple people make their view m...

# compose

[aoriani]

I am seeing that a couple people make their view models to expose the entire UI state thru a single property like a val state: State<UiState> . Is that a good practice? I am concerned about the granularity of the recompositions. Suppose that only one property of UiState changes, and that that property is consumed by only a single composable. Would only that composable face recomposition, or would the entire screen since state is the only State<T> object in the composable tree ?

[curioustechizen]

See related discussion https://kotlinlang.slack.com/archives/C5GB1NDGE/p1688565262429569?thread_ts=1688536514.245049&cid=C5GB1NDGE

[Colton Idle]

I always just expose state as a regular class with a bunch of inner snapshot state. gives me the granualrity i need. and way better than the copy boielerplate you get with stateFlow

[dave08]

Copy boilerplate isn't too bad with Arrow Optics btw...

[Colton Idle]

gotta try that out

[dave08]

This is especially nice when doing a few changes at a time: https://github.com/arrow-kt/arrow/blob/13d4c3f15a5325de4b9d65b7c79d87012f726b1e/ar[…]/optics/arrow-optics/src/commonMain/kotlin/arrow/optics/Copy.kt

[dave08]

And the docs are here: https://arrow-kt.io/learn/immutable-data/intro/

[dave08]

There's also Kopykat for a lighter solution: https://github.com/kopykat-kt/kopykat