Does

derivedStateOf

track reads of

State

objects at run time or compile time (or perhaps I should say dynamically or statically)? 🧵

All snapshot states are tracked at runtime but your code should work as iterating through the list is recorded even if the list is empty (because getting the size of list is recorded). If it doesn’t work, consider filing a bug.

Calling

filter

on an empty list never runs the filter’s lambda. Therefore the

contains()

on the

SnapshotStateList

list is never invoked.

doesn't both list should be using mutableStateListOf ?

I expect the state to update only when

aSnapshotStateListOfStrings

changes (that’s why it is the only

SnapshotStateList

).

How does

filter

know the list is empty?

It doesn’t, but

filter

is implemented with a for loop: when run, if the list you are filtering is empty, its lambda will never be called so

aSnapshotStateListOfStrings

will never be read.

if the list you are filtering is empty

How does the for loop know the list is empty?

but is it recorded when the list is not a stateList ?

Ok I didn’t notice that

aMutableListOfStrings

isn’t a state list. So this is expected.

It’s done at runtime. But I think there’s an actual bug lurking here that someone else just discovered last week: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1642650486349500?thread_ts=1642625335.328100&cid=CJLTWPH7S

I gave it a look but it seems a different issue, I’ve filed this which also include a simpler test to reproduce: https://issuetracker.google.com/issues/216136031

Echoing nitrog42 and Albert above, this is expected behavior. Referring to the simpler example in your bug,

private var switch

is a plain

var

, so Compose has no way of tracking when it changes. The solution to get the behavior you’d expect is

private var switch: Boolean by mutableStateOf(false)

, so that

derivedStateOf

can re-run if

switch

changes.

I’m not sure if we can call this a bug or expected behavior: The derived lambda does read from

state

even though the read is conditional on the value of

switch

(which is a plain var, no mutableStateOf ) so in principle the derived lambda should be rerun whenever

state

changes, regardless of the value of

switch

. But this doesn’t happen. My conjecture is that this most likely happens because the runtime decides whether to track

state

based on whether there had been any actual reads from it during the lambda’s first run. So if, during this first lambda run,

switch

is false then

state

isn’t going to be tracked by this derived state. IMHO this is the result of a limitation of the system (i.e. the fact that tracking of reads of state vars happens dynamically at runtime). If the tracking were to be based e.g. on statical source code analysis, then the read to

state

would always be tracked (because the read statement is actually in the code:

state.uppercase()

). N.B. I’m not asking nor suggesting to do statical state tracking, I’m just trying to understand why this is happening and, if my conjecture is actually true, perhaps we can improve the docstring of

derivedState

highlighting this peculiarity.

actually this remind me of the stringResource() / resources() method :

@Composable
@ReadOnlyComposable
private fun resources(): Resources {
    LocalConfiguration.current
    return LocalContext.current.resources
}

where

LocalConfiguration.current

is used to track changes and retrigger the get of resources instance

Exactly!

This is definitely the correct behavior. Tracking a state which is not read and causing recompostion when it changes results in bad performance. The correct solution is to use snapshot states, as Alex suggested.

It’s a tradeoff. It won’t cause recomposition though. It would re-run the derived lambda: recomposition is triggered only if the return value of the lambda is different from its previous, memoized, value.

It’s not a tradeoff. You are not using Compose’s mechanism (snapshot state) so you can’t expect it to work out of the box.

At risk of sounding like “it’s a feature, not a bug!” the dynamic state tracking at runtime allows for behavior that’s far more powerful than what static state tracking would allow. Let’s suppose you had:

private val derived: String by derivedStateOf {
    if (someFunction()) {
        state.uppercase()
    } else {
        "empty"
    }
}

When the block runs,

derivedStateOf

will call

someFunction

, and if the result is true then, it will read the

state

. If

someFunction

returns

false

, then

state

won’t be read, so from the perspective of

derivedStateOf

, there’s no way that any changes to

state

can impact the outcome. So how can the result of

derivedStateOf

ever change? By changing any snapshot state that

someFunction

read to make its decision. The power is that

someFunction

can refer to state that

derivedStateOf

has absolutely no knowledge about.

someFunction

could be delegated to an interface, with various logic, to another class, 5, 10 levels deep. If

someFunction

depends on 5 pieces of snapshot state, then the only way for

someFunction

to change is if any of those 5 pieces change. If that happens, then

derivedStateOf

will run again. Maybe the new result is still

false

, but it depends on 10 pieces of different state this time. If any of those 10 pieces change, then we calculate again. The other thing is that this isn’t unique to

derivedStateOf

, this is the behavior throughout the Compose system. The limitation here is that you have to work with the Compose snapshot state system throughout. If you refer to some

var flag: Boolean

, then from the perspective of Compose, it’s like doing

if (false) state else "empty"

. From the perspective of Compose, there’s no way for that

false

to ever become true. (this gets tricky for state managed outside of Compose, and the

resources

is a great example: the resources can change arbitrarily, so we need to depend on the

LocalConfiguration

as a Compose hook to trigger rerunning) The power of this system is that you don’t have to manually wire up all of the possible dependencies in a massive

Flow<T>

network (or choose your other observable type of choice). Each piece of internal state can independently and transparently create new state based on other state.

Thanks for the very good explanation. I just wish I could have understood all of this just by looking at the docs. But with this edge case I was unsure whether I was doing things according to the docs or not.