This way of observing a SharedFlow (repeat=0) seem...

# compose

[Michal Klimczak]

This way of observing a SharedFlow (repeat=0) seems to work but it looks suspicious, especially because of LaunchedEffect(true). There's probably some other Effect that I should use, right?

val pagerState = rememberPagerState(pageCount = pages.size)

LaunchedEffect(true) {
    //SharedFlow 
    pageChangeFlow.collect { 
        pagerState.animateScrollToPage(it) 
    }
}

HorizontalPager(state = pagerState)

[Dominaezzz]

I personally like LaunchedEffect(Unit) tbh.

[Dominaezzz]

I think that's the effect you want anyway.

[Ian Lake]

Seems like you'd want LaunchedEffect(pagerChangeFlow) ?

[cb]

Yep, what Ian said 👆, or LaunchedEffect(pagerState) is what I tend to use

[cb]

https://google.github.io/accompanist/pager/#reacting-to-page-changes

[Dominaezzz]

Or snapshotFlow { pagerChangeFlow }.flattenConcat() if you want to be super extra about it.

[Michal Klimczak]

https://google.github.io/accompanist/pager/#reacting-to-page-changes

Buty my code is not indented to find out when page change happens, Instead I want to change page whenever my sharedFlow fires appropriate event.

[cb]

Ah, well it’s a similar pattern. Use the subject as the key for the launch.

[cb]

There’s no need to snapshotFlow the pagerChangeFlow, it’s not a stateful property. In fact, it uses snapshotFlow underneath

[Dominaezzz]

If it's not stateful then why use it as an effect key?

[Michal Klimczak]

Do I understand correctly, that the job that contains pageChangeFlow.collect will then be tied to the pagerState value changes. so whenever the page changes (e.g. user flings manually), it will cancel and relaunch the coroutine? Isn't that wasteful?

[Ian Lake]

What LaunchedEffect(pagerChangeFlow) means is that if the pagerChangeFlow object is replaced with a new object, the previous code block is cancelled and a new code block associated with the new flow is started. Using true or null would mean that they'd both run

[Ian Lake]

That's why LaunchedEffect should always take a key - in just about every case, your LaunchEffect is operating on something - that something (or somethings) should be the key

[Michal Klimczak]

Okay, I was referring to LaunchedEffect(*pagerState*) which Chris suggested. which is external to the LaunchedEffect. LaunchedEffect(*pagerChangeFlow*) is clearer,
But just to be sure I understand - in this case, since pagerChangeFlow is an immutable field of viewmodel, it will never be replaced, so technically the difference between that and true/null/Unit is purely semantic?

[Ian Lake]

I think Chris was specifically talking about Accompanist's Pager library, of which there's also a variable called pagerState, of which a pageChanges flow is part of. I suspect this is in fact, your own custom thing, rather than that?

[cb]

Ahhh yes 😂

[Michal Klimczak]

it's the Accompanist HozirontalPager 🙂.

oh wait, I get what you meant. Yes, pageChangeFlow is my own 😄

[Ian Lake]

For truly immutable, effectively singletons, you are correct that using Unit as your key does not make any practical difference, but I'd certainly strongly suggest getting into the habit. You never know when the immutable Flow of today instead needs to be wrapped in a remember ala https://medium.com/androiddevelopers/a-safer-way-to-collect-flows-from-android-uis-23080b1f8bda#27a9

[Ian Lake]

Sometimes best not to assume anything 🙂

[Michal Klimczak]

Thank you guys, you are awesome!