I have a question and am interested about opinions...

# compose-android

[Djuro]

I have a question and am interested about opinions you have about state management with compose.
Here is a scenario:
Let's say you have a radio button form on your screen. There is radioButtonNameList: List<String> and selectedRadioButtonIndex: Int of course
How do you manage this state. What is clear to me is that radioButtonNameList will be provided by viewModel or any other state holder. But is selectedRadioButtonIndex: Int managed inside the state holder or inside the composable function.
1. Inside the composable
a. Advantage
i. this is nice as it is self managed
b. Disadvantage
i. Imagine the state holder for whatever reason needing to know about the selected item in the future. It can be of course informed when it is changed but it might also need it for some other operation
2. Inside the state holder
a. Disadvantage
i. property drilling
ii. more logic contained inside the state holder making it more difficult to manager
b. Advantage
i. everything is at one place
Do you have some elegant solutions for such scenarios? I was also checkiout out Molecule but am unsure if this is the right use case for it (thought it might be since I have the whole form which is pretty dynamic, has several radio button menus, filtering, dropdowns etc.)

[Djuro]

Note: what I decided to do in the end is leaving the selectedIndex inside the composable since it is okay for my current usecase, I am still interested about your opinions on this topic though

[Stylianos Gakis]

Since you got the state holder already why not just have the selected index also in there?
What do you mean about property drilling being a negative?
You also say more state makes it harder to manage. Isn’t it even harder to have the state scattered in different places and then having to make sense of all of it in pieces?
Also what if you want to reuse that state holder in a similar situation, will you hold the selected index separately on that composable locally too?

[Djuro]

The complexity and the logic contained within the state holder increases making it harder to follow. In this case, I think that the selected index should go in the composable (radio button form example) and should inform the state holder through a callback. I dont see the state as scattered, rather I think it is where it should be naturally (radio button form makes no sense without having a callback for selected index).
About property drilling: I know that some are claiming that it is not since it s very explicit, but honestly, when working with more complex examples its terrible, not practical at all in my opinion

[Stylianos Gakis]

radio button form makes no sense without having a callback for selected index

You could say the same about TextField and it’s current text onTextChange pattern, but you’d be surprised to see that the new BasicTextField2 is in fact working without a callback which informs you about the state change. It simply changes the state directly which is stored in MutableState inside the state object.
The same can apply in the radio button form.

Still not sure what property drilling has to do with this, if anything having it all in one state object instead of having the state object that you need to pass down and having a callback on state changes would in fact be less things passed down.

[Zach Klippenstein (he/him) [MOD]]

It’s more complexity in the state holder sure, but there it’s a lot easier to test. If you’re gonna end up with a callback just to inform it of change anyway, I’d just hoist the state. It’s more flexible and seems like you’d just end up with two sources of truth eventually anyway.

[Djuro]

Thank you a lot for the insight of BasicTextField2. I kinda changed my opinion a bit now that I went through 3 articles by Alejandra Stamato on medium. I will probably move these into the state holder