Identity-based observe and UIBindingReader

[lucamegh]

When using the observe function, it is easy to inadvertently access observable values you did not intend to observe. This can cause the trailing closure of observe to run more often than expected. The issue becomes particularly noticeable when instantiating view controllers inside the observe closure:

observe { [weak self] in
  guard let self else { return }

  let child: UIViewController
  
  if model.isLoading {
    child = LoadingViewController()
  } else {
    child = ContentViewController()
  }

  addChild(child)
  child.view.frame = view.bounds
  child.view.autoresizingMask = [.flexibleWidth, .flexibleHeight]
  view.addSubview(child.view)
  child.didMove(toParent: self)
}

Accessing child.view forces the view to load immediately, which triggers loadView and viewDidLoad. The same behavior occurs with standard container controllers such as UITabBarController. If you are interested in the details, you can take a look at this article by Boris Bugor.

Because of this, if viewDidLoad is used to start observing state, you may end up observing far more state than intended.

The situation becomes even less predictable when dealing with UIWindow’s rootViewController. Calling window.makeKeyAndVisible() triggers not only viewDidLoad, but also viewIsAppearing, viewWillAppear, and viewDidAppear.

Consider the following example:

// SceneDelegate

observe {
  switch model.root {
  case .loading:
    window.rootViewController = LoadingViewController()
  case .home(let model):
    window.rootViewController = HomeViewController(model: model)
  }
}

With this setup, none of the lifecycle methods of HomeViewController are safe places to start observing state. The observe in SceneDelegate would end up tracking every observable accessed inside any of the lifecycle methods of HomeViewController.

Possible improvement

One possible solution takes inspiration from the present API:

@discardableResult
func present<Item, ID: Hashable>(
  item: UIBinding<Item?>,
  id: KeyPath<Item, ID>,
  onDismiss: (() -> Void)? = nil,
  content: @escaping (Item) -> UIViewController
) -> ObserveToken

This API ensures that the presented controller only changes when the identity of Item changes.

A similar variant of observe could be introduced:

func observe<Item, ID: Hashable>(
  item: UIBinding<Item>,
  id: KeyPath<Item, ID>,
  onChange: (Item) -> Void
) -> ObserveToken

func observe<Item: Identifiable>(
  item: UIBinding<Item>,
  onChange: (Item) -> Void
) -> ObserveToken

This approach makes the observed state explicit and prevents unexpected updates. I implemented a helper like this in my own codebase, and it has proven extremely helpful.

The previous example would then become:

// SceneDelegate

observe(item: model.root) { destination in
  switch destination {
  case .loading:
    window.rootViewController = LoadingViewController()
  case .home(let model):
    window.rootViewController = HomeViewController(model: model)
  }
}

With this design, inner view controllers can freely access observable properties without affecting the outer observation. The onChange closure only runs when the identity of root changes.

Additional idea: UIBindingReader

Another improvement could be the introduction of a read-only version of UIBinding (UIBindingReader, maybe?) that can be derived from a UIBinding. This reader would be used in situations where state should be observed but not mutated. Exactly the behavior needed by observe(item:id:onChange:): what a coincidence!

At the moment, if you want to prevent external mutation of a model's state while still allowing UIBindings to be created, you typically have to rely on not-so-ergonomic code like this:

// Model

private var _root = Destination.loading

var root: Destination {
  get { _root }
  set { reportIssue("Invoked setter on Model.root") }
}

A more natural approach might look like this:

// Model

private(set) var root = Destination.loading

// Controller

@UIBindable var model = Model()
$model.root.reader // or UIBindingReader($model.root)

I know that a simple key path could serve this situation, but the UIBindingReader approach feels more direct. This becomes especially true when Item does not conform to Identifiable:

observe(\.item, on: model, id: \.self) { ... }

vs.

observe(item: $model.item, id: \.self) { ... }

SwiftUI already has this concept, and since UIKitNavigation aims to modernize UIKit in light of SwiftUI, it seems reasonable for it to adopt something similar.

Conclusion

Looking forward to hearing your feedback on these ideas!

[lucamegh]

After learning about #286 I realized one could use @autoclosure () -> Item instead of UIBindingReader which I believe is better.

[lucamegh]

After further tests I see an issue with using @autoclosure. Since the closure must also be also made @escaping, you are forced to capture self: observe(item: self.model.item, id: \.self) { … } if you use it in a view controller where the view model is a stored property, this would create a retain cycle between the ObserveToken and the view controller...