I've a question regarding paging3: Looking at the official <example>, we're returning new flow of `...

# android

[Kshitij Patil]

I've a question regarding paging3:

Looking at the official example, we're returning new flow of PagingData everytime we search with new query. Although it's true that every flow is going to be different, don't you think that we could have used `SharedFlow`s here somehow?

[Dustin Lam]

You cannot re-collect from the same instance of PagingData. The only way to re-use it is ti call .cachedIn() which basically condenses the internal event stream and multicasts it, so you don't need to reload the cached data, but it still produces a new instance of PagingData each time

[Dustin Lam]

So a SharedFlow which broadcasts would not work

[Dustin Lam]

In the codelab's case, when the query changes the previous load results aren't useful, so we reload from scratch. But in the case for transformations the flow way to do it is essentially

[Dustin Lam]

pager(..).flow
  .cachedIn(scope)
  .combine(queryFlow) { pagungData, query ->
    pagingData.filter { it.contains(query) }
  }

[Dustin Lam]

something along those lines

[Dustin Lam]

codelab is the opposite way though (query maps to pagingData)

[Kshitij Patil]

Okay, now the codelab logic makes sense. I’m now maintaining a MutableStateFlow in viewModels which will be updated on edittext text changes, debounce those updates and make fetch call appropriately. The fetch method will get a new Flow of PagingData and I’m emitting each PagingData to an Immutable state object I maintain in viewmodel (LiveData of State). The LiveData is thus observed in the Fragment and submiited to RecyclerVIew adapter. How does this sound? Also, the fetch call job references are kept and I do cancel the old one same as the codelab (just everything is done in ViewModel)