Question: Deeper than one-level navigation
AndrewLipscomb opened this issue · comments
Hi Alexey,
Having a look at your repo to get ideas on how to tackle my own issues - have you tackled anything to do with navigation (in the NavigationView sense) beyond a one-level-deep-master-detail-set?
I'm still looking for ideas to an SE question I posted - you mentioned in https://nalexn.github.io/swiftui-deep-linking/ that you had this working for programmatically navigat(ing) to a screen at any depth - but I keep on hitting odd animation issues.
Other than that - good to see others are tackling and posting the non-trivial stuff - Apple's documentation and examples are very sorely lacking!
Hey @ALTinners I've looked into the problem you have and can confirm that the issue is with NavigationView implementation, which is currently totally broken.
If you disable animations with UINavigationBar.setAnimationsEnabled(false) before the ContentView is even created and configure your NavState with initial values "b", "ba", "bbb", you'll see this message in the log:
nested push animation can result in a corrupted navigation bar
Attempting to begin a transition on navigation bar (<UINavigationBar: 0x7f82c3d0b330; frame = (0 20; 375 96); opaque = NO; autoresize = W; userInteractionEnabled = NO; layer = <CALayer: 0x600000fb0ce0>>) while a transition is in progress.
These messages originate from UIKit and indicate the SwiftUI is calling pushViewController with animated set to true no matter what.
With my sentence about the navigation to any depth, I assumed the absence of such bugs in SwiftUI components (which I'm sure will be addressed soon), because SwiftUI's API provides full support for bulk navigation changes for any combination of the views.
Good find on that error message there - that's a royal pain that the full API is not exposed.
Honestly - I'm a bit iffy on Apple's whole design paradigm for navigation here - the fact that programmatic navigation is tied to Views is misguided IMO as screen-position-based optimisations (like your List example) suddenly impact things that have nothing to do with layout performance. Its a huge break of encapsulation.
Feeling that way about the whole framework now - just because everything can be a View doesn't mean it should be a View. There's nothing stopping the interface point (ie: a non-view NavigationModel + NavigationRoutes or similar) from being declarative but it should not be tied to display directly.
Anyway - thanks for letting me know and having a go! Love the articles, you know your stuff