pavi2410

    pavi2410

    3 years ago
    SwiftUI uses
    @State var count = 0
    while in Compose,
    val count = +state { 0 }
    . Why such a hacky thing (
    +state
    ) is chosen?
    Pitfall of the current approach of Compose is that you have to write
    count.value = 1
    as opposed to
    count = 1
    . The latter is cleaner.
    matvei

    matvei

    3 years ago
    In compose, you can as well use
    @Model
    data class CountModel(var count: Int = 0)
    The
    +
    is the syntax for effects, which is subject to change, but essentially it's main purpose to give Compose knowledge about some building blocks that are not UI, so runtime can memorize and reuse it or call in at specific moments, such as compose lifecycles
    So if + will go away, it will be something like
    val state = State(0)
    pavi2410

    pavi2410

    3 years ago
    But why?
    matvei

    matvei

    3 years ago
    Why not var?
    pavi2410

    pavi2410

    3 years ago
    Yes, like
    var count = 0
    Or even
    var count by state { 0 }
    matvei

    matvei

    3 years ago
    Try to type the latter 🙂 But with +
    var count by +state { 0 }
    should work
    pavi2410

    pavi2410

    3 years ago
    I just don't understand why in Kotlin there is a hacky thing such as prefixing a plus sign.
    matvei

    matvei

    3 years ago
    This is definitely subject to change, API still has a long road to be finalized, so things will change, including how Effects are being created in composition
    l

    Leland Richardson [G]

    3 years ago
    Not 100% set in stone yet, but i’m fairly certain the plus operator is going to go away. That said, I believe the use of functions for state (and other things we currently call “effects”) is more composable than annotations like in swiftUI can be. It will very likely be
    val count = state { 0 }
    and
    var count by state { 0 }
    will also work if you prefer that (basically, current API just without the + being needed)
    Adam Powell

    Adam Powell

    3 years ago
    I'm looking forward to the property delegation part 🙂
    l

    Leland Richardson [G]

    3 years ago
    the code is there for that to work already. We just need to rebase the compiler to get property delegation compiling properly. CL is up, close to getting merged
    louiscad

    louiscad

    3 years ago
    Are you going to make milestone/preview/dev/pre-alpha/whatever releases at some point for us to try more easily, knowing it is in a sufficiently working state (as opposed to current state where you might sync the repo in a non working state, and can't know when it works again or if you should checkout an earlier commit you don't know)? I'm not asking for compatibility between those versions, just releases with a name/number that I can conveniently download and try using Compose to get a sense and of what's coming, and maybe a little experience.
    Adam Powell

    Adam Powell

    3 years ago
    once it's ready for that, yes. It'll follow the same alpha/beta/rc cycle as the rest of the androidx libraries
    fwiw we do run presubmit tests and such for changes in the repo, you shouldn't (often) sync it and get it in a bad state
    louiscad

    louiscad

    3 years ago
    I'm not talking classic alpha and all, but more preview. Something like weeklies, so it makes it easier to know what preview version you're using as an early previewer.
    Adam Powell

    Adam Powell

    3 years ago
    probably. We're not there yet though. 🙂 The dependencies on a modified kotlin plugin and android studio make that sort of standard snapshot a bit less useful. Once we can get it integrated into a more normal workflow it'll get easier.
    krtko

    krtko

    3 years ago
    Maybe @pavi2410's point is the
    @State
    annotation is clearer than using a
    +
    to denote a UI state variable.
    pavi2410

    pavi2410

    3 years ago
    I am OK with the use of property delegation. But if there is an annotation, it might require reflection at runtime 🙃
    jim

    jim

    3 years ago
    An annotation would not require reflection at runtime; we are a compiler plugin and process all of our annotations during compilation. Using an annotation has some advantages. For example, using
    +memo
    requires realizing that you're supposed to also specify an invalidation set of all the parameters used to calculate the memoized expression. If you miss one, your code will be subtly wrong. Using an annotation instead would allow the compiler to calculate the invalidation set of the expression, thus avoiding bugs. This has been the topic of a few hallway discussions; it's potentially a space worth exploring further.