does anyone have a good sample on how to build a d...

# compose

[aipok]

does anyone have a good sample on how to build a dropdown list? I can see Dropdown composable, but how to put everything together inside it is not clean. How to track selected item and modify it on select

[Vinay Gaba]

I have an example of a radio button that’s probably very similar. It has some basic logic for selected radio button in a group. You should be able to apply the same principles from this example

https://github.com/vinaygaba/Learn-Jetpack-Compose-By-Example/blob/master/app/src/main/java/com/example/jetpackcompose/material/MaterialActivity.kt#L240

[aipok]

But what if I need to expose selection result to view model livedata because I’m doing search page with 2 inputs… input field and category dropdown, while either of them changes I want to call the view model function to fetch search results.

[aipok]

currently I’m trying pass livedata for both of the value to my main page composable like it suggested in tutorial and also events that modify the livedata values. But it looks very big already… thats why I start thinking that there might be a better way?

[aipok]

I have to already pass 4 live data and 2 event to that composable

[aipok]

like category list observable(that is provided for items in dropdown), current selected category (that is presented in dropdown value), current entered text (search term input) and search results (to show back the results of the search)

[aipok]

and as suggested in tutorials the modification of the livedata is not good inside composable, I’m passing back event to modify search term and to update current gategory

[Vinay Gaba]

Just my opinion so take it with a grain of salt - I think the problem you are describing would apply to even non-compose UI logic. For this example, let’s generalize compose to be any UI (let’s not worry about the implementation details of how that UI is implemented). How would you deal with this then if we aren’t worried about compose? One way to deal with this would be to pass down a state object to your UI that describes all the various parts of your screen. You could do something similar even with compose where you just pass down this single object to your composable. Honestly, there are multiple other approaches you could take here. For example, you can also also get rid of live data completely and just use compose primitives (like mutable state).

[aipok]

hmm… thats actually a good idea, I can handle internal state and only expose back the callback that will actually fetch data or return result.

[Vinay Gaba]

oh yes, passing callbacks would be a good idea as well, as that makes your composable even more generic and reusable.

[aipok]

but it would be nice to open more doors and see if there are any other options or suggestions how to do it. As you wrote on how would I deal with this using no composable. It would be much easier with current UI (data binding) and view model that does all the magic.

[Vinay Gaba]

alternative approach would be that you pass the view model to the composable to trigger events.

[Vinay Gaba]

and yes, I am very curious about how this evolves!

[aipok]

I was thinking about this, but in some of the guides I read, G guys have wrote it is not good idea to pass VM to composable, better to pass individual fields, which makes composable really huge 🤔

[aipok]

anyway, thanks for your input, that triggers some lights for me. I will give a try something with internal states

[Vinay Gaba]

yeah my approach would be to pass down the state object to the composable that describes the entire view.