Hi! When doing unidirectional flows in pre-compose Android I constantly notice that it is nice to se...

# compose

[dimsuz]

Hi! When doing unidirectional flows in pre-compose Android I constantly notice that it is nice to separate "static" properties from "dynamic" ones. For example if we render a List<User> where User(id, name, isSelected) and if this list is 100-200 users, then to immutably switch selection of 1 user costs a full realloc of whole List + 1 user object.

In light of this I tend to split into something resembling Pair<List<User(id, name)>, Set<String>> , i.e. "static" user props and "dynamic" set of selected ids.

It doesn't seem to be Compose specific, but I wonder, is this a good thing to do in general, or will ART optimize this anyway? And also: is there some terminology invented for this rather than mine static/dynamic thing?

[Tash]

Yeah this is kinda like props v state discussion in React

https://reactjs.org/docs/thinking-in-react.html#a-brief-interlude-props-vs-state

[Tash]

Also: https://github.com/uberVU/react-guide/blob/master/props-vs-state.md

[dimsuz]

Great thanks! I've found "props vs state" discussions when I googled, but I got the impression that they are discussing what to put into a "local" component state and what should come from above. In my case, I want "component" to be dumb and pass everything from above.

I'll read once more, more carefully! (I also seem to have found other links, yours look clearer)

[Adam Powell]

If your only concern is allocations, this is why we use kotlinx.collections.immutable internally in compose. Persistent collections share structure so you don't copy the whole collection when you make a small change.

[dimsuz]

Oh, so they're already available for use? I saw them few years ago in a pre-preview state 🙂 Nice to know, I'll give them a try!