(Optional but probably no time) Migrate to Navigation3 by MVI state or other sources #79
Description
Our two primary ChildStack navigation components, RootNavComponent and MainNavComponent, do not rely solely on Decompose configuration classes as the single source of truth.
In fact, each navigation class maintains its own source of truth and delegates it to the configuration classes to satisfy Decompose’s navigation requirements. RootNavComponent uses KStore, and MainNavComponent uses an MVIKotlin store. These sources are translated into the corresponding configuration classes, which are then used to build a ChildStack.
This delegation-based approach raises a question: what happens when an Android configuration change occurs (e.g., screen rotation)? Decompose preserves navigation state in the configuration classes, not in our own sources of truth.
For MainNavComponent, the second example on this page of the Decompose docs, where both StateKeeper and InstanceKeeper are used, might address this. We would need to pass the newly created/retrieved state from StateKeeper into the MVIKotlin store and let InstanceKeeper retain the entire store.
However, it’s unclear how to handle RootNavComponent; perhaps its current implementation is already optimal.
Regardless, the new Navigation 3 library (currently in alpha) may be a better fit for a navigation model driven by XXX.
If we adopt Navigation 3, we can drop Decompose’s navigation and move the navigation logic from the decompose-logic module to the compose-ui module. We would use an MVIKotlin store to persist the list and apply the same StateKeeper and InstanceKeeper state-preservation approach.