Hello everyone! Seeking for some validation / feedback on the following idea that becomes possible t...

# compose

[Carlos Muñoz]

Hello everyone! Seeking for some validation / feedback on the following idea that becomes possible thanks to Compose (took some ideas from the official sample):

- Single activity, single viewmodel that just receives actions from screen components: https://github.com/carlosmuvi/notes-compose/blob/master/app/src/main/java/com/carlosmuvi/notes/RootViewModel.kt
- View model just contains Action handlers, passed down to the screen @Composable: https://github.com/carlosmuvi/notes-compose/blob/master/app/src/main/java/com/carlosmuvi/notes/home/HomeActionHandler.kt
- Action + currentState = new State. Handled in reducers: https://github.com/carlosmuvi/notes-compose/blob/master/app/src/main/java/com/carlosmuvi/notes/home/HomeReducer.kt
- A parent state to handle the current screen: https://github.com/carlosmuvi/notes-compose/blob/master/app/src/main/java/com/carlosmuvi/notes/AppState.kt
- One state object per screen, allowing feature modularization: https://github.com/carlosmuvi/notes-compose/blob/master/app/src/main/java/com/carlosmuvi/notes/home/HomeScreen.kt

Some open questions:

- Where to notify when a "screen is created" to trigger initialization?
- Is it the ViewModel really necessary here, since the state objects could keep the state themselves?
- In general, do you see this navigation pattern scalable?

[Ryan Mentley]

I'd be concerned about storing so much state as members of singleton objects - I don't think that's going to scale, for the same reasons that storing static state has issues outside of Compose

[Carlos Muñoz]

Definitely one of my main concerns as well

[Carlos Muñoz]

Thanks Ryan!

[Carlos Muñoz]

Any suggestions to make something along this lines scalable? or having an activity / fragment container per screen will still be the way to go in Compose : )