Saw a code example like this... ```@Composable fu...

# compose

[Colton Idle]

Saw a code example like this...

@Composable
fun InstrumentsList() {
    var instruments by remember { mutableStateOf<List<Instrument>>(listOf()) }
    LaunchedEffect(Unit) {
        withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
            instruments = supabase.from("instruments")
                              .select().decodeList<Instrument>()
        }
    }

Could you just move the work from the LaunchedEffect to the remember {}.block?

[MR3Y]

What about using produceState?
https://developer.android.com/reference/kotlin/androidx/compose/runtime/package-summary#produceState(kotlin.Any,kotlin.coroutines.SuspendFunction1)

[MR3Y]

something like this:

var instruments by produceState(listOf()) {
withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
            instruments = supabase.from("instruments")
                              .select().decodeList<Instrument>()
        }
}

[ephemient]

you can't suspend in remember

[Francesc]

maybe a bit tangential, but this business logic should not be in your compostable and should be moved to your presenter/viewmodel instead. your compostable should receive the list of instruments as a parameter.

[Colton Idle]

yeah. honestly im doing compose multiplatform right now and trying not to use androidx VM and a little lost on how to remove business logic from compose. still iterating a bit here, because I'd agree that I don't really want to rely on side effects to do initialization of things.

[Francesc]

we're going off topic, but if this is for a a personal project, you could look at Circuit . It's still in alpha, so may be not an option outside your own projects.

[Colton Idle]

yeah. i know ive seen slacks lib for that and squares. id still like to learn how to do it without using a lib though

[Chrimaeon]

ViewModel is a architectural pattern. If you don’t want to use the Android library, nothing stopes you from creating your own class. You‘ll will loose the benefits from the lib, but you don’t have those benefits anyway when doing it in the composable.

[Chrimaeon]

And @Francesc it’s totally fine to have this logic in the composable. That’s why those side effect composable where created for. Not each and every screen needs a full-blown business logic architecture to retrieve its UI state.

[Francesc]

I have to disagree on this point, having the business logic not only breaks separation of concerns, makes your testing that much harder

[Chrimaeon]

If it’s a simple dialog that shows a list of selectable items?

[Francesc]

the example shown here is not that

[Chrimaeon]

How do you know that?

[Francesc]

it's fetching data from some data source, that's clearly something that does not belong in a compostable, at least in m book

[Chrimaeon]

What’s „m book“?

[Francesc]

my book

[Chrimaeon]

And your book is what? The masterpiece of architectural patterns?

[Francesc]

I'm not sure what you are getting at, I have my opinion, you have yours, I'll leave it at that

[Chrimaeon]

Sure, you said you disagree with my opinion 🤷‍♂️