Hello everyone! Seeking for some validation / feed...
# compose
c
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?
r
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
c
Definitely one of my main concerns as well
Thanks Ryan!
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 : )