so I have this block of code ```lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.START...

# coroutines

[oday]

so I have this block of code

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.uiState.collect { uiState ->
            if (uiState.authenticated) {
                setContent {
                    Home()
                }
            } else {
                setContent {
                    Authentication()
                }
            }
        }
    }
}

and the issue is that it’s collecting the stateFlow immediately before my viewModel gets the chance return the result, so it shows Authentication, then when the value comes back ti shows Home again

I want it to…well observe like LiveData does

[oday]

and i really don’t get what on earth distinctUntilChanged is trying to do with its signature

[oday]

I could solve it by setting authenticated to start off as null, looks like this

if (uiState.authenticated != null) {
    if (uiState.authenticated) {
        setContent {
            Home()
        }
    } else {
        setContent {
            Authentication()
        }
    }
}

but is that really how to do it ?

[oday]

nothing is working as long as authenticated has an initial value

[oday]

i dont know whether this is even the way to do it, im kind of treating it like LiveData but it doesnt want to behave like livedata

[Adam Powell]

I'm not quite sure which behavior of LiveData you're comparing against

[oday]

well it doesnt grab initial value the moment i start observing and acts on it immediately

[oday]

only when .postValue is called on the livedata does the observer trigger

[Adam Powell]

oh the ambiguous initial state

[oday]

yea authenticated will start as false

[oday]

then viewmodel finishes, becomes true

[oday]

it triggeres for both values

[Adam Powell]

fwiw if we were designing it again today we'd probably make it work like StateFlow does instead, that behavior was kind of regrettable

[Adam Powell]

your code will get clearer if you model the rest of your assumptions

[oday]

so there’s something logically im not getting

[Adam Powell]

authenticated can't be a boolean because you're assuming that there's something special about, "not yet authenticated because I'm waiting on some sort of confirmation"

[Adam Powell]

or rather, it can't only be a boolean. There's another piece of state not being modeled here. There's a third, "I'm not sure yet" state

[oday]

Loading

[oday]

success, and failure

[oday]

ok i see

[Adam Powell]

right. working in state is about modeling those assumptions as part of the state itself

[oday]

i see

[oday]

ok thats clearer

[Adam Powell]

remove the elements of, "over time" from the system; the state unambiguously tells you everything you need to know

[oday]

yea, that “while this is fetching that” is a state in itself

[Adam Powell]

yep, exactly. if something is ambiguous, clarify it in the state

[oday]

gotttt it

[oday]

thanks!

[Adam Powell]

this is also why StateFlow and friends all distinctUntilChanged by default and "skip" intermediate values if an observer isn't responding fast enough: it should never matter to an observer so long as the state is being modeled fully. The latest, current state is all you ever need.

[oday]

works 🙂