Hi, I found

Kotlin Redux

a few days back and now Im starting to learn and study it. I understand the concepts very well but I just can't get how to model the

AppState

right. How exactly do you model the

AppState

? Examples I've seen so far only show a small application where the

AppState

is very simple. But how do you model an

AppState

in a Large Application with multiple screens? Do I make smaller "`AppState`" inside the "root"

AppState

like:

data class AppState(
    val loginAppState: LoginAppState,
    val signUpAppState: SignUpAppState
    val someOtherScreenAppState: OtherScreenAppState
    ....
)

data class LoginAppState(
    val usernamer: String,
    val password: String
    ....
)

It seems that 

Redux

 makes sense when screens share state between screens such as the Todo Application Example or its very simple when dealing with single screen application such as the Counter Application but how do you model the 

AppState

 when working with screens doesn't really have connected state such as an application with a 

LoginScreen

 and 

SignUpScreen

. Those two screens doesn't share any state. How to deal with these kinds of scenarios? I'd really appreciate any help. Thank you very much in advance

you should split your state instead of creating multiple stores, it doesn’t matter if screens share state or not

Yes with substates as properties of the app state. Furthermore, your AppReducer would also delegate the state and the action to the responsible reducers.

can you guys link me to some examples? I also imagine that by putting everything in the

AppState

I will also have to manage when those `State`s get cleaned up. So in a

SignUpScreen

where you have User details, once the User is logged-in or have moved out of the SignUpScreen I would need to have an

Action

which would be interpreted by a reducer to clear the state. Is that correct?

Yes. Actually redux architectures have a pretty cumbersome boilerplate but the benefit is that everything is far easier to interact with. I don’t have an example currently to link but I have used it on a previous company.

You shouldn’t rely on your state for the app navigation or include it in the state, I don’t feel the need of “resetting” the “SignupScreenState” when the user logs in, what for? That screen is removed from the UI by the navigation logic, so what’s the need of resetting its state? It’s not doing anything anyway. You just need to reset the state when you want to open that section again

But imagine a state which contains a list of data. If that data is big, keeping it in there without the intention of ever using it again is wasteful specially for devices who have limited resources.

yes, in that case you should make an action that resets it, but I still feel like it’s more an exception than a rule

ok one last question i guess.. how do i manage the smaller States? The way I learned how to create the AppState is to do something like:

data class AppState(
    val someState: SomeState = reducerSomeState(action),
        val someState: SomeState = reducerAnotherState(action)
     ....
)

// I cant imagine how to do it for the state inside the substate
data class SomeState(
    val somthing: String = reducerSomething(action)
    ....

i dont get it, you want to create a substate of a substate?

Maybe I should look into your example first and ask again. 🙂 Your work might answer my questions. This is a very big help! Thank you very much. I really appreciate it! ❤️

don’t worry, feel free to ask again 🙂 One day I will add more sections, I still need to finish iOS and start React

Thank you so much 😄

HomeState only represents the HomeScreen, so it won’t get bigger than the screen itself. Every part of the app should have its own state with all the information it needs. I never needed a state with more than a couple of properties, do you feel like you could have all that data needed in a single screen?

is it correct to do something like:

fun homeReducer(state: HomeState, action: Any): HomeState {
    return HomeState(
        latest = reduceHomeLatest(action),
        something = reduceSomething(action),
        ....
    )
}

no, every part of the state should have only one reducer. Depending on the library it could even don’t compile, for example with redux.js you need to have a 1:1 state-reducer

I’ve always used a single, global store. Nothing is stopping you from using multiple stores. Mutiple stores are more of a flux arch (from web). Redux-kotlin is not really opinionated, , so what ever works for you and your team. I say a store has the benefit of easily sharing state between views/screens/etc. True, it could present memory pressure in some use cases. Really depends on the app and what is in the store. Larger/memory intesive stores may need to prune state if leaving an area of the app, or if device signals low memory (onTrimMemory() on Android for example)