https://kotlinlang.org
Join Slack
what could cause some Composable to not be recomposed when some state that’s being observed inside i...
# compose
o
what could cause some Composable to not be recomposed when some state that’s being observed inside it has changed from the viewmodel?
debugger doesnt even hit the beginning of the Composable when the state changes, nothing
but before the whole composable is loaded, it does react to changes in state and that’s how it loads its list
z
I think it’s easier if you just share your relevant code
o
yea I know ..its just how to get it in 1 place where it’s clear, ok wait
NotGranted is triggered, but Disabled never triggers
the line where the state changes for disabled, IS triggered, but the recomposition doesn’t happen
z
Remove the .value call, otherwise your composables are no longer observing its value but instead just gets the value once
o
I thought it was exactly the same
ok well that’s new..
I put the 
.value
in the 
when
then?
i guess yea
z
If you use the by delegate then you’ll automatically get the observed value Syntax is something like val a by vm.flow.collectAsState()
o
what do you prefer all the time?
delegate?
z
Yes. It’s less code
o
and no mention of value anywhere cause the delegate does that
ok cool
z
o
yea gotta reread
but then, for example, if you are doing a when on 
eventsState
and you are in one of the branches, where eventsState 
is
EventsState.Success..and you want to now get a property from eventsState 
events
, it will complain about how it needs to be cast to EventsState.Success first
Smart cast to 'BrowseEventsViewModel.EventsState.Success' is impossible, because 'eventsState' is a property that has open or custom getter
z
Can do when(val a = yourVariable) { }
o
aha…
magician
ok no its simple you just copy it to 
a
so that you can get away with accessing stuff
since 
a
isn’t a thing that has a open or custom getter
yea that still didn’t do it, the not granted one always works and always shows the dialog, disabled doesn’t
weird
haha, after leaving the app it triggers!
actually no, the not granted dialog is shown from the host activity, none of the state changes are triggering the recomposition
after the composable loads that is, it doesnt go back there on any subsequent state changes
z
I would go back and learn compose basics
o
when any state that you’re observing from anywhere changes, recomposition happens in the place you’re observing it
isn’t that it?
I was right, the issue turned out to be that there were 2 instances of the viewmodel in question, so 2 states, etc.. using just 1 resolved it
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by