Would it be bad practice to pass a coroutine scope to a StateHolder class (through a `rememberCorout...

# compose

[gsala]

Would it be bad practice to pass a coroutine scope to a StateHolder class (through a rememberCoroutineScope in the the rememberXState Composable function) so I can run animations or timing logic within the state class?

[gsala]

Example:

@Composable
fun rememberXState(...) {
    val coroutineScope = rememberCorotuineScope()
    XState(coroutineScope)
}

class XState(val coroutineScope : CoroutineScope){
   ...
}

[ascii]

Yes because coroutines scopes are "unstable", so if you're passing the StateHolder to a composable, that function won't be marked as skippable. Try to work around it if you can.

[ascii]

However, I believe PullRefreshState (deprecated) uses this approach

[gsala]

I didn’t know of PullRefreshState 🙏, but that’s exactly what I need the scope for. I want to encapsulate the animation and timing logic in the state, so it’s as simple as possible to consume the state from the composables. I guess I won’t be able to mark the state as @Stable though

[efemoney]

Its not a bad practice. To address @ascii, you can always mark the state as stable

[ascii]

you can always mark the state as stable

Sure, but in this specific case, I believe it's not recommended? I can't point to any specific resource because I don't remember where I saw it.

PullRefreshState is also not marked stable, and that was made by Google devs for M2.

[Tunji Dahunsi]

This is generally fine.

[Zach Klippenstein (he/him) [MOD]]

That’s fine, as long as you ensure the lifetimes are matched

[Zach Klippenstein (he/him) [MOD]]

Note that if you’re doing this for a modifier, Modifier.Node has its own coroutine scope

[Zach Klippenstein (he/him) [MOD]]

And if you are just using it to do something like launch a coroutine on init, I’d prefer a suspend function called from a LaunchedEffect