We've been following two approaches to this:
In some cases we have a domain/module state that holds all the information needed to derive all of that module's screens' state. So every screen pertaining to the module is at the same level. So sharing state is really easy. A screen's state can easily be derived from its module's state. There's no nesting. We then have a module
Coordinatorhaving access to the module's store thus it can scope down to whatever store is needed. Then via extensions to this coordinator, we can easily create the view with the store it needs to operate. What's bad about it? Every
Viewneeds to also be passed the module's coordinator so it can create the next view in hierarchy. We like this approach, but we would like to get rid of this coordinator.
Then we also follow some of the practices covered in case studies and examples apps where basically screens' states are nested. While this works fine, I think that sharing state in this way is not practical most of the time because let's say you have a screen that is N level deep in the navigation hierarchy. Whatever state this view needs to be shared, you would then have to pass it through N-1 layers before it and those layers may not even use that state at all.
Any advices on how to improve the pain points I mentioned in one and the other methods I described above? Really appreciated.