Thread
#compose
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    Pulling this out of the thread to avoid derailing it… What does this mean for
    savedInstanceState
    ? Looks like it’s stuck around for now?
    l

    Leland Richardson [G]

    2 years ago
    I think this is being discussed. Have any strong feelings yourself?
    just a reminder that
    state
    :
    savedInstanceState
    ::
    remember
    :
    rememberSavedInstanceState
    so the most consistent change would be to get rid of it and just have
    rememberSavedInstanceState
    which perhaps we could/should rename in that case
    and the
    rememberSavedInstanceState { mutableStateOf(0) }
    would get an autosaver that would “just work”
    brandonmcansh

    brandonmcansh

    2 years ago
    Makes sense to me
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    rememberSavedInstanceState
    is a little weird to me conceptually. Why would I care about saving an immutable value? The kdoc explanation about mutable values makes more sense, but for
    rememberSavedInstanceState { mutableStateOf(0) }
    , you’d need to always wrap your custom
    Saver
    in one that unwraps/wraps the
    MutableState
    value, right? That’s a bit awkward.
    I think having an overload that specializes the type parameter upper bound to
    State
    or
    MutableState
    , and automatically wraps the
    Saver
    would solve that.
    TBH, even
    state
    seems so common and small that I’m a little disappointed to see it go away, although I completely understand the desire to minimize the amount of magic and the API surface, and this is probably a lot simpler to educate.
    l

    Leland Richardson [G]

    2 years ago
    i used to hold on to the short/simple/sweet
    state
    API so strongly that you’d have to pry it from my cold dead fingers
    but not so much anymore after having thought about it and sitting with the idea for a while
    i’ve seen a lot of people fundamentally misunderstand what the
    state
    API actually is
    and
    remember
    is the real fundamental API that people need to understand
    and right now, even if they did understand
    remember
    , they might miss the fact that
    state
    is just a convenient call to remember
    it makes demos and simple code slides more verbose, but i think in the long run its the right call. it stops conflating state with remember
    people missed the fact that
    mutableStateOf
    can be used outside of composition
    and also we are seeing patterns emerge where people want to create @Composable convenience factory functions that create an object (maybe using some ambient values) and then remember it, simplifying the usage site
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    It’s clever, but “i’ve seen a lot of people fundamentally misunderstand what the state API actually is” sure seems to suggest it’s too clever.
    l

    Leland Richardson [G]

    2 years ago
    for instance you could have
    @Composable fun SomeClass() = remember { SomeClass(SomeAmbient.current) }
    this pattern, i think, is probably bad. but having a reusable convenience method isn’t necessarily bad
    I’d like to push the convention of prefixing such methods with
    remember
    to hammer in the point
    so instead,
    @Composable fun rememberSomeClass() = …
    because the problem is it is too hard to tell at the usage site if this is something you ought to remember or not
    and even worse, you can’t do
    @Composable fun SomeClass() = SomeClass(SomeAmbient.current)
    because in that case, the caller can’t remember the result, because remember lambda blocks can’t have composable calls in them
    anyway. it’s a complicated choice, but this is probably the right call i think. perhaps worth a blog post or something describing the decision and the anti-patterns we saw emerge
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    makes perfect sense. I think it’s easy to over-index on the usefulness of cute little sugary things like this early on that just feel so good when writing samples and stuff, when they don’t actually provide much value in readability in real code and make the mental model you have to acquire so much bigger.
    l

    Leland Richardson [G]

    2 years ago
    yeah, exactly
    i think for a composable function to be understandable, its somewhat important to be able to identify which objects are “remembered” across recompositions and which ones aren’t
    this convention + API change will help move towards that
    Timo Drick

    Timo Drick

    2 years ago
    Just one thought about naming. In Kotlin there is the delegate "lazy" which does more or less the same like remember. So maybe remember should be called lazy? Btw. LazyColumnItems/LazyRowItems are doing different things. So maybe not use Lazy as Prefix for this Recyclerview thing. I think this would make it much easier to understand.
    Maybe just ColumnItems/RowItems
    l

    Leland Richardson [G]

    2 years ago
    semantically lazy and remember are very different things
    i don’t think
    lazy
    is the right term to use here. i’m actually quite happy with the name of
    remember
    but maybe others feel differently?
    Timo Drick

    Timo Drick

    2 years ago
    Ok than i still do not understand remember 😄
    brandonmcansh

    brandonmcansh

    2 years ago
    Lazy*Items are prefixed that way because of how they handle recomposition wrt visible items
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    remember
    initializes the value (invokes the lambda) eagerly/synchronously. The
    lazy
    delegate doesn’t initialize the value until it’s read (i.e., lazily). Like the
    lazy
    delegate,
    Lazy*Items
    doesn’t add its children to the composition until they’re scrolled into view.
    Timo Drick

    Timo Drick

    2 years ago
    OK yes that makes sense. Thank you for clarifying this.
    brandonmcansh

    brandonmcansh

    2 years ago
    Wrt Lazy*Item is it expected behavior for a recomp to not occur until scroll even if its state.value updates?
    andylamax

    andylamax

    2 years ago
    Lazy*Items
    has been bugging me so much. @Zach Klippenstein (he/him) [MOD]'s explanation has made it so clear to me. Thanks
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    RecyclerView
    is such a weird name, when you think about it – the main feature of
    RecyclerView
    is that it’s lazy. The fact that it recycles views is just an optimization to reduce memory usage and allocations. It doesn’t have anything to do with its core functionality. I like the
    Lazy*Items
    name a lot better, since it highlights the main feature/use case.
    l

    Leland Richardson [G]

    2 years ago
    new idea: we just hire @Zach Klippenstein (he/him) [MOD] to write all of our documentation
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    2 years ago

    https://media.giphy.com/media/jUwpNzg9IcyrK/giphy.gif

    l

    Leland Richardson [G]

    2 years ago
    you can write my slides and give my presentation while you’re at it 😬
    andylamax

    andylamax

    2 years ago
    😂😂😂😂😂😂
    gildor

    gildor

    2 years ago
    I think the biggest problem with this, that eventually everyone will have own
    state{}
    function to get rid of boilerplate
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    At least they’ll know how it works though 😅
    gildor

    gildor

    2 years ago
    they will just select
    remember { mutableStateOf(…) }
    , alt + enter, extract to a function and forget about it next minute (or maybe it will remember only one developer in the project who introduced this extension)
    even something like
    rememberState { … }
    would be probably better
    l

    Leland Richardson [G]

    2 years ago
    yeah i think we might consider adding
    rememberState
    we’re trying to be thoughtful here though. its a lot easier for us to add a convenience API later
    much harder for us to remove an API, especially one which would see as high of usage as this one would
    and it has become pretty clear to us that people are missing the fact that state is a convenience method
    and instead thinking its doing some fundamental thing
    so they miss the real fundamental APIs, which are
    remember
    and
    mutableStateOf
    gildor

    gildor

    2 years ago
    much harder for us to remove an API
    Maybe use OptIn annotation, same as Kotlin stdlib does
    andylamax

    andylamax

    2 years ago
    They'll have to OptIn the whole lib then. Coz its experimental it okay if things are shaken here and there until a concrete decision is made
    gildor

    gildor

    2 years ago
    Yes, but this looks as more fundamental decision, not only until Compose dev preview/alpha