Thread
#compose
    d

    dimsuz

    1 year ago
    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

    Tash

    1 year ago
    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
    d

    dimsuz

    1 year ago
    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

    Adam Powell

    1 year ago
    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.
    d

    dimsuz

    1 year ago
    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!