What are good resources to understand how Compose ...

# compose

[gsala]

What are good resources to understand how Compose helps separate UI and business logic? I feel like most examples use mutable local state, instead of state that is updated externally to the composable

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

I don't think it's true that Compose does, itself, help you separate those things. Leland talked about this a bit at the Android dev summit last year:

https://youtu.be/Q9MtlmmN4Q0▾

In general though, one specific recommendation is to build UI components that take in immutable data and callbacks instead of taking in rich, service-y objects and interacting with them directly. I know members of the compose team have said his multiple times in this channel but I'm not sure if it's "officially" written down specifically for compose. I would imagine the same recommendations and patterns would apply from React, Flutter, SwiftUI, etc. though, they all kind of share the same general concepts.

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

Eg the pattern of "lifting state up" is applicable to all these frameworks.

https://reactjs.org/docs/lifting-state-up.html

[gsala]

Alright 👍 So UI as a function of immutable data. But does Compose selectively recompose only the changes to the this data?
If I had a global app state, and a Composable function that renders that state, would the whole UI rerender because of one small change in the app state, or would Compose do some smart diffing and recompose only the changes ?

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

Presumably if you had one giant app state object, you would only pass pieces of that down your tree, and further break up those pieces the further down the tree you go. Compose will only re-invoke functions for data that it thinks has changed, so I think this should be fine.

That said, you currently need to annotate immutable types with compose's Immutable annotation for it to know a type is truly Immutable, but apparently that requirement might be lifted in the future.

[nlindberg]

I’m basically doing what zach is proposing in this redux<ish> pattern that im playing with: https://github.com/NielsLindberg/redux-kotlin/tree/master/app/src/main/java/com/nlpit/redux it does correctly only recompose part of the tree as you can see from the print statements if you run it.

[gsala]

I didn't know about the Immutable annotation.
That looks interesting @nlindberg

[nlindberg]

It’s a bit weird to me that if you remove the Immutable annotation from the various state data you parse to the compose functions, it recomposes the whole UI tree. I would expect that it still did a referential equality check even without the annotation and that the annotation would just be used to improve performance.

[jim]

@nlindberg A referential equality check isn't good enough, because when a mutable object is mutated over time, the reference (used for referential equality checks) remains unchanged. As a result, the mutated value wouldn't show up on the screen if we skipped updating when mutable values were referentially equal.

[nlindberg]

Mm makes sense, I think I just expected it to default more towards not recomposition than recomposition. But yeah I can see how you have to with mutable data.