A modern programming language that makes developers happier.

kotlinlang

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?

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

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

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.

However, I believe PullRefreshState (deprecated) uses this approach

I didn’t know of PullRefreshState :pray:, 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

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

&gt; 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.

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

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

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