# compose


12/06/2020, 10:26 PM
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
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?


12/06/2020, 10:29 PM
Yeah this is kinda like props v state discussion in React


12/06/2020, 10:32 PM
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)
👍 1

Adam Powell

12/06/2020, 10:36 PM
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.


12/06/2020, 10:37 PM
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!