Marcello Galhardo10/29/2021, 5:40 PM
? For example, why would someone choose a
and do a
instead of simple using a
at first place? 🤔
Brian G10/29/2021, 5:44 PM
is fine to use, unless you are writing multiplatform code.
requires the Compose dependency, while
Marcello Galhardo10/29/2021, 5:48 PM
eygraber10/29/2021, 7:40 PM
is common code, so it could be used in a multiplatform project. One reason to use
would be to keep your state entirely immutable (i.e. if state changes a whole new object is emitted vs updating your existing state). This is helpful in architectures like MVI.
Brian G10/29/2021, 9:32 PM
, I don't think that's published for iOS (yet)
Marcello Galhardo10/29/2021, 10:54 PM
eygraber10/30/2021, 11:56 PM
works, except it's more hidden because you're doing it through state emissions (also the distinction blurs depending on how you work with it, i.e.
vs doing everything with a flow API).
Marcello Galhardo10/31/2021, 10:23 AM
, you would still change it by using
- which from my understanding is exactly what you described above with
MutableState.value = newValue
. Reference: https://developer.android.com/reference/kotlin/androidx/compose/runtime/MutableState Honest question: what is more hidden? Isn't the state emissions exactly the same? 🤔
eygraber10/31/2021, 3:26 PM
then you're not setting
anywhere; you're just emitting your state. If you use
then it is much closer to how
works. I think using
in this way "sort of" defeats its advantage over
. The way I'm using it to have a
for each field so that I can limit the recomposition to the specific scope where that discrete read is. By having your whole state in a
that you read in a top level composable, recomposition will affect that whole subtree.
Marcello Galhardo11/02/2021, 8:25 AM