Thanks for great "deep dive" series! Applying to typical Android apps:
State tracking works when reads are initiated from @Composable functions (not from e.g. onClick callbacks) and propagates through functions and computed properties, but not regular properties (e.g. adding backing field to _result in your From push to pull example breaks tracking).
Otherwise it's just a one-time read.
Is that understanding correct?
Looks convenient, but IMHO makes it harder to reason about code behavior. We can't say if a piece of code is "reactive" without looking above and below it in the call stack.
This is not a problem for UI code, but I'm thinking about using State in ViewModel & even deeper layers, so the call stack might be long.
State tracking works when reads are initiated from @Composable functions (not from e.g. onClick callbacks) and propagates through functions and computed properties, but not regular properties (e.g. adding backing field to _result in your From push to pull example breaks tracking).
Otherwise it's just a one-time read.
Is that understanding correct?
Yes.
Looks convenient, but IMHO makes it harder to reason about code behavior.
That can be true, there are definitely trade offs to this vs expressing reactivity in your types.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for great "deep dive" series! Applying to typical Android apps:
State tracking works when reads are initiated from
@Composablefunctions (not from e.g.onClickcallbacks) and propagates through functions and computed properties, but not regular properties (e.g. adding backing field to_resultin your From push to pull example breaks tracking).Otherwise it's just a one-time read.
Is that understanding correct?
Looks convenient, but IMHO makes it harder to reason about code behavior. We can't say if a piece of code is "reactive" without looking above and below it in the call stack.
This is not a problem for UI code, but I'm thinking about using
Statein ViewModel & even deeper layers, so the call stack might be long.Yes.
That can be true, there are definitely trade offs to this vs expressing reactivity in your types.