SwiftUI uses `@State var count = 0` while in Compo...

# compose

[pavi2410]

SwiftUI uses @State var count = 0 while in Compose, val count = +state { 0 }. Why such a hacky thing (+state) is chosen?

[pavi2410]

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]

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

[matvei]

So if + will go away, it will be something like
val state = State(0)

[pavi2410]

But why?

[matvei]

Why not var?

[pavi2410]

Yes, like var count = 0

[pavi2410]

Or even var count by state { 0 }

[matvei]

Try to type the latter 🙂 But with +

[matvei]

var count by +state { 0 } should work

[pavi2410]

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

[matvei]

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

[Leland Richardson [G]]

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]

I'm looking forward to the property delegation part 🙂

[Leland Richardson [G]]

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]

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]

once it's ready for that, yes. It'll follow the same alpha/beta/rc cycle as the rest of the androidx libraries

[Adam Powell]

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]

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]

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]

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

[pavi2410]

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

[jim]

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.