Hello folks, I'm having some difficulty modelling ...
# orbit-mvi
Hello folks, I'm having some difficulty modelling state with Compose, Paging3 and MVI(Orbit). Since paging3 recommends to expose a flow, that it can later collect lazily in the UI, I've to send a flow in my emitted state. Here goes my queries 1. The approach works, but my tests fails because emitted flow != fake flow. (The cachedIn operator will convert my fake into a viewmodel managed instance). At this point the standard kotlin
function will not work and I have to manually assert on all the properties. Am i overlooking something? 2. Is it okay to emit a flow in a state or is there a better way with paging3 compose?
Nice question, looking forward for the response. At first sight, exposing a Flow in the MyUiState seems like breaking the SSOT 🤔
What happens if you’re scrolling and then a new State is emitted?
🥹 1
At first sight, exposing a Flow in the MyUiState seems like breaking the SSOT...
Yeah 🤔 ...But if you think about it
is still the SSOT here, but since
is doing most of the heavy lifting, we would have to feed it a "refreshable" data and suddenly it becomes a crucial part of the state. Whereas in the old view based world, we had direct access to backing adapters. We could collect /emit/submit new data as and when we require it, without sharing the source 😅
yes but i still believe SSOT will be compromised because now you have a Flow that can change de state independently of MyUiState emissions. The ui state should be the one sending new content, not the flow
👍 1
but i get it, is a very valid question and i’m looking forward to the right answer 😅
so far i’m doing it manually instead of using Paging3 (not mainly because of this reason)
Ah, now I'm really curious to know more about this other reason 😛
editing, removing (and undo by adding back at index) items without invalidating the hole list. Cloud not achieve that with Paging3 😅
Understood 👍
I see nobody really has an answer to this apart from doing it manually...?