Does anyone have a Flow<> example with Compose for observing a list?

# compose

[brandonmcansh]

Does anyone have a Flow<> example with Compose for observing a list?

[Zach Klippenstein (he/him) [MOD]]

List or MutableList?

[brandonmcansh]

just an immutable one

[brandonmcansh]

the JetNews sample just has lambda's as return results for it's repository calls and looking at using usecases instead of passing the repository via args

[Zach Klippenstein (he/him) [MOD]]

so you’ve got a Flow<List<T>> and you want to do something like val currentList = listFlow.collectAsState(null)?

[brandonmcansh]

essentially ya

[brandonmcansh]

have it update a LazyColumnItems on change

[brandonmcansh]

is where my head was at at least

[John O'Reilly]

There is a Flow<T>.collectAsState() extension function (wasn't sure if maybe that's what was being referred to by collectAsState reference above?)

[Zach Klippenstein (he/him) [MOD]]

val listFlow: Flow<List<T>> = …
val currentList: List<T>? = listFlow.collectAsState(null)
if (currentList == null) {
  LoadingUI()
} else {
  LazyColumnItems(currentList)
}

[Zach Klippenstein (he/him) [MOD]]

yea, sorry forgot it was an extension. Here’s the kdoc: https://developer.android.com/reference/kotlin/androidx/compose/package-summary#(kotlinx.coroutines.flow.Flow).collectAsState(androidx.compose.kotlinx.coroutines.flow.Flow.collectAsState.R,%20kotlin.coroutines.CoroutineContext)

[brandonmcansh]

oh boss

[brandonmcansh]

thank you

[Zach Klippenstein (he/him) [MOD]]

if you have a StateFlow, you don’t need to provide the initial value yourself

[brandonmcansh]

even better

[brandonmcansh]

thanks @Zach Klippenstein (he/him) [MOD]

[brandonmcansh]

@Composable
internal fun BookmarkList(
        padding: Modifier,
        loadBookmarks: State<List<Bookmark>>
) {
    with(loadBookmarks) {
        ScrollableColumn(modifier = padding) {
            LazyColumnItems(value) { bookmark ->
                BookmarkCard(bookmark = bookmark) { editRequest ->
                    
                }
            }
        }
    }
}

[brandonmcansh]

there we go

[brandonmcansh]

@Composable
private fun AppContent(
    navigationViewModel: NavigationViewModel,
    bookmarkViewModel: BookmarkViewModel
) {
    Surface(color = MaterialTheme.colors.background) {
        when (val screen = navigationViewModel.currentScreen) {
            Screen.Home -> {
                Crossfade(screen) {
                    HomeScreen(
                            navigateTo = navigationViewModel::navigateTo,
                            loadBookmarks = bookmarkViewModel.loadAll()
                    )
                }
            }
        }
    }
}

[brandonmcansh]

State<List<Bookmark>> from DI/passed args

[Zach Klippenstein (he/him) [MOD]]

Passing a state in seems like a smell to me. Just pass the actual value in instead, it’s simpler API, simpler for testing, and simpler to reason about.

[brandonmcansh]

fair reasoning

[Zach Klippenstein (he/him) [MOD]]

Also making this a State i think makes this code harder to read. I’ve never seen any compose code do this, and i don’t see any this references in that snippet so are you even using it?

[Zach Klippenstein (he/him) [MOD]]

(unsolicited code review, sorry 😛)

[brandonmcansh]

the value passed to LazyColumnItems

[brandonmcansh]

no keep it coming 🙂

[Zach Klippenstein (he/him) [MOD]]

Ah, yes. I would definitely miss that in the first 2 or 3 reads of this code, and would definitely recommend just calling referencing the val directly (which is even less boilerplate if you just pass the actual value in)

[brandonmcansh]

yep, that makes complete sense

[brandonmcansh]

looking into that now

[brandonmcansh]

AS is being dumb and is showing errors for kotlin pre-release but is still compiling fine so it's quite fun

[Zach Klippenstein (he/him) [MOD]]

Irrelevant if you change to just pass the value in, but calling a State val loadAnything is confusing to me. The name “load*” reads like a verb, like it’s a function that performs a “load” action, but a state is more of a noun.

[brandonmcansh]

yeah i had that named to match the usecase that I was attempting to pass in

[brandonmcansh]

agreed on the naming

[Zach Klippenstein (he/him) [MOD]]

Ah, i see