The docs say not to use `LaunchedEffect(true) { }`...

# compose

[reactormonk]

The docs say not to use LaunchedEffect(true) { }. I'm using it with LaunchedEffect(true) { entries = someAPI.load() } where I'm loading in possible autocomplete solutions. What would be the correct way to do this?

[Stylianos Gakis]

Well, do you want your autocomplete options to be changing every time the text input also changes?

Also passing Unit (Typically Unit is a better indicator rather than passing true in there or some other such constant) as the key is not always a mistake, sometimes there are real usages for it.

[reactormonk]

No, that'd just be the list of possible selections. I'd do the filtering at a later stage.

[Stylianos Gakis]

And what if the network request fails?

[reactormonk]

Then the whole view is useless. It's a debug view for myself only atm ^^

[Stylianos Gakis]

Well then do it this way if you don't care for such things

[reactormonk]

And if you would care for such things?

[Stylianos Gakis]

The work wouldn't be kicked off from the UI for sure. Your ViewModel would contain this code. Unless you're using compose in your VM too with molecule or something like that?

[reactormonk]

Separating out my debug view code into VM has been severely lacking so far. What would you recommend there? It's mostly for "how does this Android internal thingy work" code and less for code that goes into actual production code.

[Stylianos Gakis]

How does what thingy work, how effects in compose work?
I am not sure I understand your question.

[reactormonk]

Ah, I'm interfacing with a lot of different Android APIs, so I'm writing some code for e.g. interacting with the bluetooth device, where I can send various signals with buttons & collect the responses.

[Stylianos Gakis]

Right, and do you mean that this is why you haven't moved things to your ViewModel or what?

[reactormonk]

Yeah, exactly. I'm currently elaborating if it'd be worth it to learn how to do that in a consistent manner. Good habits etc. Molecule looks interesting, are there other options in this space besides regular viewmodels?

[Stylianos Gakis]

You can also just use a ViewModel-like class which simply does not inherit from ViewModel. You will not get the surviving guarantees on config changes etc that VM gives you, but you might just not need those anyway if you're doing a debug thing as you're saying.
Then it's just a normal state holding class which does this kind of work.
Some docs https://developer.android.com/topic/architecture/ui-layer/stateholders#types-state

[reactormonk]

Cool, thanks!