https://kotlinlang.org logo
Join Slack
Powered by
So in compose there is remember. Which basically ...
# compose
d
So in compose there is remember. Which basically avoids recomposition. So you also generally emit that state to your VM via a callback. There are times where you have to update what is remembered by what is in the viewmodel. From my understanding a couple popular ways to do that is either not have remember but I have an issue with a control does not work well with many recompositions. Another way is remember(KEY). Where key is something that updates remember. Couple questions 1. Do you think if a control does not work well with many recompositions its a bug? Basically its the slider the thumb in Material compose 2. If you recommend using remember(key) to clear it how have you seen this architected. Feels a little hacky
👀 1
z
remember
doesn't avoid recomposition, it allows something to persist between recompositions.
1. Do you think if a control does not work well with many recompositions its a bug? Basically its the slider the thumb in Material compose
Are you saying you're seeing unexpected Material slider behavior?
It's hard to answer your very abstract question. There are plenty of valid use cases for using 
remember
with a key, but it's also possible to misuse it. If you're deriving some value in a composable from your view model and remembering it, does it really need to be remembered if the view model is the source of truth?
d
I am not sure if its considered unexpected if on recomposition the thumb disappears
Like I am moving my finger along and the thumb disappears and also found thumb jumping around. So it sounds like on recomposition that is unexpected?
z
How are you storing and updating the slider value?
d
It is in the VM in uistate which is collectAsStateWithLifecycle
z
So when the slider change callback is invoked, you pass it to the VM, which eventually emits on a flow?
It's possible the update is happening asynchronously, which means the next frame after an input event the old slider value is still used.
☝️ 1
d
Also my use case is. I have a slider. That when it moves it updates the main viewmodel single UI state. There is a checkbox that is outside of the composable that can reset the slider so it updates the VM and thus updates the slider.
So when the slider change callback is invoked, you pass it to the VM, which eventually emits on a flow?
Yes
z
That shape in general is fine, but if it's jumping around it sounds like something might be happening async
Are you using any flow operators?
d
Yeah I am exploring with a greenfield app to see if I can replicate it. So you are saying recomposition should basically not cause that thumb to disappear. I can dig into that
Are you using any flow operators?
No.
z
If you can reproduce in a new project, please share here and I can take a look
d
I had 2 issues that I am digging into 1. I believe changing the theme around the slider causes the thumb to disappear and do some really weird things 2. The thumb jumped around. I think this is due to a mishandling of the slider value I am doing. I can dig into this more I am digging into these and will post with a project or what I find(if its not an issue)
a
I’ve seen 
Slider
state management have very similar characteristics to text fields that is explored in https://medium.com/androiddevelopers/effective-state-management-for-textfield-in-compose-d6e5b070fbe5 You can get really weird behavior if there’s any asynchronicity between the 
Slider
changing the value, and when the value passed to the 
Slider
updates, and a 
Flow
in a 
ViewModel
can definitely introduce that asynchronicity
d
Thanks. Likely my issue. @Alex Vanyo you seen a more complicated github example where it handles multiple of these controls and passes it up and down multiple layers of composable in a clean way
d
Not sure if this is related, but we logged something similar to this a while back https://issuetracker.google.com/issues/311440479
5 Views
Open in Slack
PreviousNext
Powered by