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?

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

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)

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.

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!