current hierarchy of my app starts with: - Root - ...

# ballast

[Adrian Witaszak]

current hierarchy of my app starts with:
• Root - I use for initialising Koin and passing RootContent in targets
• Router - does routing ofc and runs scope in VM for monitoring Auth state. if logged out it tells router to go back to login page
• Login page
• rest of the app
Is it ok to keep the observe user state logic in the Router's VM, or should I move it up one level? Currently the root is not a ballast component.

[Casey Brooks]

I’m working on an app now where I’m trying to figure the same thing out, so I don’t really have a strong recommendation at this time.

I’ve listed in this issue some of my thoughts on how to structure the “repository layer”, but I haven’t fully fleshed it out yet. But in general, I do think it’s best to consider the Router as part of the Repository layer rather than part of the UI layer, since the Router drives the UI and can be affected by non-UI things (like auth state).

The structure within the Repository layer should be done as a hierarchy to help keep the data flow simple and understandable. Basically, require that each VM in the Repository layer (the Router, the global auth state, any other repositories, etc) are connected through their constructors. And you may need to introduce a 3rd Repository which collects the state from both the Router and Auth to make decisions on when to redirect to the login page. For example, organized something like this:

[Casey Brooks]

The reasoning for this structure is basically the same as with Compose/React: state flows down, events get sent up. Helps keep things predictable