Is there a reason for the vanilla

SideEffect

not having key args? In the example in the official docs, you can see that there easily can be extra calls to the analytics. The

LaunchedEffect

is great but the suspend block is sometimes not needed and wasteful.

@Composable
fun rememberAnalytics(user: User): FirebaseAnalytics {
    val analytics: FirebaseAnalytics = remember {
        /* ... */
    }

    // On every successful composition, update FirebaseAnalytics with
    // the userType from the current User, ensuring that future analytics
    // events have this metadata attached
    SideEffect {
        analytics.setUserProperty("userType", user.userType)
    }
    return analytics
}

The equivalent is

DisposableEffect(key) {
    ...
    onDispose { }
}

yes but then you have the unused

onDispose

block

Yes, in practice it doesn't matter.

you could have passed no args if you want it to run with every composition

It's trivial to write a wrapper:

@Composable
inline fun OneShotEffect(key: Any, noinline block: () -> Unit) {
    DisposableEffect(key) {
        block()
        onDispose { }
    }
}

yeah that seems nice. But why isn't it in the API? I keep thinking there should be a deeper reason for it :)

Probably to discourage side-effects 🙂

Maybe extra suspending is super cheap?

LaunchedEffect

schedules its block on the main dispatcher, so its changes will always be reflected at least one frame later

I don't see very use cases for the

SideEffect

at all. You almost never want an effect to repeat on each composition

It's useful when you want to update a

remembered

state object through function parameters

why not just use

remeber(arg) {}

?

that would recreate the object when

arg

changes

Can you please give a short snippet of how that would work?

Check out the conversations in which these two comments appear: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1639692619286600?thread_ts=1639688997.283600&cid=CJLTWPH7S https://kotlinlang.slack.com/archives/CJLTWPH7S/p1647206404442389?thread_ts=1647192578.270479&cid=CJLTWPH7S

@Rick Regan thanks! @Adam Powell Please consider mentioning the expected idempotency in the docs.