Having written loads of `LaunchedEffect`s for collecting flows (that are not state, and no way to av...

# compose

[steelahhh]

Having written loads of `LaunchedEffect`s for collecting flows (that are not state, and no way to avoid them for now 🙃), I'm now wondering if there is any difference between one LaunchedEffect for all of them vs one LaunchedEffect per flow

See 🧵 for example

[steelahhh]

LaunchedEffect(Unit) {
        someflow
        	.onEach { /* ... */ }
            .launchIn(this)
            
            
        someflow1
        	.onEach { /* ... */ }
            .launchIn(this)
            
            
        someflow2
        	.onEach { /* ... */ }
            .launchIn(this)
    }
    
    // OR
    LaunchedEffect(Unit) {
        someflow
        	.onEach { /* ... */ }
            .launchIn(this)
    }
    
    LaunchedEffect(Unit) {
        someflow1
        	.onEach { /* ... */ }
            .launchIn(this)
    }
    
    LaunchedEffect(Unit) {
        someflow2
        	.onEach { /* ... */ }
            .launchIn(this)
    }

[Big Chungus]

Can't you just use myFlow.asState()

[steelahhh]

These flows are not state, but analytics, navigation and some project specific trickery. So nope, I unfortunately cannot do that

[Zoltan Demant]

I think that would just result in the first flow being collected, suspending the coroutine until cancelled (or effectively, forever). Ive seen some peeps call launch{} inside the LaunchedEffect to collect multiple flows though, but I dont know how that differs from just using multiple LaunchedEffects!

[myanmarking]

no. launchIn doesn’t suspend so its fine in that regard. idk about best practice tho

[Zoltan Demant]

Youre right @myanmarking! Effectively its the same thing, but shorter, than launch { flow.collect } 👍🏽

[myanmarking]

exactly

[myanmarking]

i started to use launchIn instead of launch+collect in the viewModel because too many times i ‘missed’ the fact that collect will just suspend 😛 so the code next to that call was not executing. It’s stupid, but happens :p

[Stylianos Gakis]

Since I saw launchedIn mentioned here, I feel the obligation to link this https://www.billjings.com/posts/title/avoid-launchin/?up=technical . I really liked it as an idea and I think that it has helped me make some of my code nicer. I still use it myself too, but a tiny bit less.

[Arjun Achatz]

I think it's best to break them up, as mentioned here, a less experienced developer might accidentally call collect instead of launchIn, and then your whole chain of effects are potentially lost

[myanmarking]

@Stylianos Gakis yes i read that post a while ago. I disagree with the autor. There are plenty of usecases for launchIn

[Stylianos Gakis]

Absolutely. Whatever works for you and your team. I just thought it’d be a perfect opportunity to introduce this point of view as well as I think it’s interesting, and I personally really like the idea of using coroutines for more than just normal RX-like async callback work. Or at least knowing that I have the possibility to do so 😉

[Adam Powell]

More LaunchedEffects have slightly more overhead, otherwise these approaches are mechanically equivalent

[Adam Powell]

Bill's blog post is an excellent read and a good way to calibrate your thinking when it comes to flows. The OP shows one of the exceptions that prove the rule, since it's just being used as a shortcut for launch { foo.collect... }

[Adam Powell]

But it's highly likely that as code like the OP's grows over time, you will want to refactor and extract pieces of it, and launch+collect will make that a more obvious transformation than onEach+launchIn.

[Adam Powell]

If you've trained yourself to read onEach+launchIn as equivalent to launch+collect then this might not be an issue for you, but as Bill pointed out, if you haven't and you think in callbacks rather than in suspend, you'll probably find a worse way to do that refactoring