My use case is that I have a composable that takes a timeStamp of when something was submitted

submittedAt: Instant

and I want to show on the UI the time passed since then. I can now do this in all these three ways and it all works.

@Composable
fun MyComposable(submittedAt: Instant) {
    val now by currentTimeAsState(updateIntervalInSeconds = 1L)
    val someText1 = remember(submittedAt, now) {
        getRelativeTimeSpanString(submittedAt, now)
    }
    val someText2 by remember(submittedAt, now) {
        mutableStateOf(getRelativeTimeSpanString(submittedAt, now))
    }
    val someText3 = remember(submittedAt, now) {
        mutableStateOf(getRelativeTimeSpanString(submittedAt, now))
    }
    val someText4 by remember {
        derivedStateOf { getRelativeTimeSpanString(submittedAt, now) }
    }
    LogCompositions("RECOMPOSING!")
    Text(text = someTextX) // on someText3 I used `someText3.value` instead
}

As I understand for options #: 1. A simple remember with the keys that

getRelativeTimeSpanString

relies on so that when either of them change the

getRelativeTimeSpanString

function is called again and updates

someText1

. This will be recalculated every time

now

changes which in this case is every second (could be faster too in some other use case) therefore we get a bunch of useless recompositions. The

LogCompositions

functions confirms that. 2. I am not even sure if I was expecting a difference here, but I didn’t get one anyway. I am assuming I would define something like this if it were a

var

that was also mutated inside this composable, not even sure how different this is from #1. 3. Same thing, unsurprisingly 4. This should read

submittedAt

and

now

from the snapshot automatically and only update

someText4

when the result of

getRelativeTimeSpanString

is different from the previous result, therefore acting as some sort of conflate method that flows have, therefore doing recompositions only when it’s needed?

LogCompositions

does confirm that recompositions only happen when the text changes in the end. Bonus points for not even having to be explicit about the keys since

derivedStateOf

has some internal check as I understand. So in conclusion, should we always go for option #4 then? Since

derivedStateOf

isn’t free either, is this internal check that

derivedStateOf

does so expensive that we shouldn’t always do it? How would we make an informed decision on this, I am unsure. Note that even on options #1-#3

MyComposable

did not recompose when the

someText

was read inside another composable down lower that was not inline, therefore it had its own “smaller” recompose scope. But since it only work in that case it feels like a thing that I don’t want to think about in general, and most of the time this isn’t even the case.

Appendix of the functions that you see in the code above ^^

@Composable
fun currentTimeAsState(
    updateIntervalInSeconds: Long = 1L,
    clock: Clock = Clock.systemUTC(),
): State<Instant> {
    return produceState(initialValue = Instant.now(clock)) {
        while (isActive) {
            delay(updateIntervalInSeconds * 1_000)
            value = Instant.now(clock)
        }
    }
}

fun getRelativeTimeSpanString(
    from: Instant,
    to: Instant = Instant.now(),
): String {
    return DateUtils.getRelativeTimeSpanString(
        from.toEpochMilli(),
        to.toEpochMilli(),
        DateUtils.SECOND_IN_MILLIS
    ).toString()
}

// Taken from <https://www.jetpackcompose.app/articles/donut-hole-skipping-in-jetpack-compose>
@Composable
inline fun LogCompositions(msg: String) {
    if (BuildConfig.DEBUG) {
        val ref = remember { Ref(0) }
        SideEffect { ref.value++ }
        d { "Compositions: $msg ${ref.value}" }
    }
}

class Ref(var value: Int)

And one other note about the subtleties of these functions:

mutableStateOf()

doesn't work without

remember { }

. It can only track its changes internally if the

State

itself is remembered across compositions. You could also hold those

State

objects in some other class that lives outside of Compose, such as your ViewModel, and not need the call to

remember { }

since the ViewModel keeps the state alive across recomposition. Also,

State

objects in general can always be assigned to variables by delegate, so the differences between #2 and #3 are purely syntactic, but do the exact same thing. The implementation of the

by State<T>

delegate it literally just an inlined call to

.value

, so there is no runtime difference between one way or the other

(the example at https://developer.android.com/jetpack/compose/side-effects#derivedstateof has the same bug right now, we’re fixing that!)

I would treat

derivedStateOf

like a caching tool: It can be very useful in some situations, but you then also need to be extremely careful with how that caching gets invalidated. In most cases you’d probably be better off just doing the calculation directly.