Stylianos Gakis
06/09/2022, 7:10 AMval item = remember(someKey) { ExpensiveConstructedThing() }
instead of val item by remember(someKey) { mutableStateOf(ExpensiveConstructedThing()) }
However after reading about this very informative article and some official docs, to my understanding when we use by
on the state object, we get the neat effect of not reading the value at that moment, but deferring the read to whenever we actually need it. Which sometimes comes with the nice side-effect or reading that state object in a “smaller” recomposition scope meaning that when it changes we don’t invalidate the wider recomposition scope that the above definition may be in.
So if we do not do this, but use simply val item = remember(someKey) { ExpensiveConstructedThing() }
do we lose this nice side effect? When someKey
does change, and the result of item
changes with it, will it invalidate the recomposition scope in which it is declared in as opposed to where it is actually read?Albert Chang
06/09/2022, 7:39 AMState
instance. With val item by remember(someKey) { mutableStateOf(ExpensiveConstructedThing()) }
you won’t get the effect anyway because the State
instance itself changed.krzysztof
06/09/2022, 8:57 AMby
here (property delegation) more clearly.
TL;DR: it’s the same as using state.value
Stylianos Gakis
06/09/2022, 9:02 AMstate.value
but the important bit is that this read is deferred to when you actually use the value for the first time instead of on the declaration line, which means that when reading it you are likely to be in a smaller recomposition scope therefore invalidating only that instead of the entire thing.krzysztof
06/09/2022, 9:05 AMmyState.value
if not using delegate, while with delegate you just call value
Stylianos Gakis
06/09/2022, 9:07 AMAlbert Chang
06/09/2022, 9:08 AMStylianos Gakis
06/09/2022, 9:10 AMAlbert Chang
06/09/2022, 9:11 AMStylianos Gakis
06/09/2022, 9:22 AMkrzysztof
06/09/2022, 9:27 AMis only half true as it has implications on how often things recompose.I’d be interested in seeing an example of it - you say using delegate approach would trigger less recompositions than property access approach?
value
on receiver, hence I said it’s the same thingStylianos Gakis
06/09/2022, 9:43 AMval counter by remember { mutableStateOf(0) }
to val (counter, setCounter) = remember { mutableStateOf(0) }
then it will invalidate the scope in which this line is declared on, not just in which it is read in.
With all that said, now that I see what you said again better, if you do use just val counter: State<Int> = remember { mutableStateof(0) }
and you read it with counter.value in the same scope, then it is equivalent yes. When you were saying = and by are the same thing I was immediately thinking of using the destructuring declaration, as I’ve almost never seen someone use the =
syntax and keeping a hold of a State
object, since that’s imo the least convenient of all the approaches 😄krzysztof
06/09/2022, 9:50 AMStylianos Gakis
06/09/2022, 9:52 AMZach Klippenstein (he/him) [MOD]
06/09/2022, 3:15 PM