SwiftUI uses `@State var count = 0` while in Compo...
# compose
SwiftUI uses
@State var count = 0
while in Compose,
val count = +state { 0 }
. Why such a hacky thing (
) 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.
In compose, you can as well use
Copy code
data class CountModel(var count: Int = 0)
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)
But why?
Why not var?
Yes, like
var count = 0
Or even
var count by state { 0 }
Try to type the latter 🙂 But with +
var count by +state { 0 }
should work
I just don't understand why in Kotlin there is a hacky thing such as prefixing a plus sign.
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
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 }
var count by state { 0 }
will also work if you prefer that (basically, current API just without the + being needed)
👍 2
I'm looking forward to the property delegation part 🙂
☝️ 9
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
🤩 6
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.
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
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.
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.
👍 3
Maybe @pavi2410's point is the
annotation is clearer than using a
to denote a UI state variable.
I am OK with the use of property delegation. But if there is an annotation, it might require reflection at runtime 🙃
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
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.
👍 1