Leverage the trait system to resolve navigation destinations

[lucamegh]

NavigationStack {
  AppView()
    .navigationDestination(for: AppDestination.self) { destination in
      switch destination { ... }
    }
  }
}

SwiftUI NavigationStack is designed such that you are allowed to define the navigation destination provider at the root of the view hierarchy. Have you considered utilizing the trait system to make UIViewController.navigationDestination(for:destination:) behave in a similar manner?

This would be helpful in single entry point systems where you have a root AppViewController defined.
You could potentially provide the destination view controllers for the whole app from a single place.

// AppViewController

override func viewDidLoad() {
  super.viewDidLoad()
  
  navigationDestination(for: AppDestination.self) { destination in
    switch destination { ... }
  }
}

[stephencelis]

@lucamegh navigationDestination(for:) is available on any UIViewController that is in a navigation stack controller, so the above should work. Are you running into issues?

[lucamegh]

I'm suggesting a different behavior of such method. AppViewController is not wrapped in a UINavigationController/StackNavigationController therefore it won't work properly (I see empty UIViewControllers being pushed instead). I'd like the method to be able to propagate the logic of returning a view controller for a destination deep in the UIViewController/UIResponder/UITraitCollection hierarchy. When a new destination is added to its navigation path, StackNavigationController looks for the closure (any Hashable) -> UIViewController in the trait collection and invokes it accordingly.

[mbrandonw]

Hi @lucamegh, can you share a simple project of what you are trying to accomplish? Our stack controller should work almost exactly like SwiftUI’s, so it’s not clear where you are having trouble.

[lucamegh]

I've put together a sample project.

Anyway, I dug deeper in the new UIKit case studies and probably found a better solution to my use case (StaticNavigationStackController).

[mbrandonw]

Hi @lucamegh, FWIW our APIs do work like SwiftUI. In SwiftUI you cannot attach navigationDestination(for:) directly on a NavigationStack/NavigationSplitView or on any parent view. It must go on a view inside a child view of the stack.

And I think there's a good reason for this. Right now navigationDestination(for:) is one-directional, in that you can set it on any child view and it propagates to the root. That makes it very easy to merge the closures into a single dictionary. This is basically how preferences work in SwiftUI too, where you provide a "reduce" function to merge sibling preferences.

But if we allow navigationDestination to flow from parent to child, then it would have to act more like SwiftUI's environment values (using traits), and then we are really opening a can of worms. Setting a destination closure would have no choice but to override other destination closures. So if you set navigationDestination in ControllerA, and then ControllerA presents ControllerB which also does navigationDestination, it will override ControllerA's destinations.

Or at least that's how it seems like it would have to work to me. If you want to sketch a possible solution we would be happy to look at it. But I do think the way we have things set up now keeps things simplest and probably easiest to understand in the long term.

[lucamegh]

I do agree that these changes would complicate stack navigation controller quite a bit and make the framework diverge too much from SwiftUI.

Again, StaticNavigationStackController use case offers a better, less convoluted solution to my problem.

We can close the discussion. Thanks Brandon