ConditionalViewController

[lucamegh]

As discussed many times in episodes, navigation can take many shapes and forms. One of my favorite types of navigation takes the form of Dave DeLong's ContainerViewController. The view controller's sole purpose is to display other view controllers, one at a time. Think it as a dumber UITabBarController. By assigning a view controller to ⁠ContainerViewController.content, the container view controller simply displays it. This concept is particularly useful in apps that make extensive use of view controller containment.

The introduction of UIKitNavigation inspired me to think about how this pattern could be enhanced with observation tools. I created a demo to illustrate what an observation-enabled ContainerViewController (provisionally named ConditionalViewController) might look like.

Here's the result:

ConditionalViewController { [model] in
  switch model.authenticationState {
  case .signedIn(let user):
    HomeViewController(user: user)
  case .signedOut:
    SigninViewController()
  }
}

Here's a basic implementation:

class ConditionalViewController: UIViewController {
  private let content: () -> UIViewController
  
  init(content: @escaping () -> UIViewController) {
    self.content = content
    super.init(nibName: nil, bundle: nil)
  }
  
  required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
  }
  
  override func viewDidLoad() {
    super.viewDidLoad()
    observe()
  }
  
  private func observe() {
    var _content: UIViewController?
    
    withObservationTracking { [weak self] in
      guard let self else { 
        return 
      }
      
      let content = content()
      install(content)
      _content = content
    } onChange: { [weak self] in
      Task { @MainActor [weak self] in
        guard let self else { 
          return 
        }
        
        _content?.uninstall()
        _content = self.content()
        observe()
      }
    }
  }
}

This view controller could be even more powerful with custom transition support. It would also address another significant use case: when you initialize a NavigationStackController, the root view controller cannot be changed. By using ConditionalViewController as the root of the navigation stack controller, you can dynamically "change" the root based on the model's state.

I strongly believe that ConditionalViewController would be a valuable addition to the library, as it offers a straightforward and elegant solution to address numerous navigation problems effectively.

Demo

[mbrandonw]

Hi @lucamegh, the library actually already comes with the tools to accomplish this, and a bit more simply.

Both the present(item:) and navigationDestination(item:) tools that come with the library are actually powered by a far more generic destination(item:content:present:dismiss:). It allows you to drive navigation off of a binding and then customize how presentation and dismissal works.

There are just a few changes you must make. First you must mark your LoadingState enum with @CasePathable, which gives you the ability to deriving bindings to each case of the enum:

@CasePathable
enum LoadingState<Success, Failure: Error> {
  …
}

Also, navigation tools tend to work better with optional state because it gives you a natural way to clear state when a feature is dismissed. So, for that reason I think it's best to drop the idle case:

@CasePathable
enum LoadingState<Success, Failure: Error> {
  case inProgress
  case success(Success)
  case failure(Failure)
}

And hold onto optional state in your model:

var state: LoadingState<String, Error>?

Then nil represents being "idle".

Next you can "install" a view controller into the root that represents the "idle" case:

install(
  …
)

And finally you can use destination(item:content:present:dismiss:) to show a controller when the state becomes non-nil and matches a case:

destination(item: $model.state.inProgress) { _ in
  LoadingViewController()
} present: { [weak self] controller, _ in
  self?.install(controller)
} dismiss: { controller, _ in
  controller.uninstall()
}

If you do that for each controller it should work identical to what you have now, but without any additional wrapper controllers. It also unlocks new super powers, such as being able to use traitCollection.dismiss() to have a child feature dismiss itself. Invoking that from any child view/controller goes up the hierarchy to find the binding controlling the presentation, and nils out the state.

And if you aren't happy with this specific API design, then that is ok, because you can build your own special API on top of these tools. We are trying to keep the number of tools offered by the library to a bare minimum while still making it possible for people to build their own specialized controllers on top.

[lucamegh]

Great to hear the library comes with this generic tool.

Is there a reason why you did not suggest me to use this other overload instead?
Speaking of which, another overload that infers the key path of the id automatically for items conforming to Identifiable would be a great addition.

destination(item: $model.state, id: \.self) { [unowned self] $state in
  switch state {
  case .inProgress:
    LoadingViewController()
  case .success(let content):
    ContentViewController(content: content)
  case .failure(let error):
    FailureViewController(error: error)
  }
} present: { [weak self] oldViewController, viewController, _ in
  oldViewController?.uninstall()
  self?.installChild(viewController)
} dismiss: { viewController, _ in
  viewController.uninstall()
}

I like this approach, although I'm not entirely convinced about making the state optional. It seems suitable for navigation and presentation, but less so for my particular use case. I may consider to create the custom container view controller using tools from the library as you suggested.

[mbrandonw]

Hi @lucamegh, no reason, that works great too.