d

    Daniele B

    1 year ago
    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.
    jim

    jim

    1 year ago
    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.
    d

    Daniele B

    1 year ago
    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.
    Colton Idle

    Colton Idle

    1 year ago
    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
    c

    Casey Brooks

    1 year ago
    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
    d

    Daniele B

    1 year ago
    @Casey Brooks yes, it makes sense
    jim

    jim

    1 year ago
    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.