https://kotlinlang.org logo
p

pavi2410

07/04/2019, 2:39 PM
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.
m

matvei

07/04/2019, 2:43 PM
In compose, you can as well use
Copy code
@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)
p

pavi2410

07/04/2019, 2:44 PM
But why?
m

matvei

07/04/2019, 2:44 PM
Why not var?
p

pavi2410

07/04/2019, 2:45 PM
Yes, like
var count = 0
Or even
var count by state { 0 }
m

matvei

07/04/2019, 2:47 PM
Try to type the latter 🙂 But with +
var count by +state { 0 }
should work
p

pavi2410

07/04/2019, 2:49 PM
I just don't understand why in Kotlin there is a hacky thing such as prefixing a plus sign.
m

matvei

07/04/2019, 2:51 PM
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]

07/04/2019, 4:27 PM
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)
👍 2
a

Adam Powell

07/04/2019, 4:27 PM
I'm looking forward to the property delegation part 🙂
☝️ 9
l

Leland Richardson [G]

07/04/2019, 4:28 PM
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
l

louiscad

07/04/2019, 5:25 PM
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.
a

Adam Powell

07/04/2019, 5:54 PM
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
l

louiscad

07/04/2019, 7:14 PM
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.
a

Adam Powell

07/04/2019, 7:16 PM
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
k

krtko

07/05/2019, 5:57 PM
Maybe @pavi2410's point is the
@State
annotation is clearer than using a
+
to denote a UI state variable.
p

pavi2410

07/06/2019, 3:22 AM
I am OK with the use of property delegation. But if there is an annotation, it might require reflection at runtime 🙃
j

jim

07/08/2019, 10:48 AM
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.
👍 1
1
5 Views