Is there anything wrong in having one big state object for the whole application? I am already doing that and everything works great. I just wonder if there are any performance problems in case the app grows too big. I am defining the state of each screen as a separate data class object, which is instantiated as a property of the big state object.

Using one giant state object is pretty similar to using only static fields or having one giant global. It seems convenient until you want to start reusing/sharing pieces of logic and then the whole monolith ends up becoming unmaintainable and needs to be thrown away and rewritten. For a tiny write-once app, it's probably fine (I use statics/globals when writing scripts) but for anything I want to maintain, I also want some degree of modularity.

I am defining the state for each screen as an AppState property, for example:

data class AppState (
    val homeScreen = HomeScreen(),
    val loginScreen = LoginScreen(),
    val settingsScreen = SettingsScreen(),
    val profileScreen = ProfileScreen(),
    val resultsScreen = ResultsScreen(),
)

Each of these are also data classes, which hold the relevant state fields for that screen. So, it’s still modular. My concern is about performance.

I typically have AppState for everything that the user uses across screens, and then ScreenXState for everything for each screen. Working on a fairly decent sized application and it works pretty well. Not sure if that's the type of modularity you were talking about @jim

Performance-wise, I believe Compose is able to detect non-changes for function parameters and avoid recomposing those functions. Recomposition is done at the function-level, not at the

State<T>

level, so if you pass

HomeScreen

or

LoginScreen

as parameters to the each screen instead of

AppState

, I think it shouldn’t impact performance too much. In general, passing the minimal amount of state necessary to each function is best for modularity and reusability as well

@Casey Brooks yes, it makes sense

One object of the style @Daniele B mentioned in the followup example makes sense and seems very reasonable/common, so long as that object is not intended to be passed around the entire app. You don't want to be tempted to, for example, have SettingsScreen() try to read something from

homeScreen

. The

homeScreen

data should be split off and passed to the home widget, rather than passing the whole AppState object.