Hi, I found `Kotlin Redux` a few days back and now...

# redux

[Archie]

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

[willyrs]

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

[willyrs]

you can tecnhically make different stores, but I never felt the need of it, in fact I feel like it would be more complicated than beneficial

[willyrs]

every screen is attached to their sub-state anyway

[willyrs]

from redux.js page:

it is possible to create multiple distinct Redux stores in a page, but the intended pattern is to have only a single store. Having a single store enables using the Redux DevTools, makes persisting and rehydrating data simpler, and simplifies the subscription logic.

[George Theocharis]

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

[Archie]

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?

[George Theocharis]

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.

[willyrs]

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

[Archie]

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.

[willyrs]

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

[willyrs]

the only reset system that I have in my app is when the user logs out. The LOGOUT action is handled by every reducer and they reset their own sub-state individually

[willyrs]

I have a multiplatform project in progress, but -in fact- it’s still in progress so I only have one state for now: https://github.com/EmmanueleVilla/apod-kmp

[willyrs]

but adding another state is just a matter of creating state, action, reducer etc and adding it to the AppState:
data class AppState(val homeState: HomeState = HomeState())

[willyrs]

you can find the “root” redux classes here: apod-kmp/shared/src/commonMain/kotlin/com/shadowings/apodkmp/redux/
and the “home section” redux classes here:
apod-kmp/shared/src/commonMain/kotlin/com/shadowings/apodkmp/home/

[Archie]

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)
    ....

[willyrs]

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

[Archie]

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! ❤️

[willyrs]

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

[Archie]

Thank you so much 😄

[Archie]

Hi @willyrs, I looked into your work. I saw that you only have a single reducer for HomeState I was wondering how you'd scale it once HomeState gets bigger.

[willyrs]

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?

[Archie]

is it correct to do something like:

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

[willyrs]

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

[patjackson52]

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)