Hey everyone, I wanted to get your thoughts on an ...

# android-architecture

[Daniel Okanin]

Hey everyone, I wanted to get your thoughts on an architectural approach. I'm planning to create a screen in Jetpack Compose that contains multiple Compose components, where each component is responsible for fetching its own data.

This would mean that each component would need its own ViewModel, etc.

What do you think? Pros and cons?

[Alexandru Caraus]

Look at decompose lib, it uses similar aproach

[rkeazor]

I mean it seems simple enough, to just use a ViewModel with MVVM style archtecture. if the components are on the same screen, you probably would just need one viewModel and state hoisting

[juliocbcotta]

I have faced this before, one issue I found is how to control a shared state, for instance, loading or error if you have only one for the whole screen. So each component should be able to control their state.

[Daniel Okanin]

Right , but int case I want each component has its own state

[juliocbcotta]

So it is fine, no?

[Daniel Okanin]

I guess I can synchronize the screen state to each component if I really need that, but the first case is each card is independent

[Daniel Okanin]

@rkeazor but Maybe a card will be hoisted in other screens so I want it will be independent which screen host him

[juliocbcotta]

Create components man, if your card is going to do the same thing in multiple places and can solve it's business by itself, you avoid a bunch of headaches and copying calls to feed data to that component

[juliocbcotta]

So, don't hoist state that you don't need to

[juliocbcotta]

We have a cart icon in my app, it is shown on multiple screens... Imagine if I had to call the usecase to load the cart state in each screen's viewmodel... It would be a nightmare.. the cart icon has its own vm and I just need to call it as a Composable without deps