square
decide whether to short-circuit identity traversals in Flow
Currently every dispatcher we have short-circuits if asked to perform a traversal that results in no change to the history (really, the top of the history, but that's too limited). KeyDispatcher (about to land) implements this check, for instance.
Do we want to move this short-circuit into Flow itself?
And perhaps this is conflating two issues, but if we want to have some first-class redirect/transform support; is this short-circuit a part of that/those mechanisms.
I would vote against that. I have to comment the following code in order to make my use case work :
// Short circuit if we would just be showing the same view again. /*val currentKey = Flow.getKey<Any>(currentView) if (destKey == currentKey) { callback.onTraversalCompleted() return }*/
I have a Read(novel:String) key, that instanciates :
- a ProgressView while some necessary services are being built
- a ReadView when those services are built and available
When the services are built, I ask for a new traversal to go from the ProgressView to the ReadView (and the short circuit would prevent it).
I don't want to have a key for the progressView because the ProgressView has no meanings for my users (it is transient) whereas the ReadView has meaning
An identity traversal is almost always an accident; clever hacks that exploit the gap notwithstanding.
You don't need to use Flow just to swap views.
As discussed in #173, I don't see how Dispatchers can avoid handling this themselves. We clear the dispatcher onPause, set it again onResume, meaning it gets a (probably redundant) bootstrap dispatch call every time we leave the app and return to it. Flow can't know the state of the new dispatcher, and whether or not it already reflects Flow's state.
I suppose that's a separate discussion than suppressing no-ops, but given the need for dispatchers to be idempotent, is there much value to doing that work?
Some of my screens are translucent, so, even if the top keys are the same I need to check the bottom screens too.
So I think that the short-circuit can't be a Flow responsability.
