UINavigationController with Store

[darrarski]

Hello everyone!

Recently I discovered the navigation branch which contains interesting additions to ComposableArchitecture aimed to easily drive a SwiftUI.NavigationStack with Store.

@NavigationState and NavigationAction

The most interesting part for me, is the @NavigationState property wrapper, which can be used like this:

struct Destination: ReducerProtocol {
  // ...
}

struct DestinationView: View {
  let store: StoreOf<Destination>
  // ...
}

struct Example: ReducerProtocol {
  struct State: Equatable {
    @NavigationStateOf<Destination> var navigation
    // ...
  }

  enum Action: Equatable {
    case navigation(NavigationActionOf<Destination>)
    // ...
  }
  
  var body: some ReducerProtocol<State, Action> {
    Reduce { state, action in
      // ...
    }
    .navigationDestination(
      \.$navigation,
       action: /Action.navigation,
       destinations: Destination.init
    )
  }
}

struct ExampleView: View {
  let store: StoreOf<Example>

  var body: some View {
    NavigationStackStore(store.scope(
      state: \.$navigation, 
      action: Example.Action.navigation
    )) {
      // ...
      .navigationDestination(store: store.scope(
        state: \.$navigation, 
        action: Example.Action.navigation
      )) { store in
        DestinationView(store: store)
      }
    }
  }
}

@NavigationStateOf<Destination> provides the collection of Destination.State that drives the navigation stack. It allows to update the stack easily:

// push new destination on the stack:
state.navigation.append(/* Destination.State */)
// pop last destination from the stack:
state.navigation.removeLast()
// ...

NavigationActionOf<Destination> can be used to update the navigation state:

enum NavigationAction<State: Hashable, Action> {
  case dismiss(id: NavigationState.ID)
  case element(id: NavigationState.ID, Action)
  case setPath(NavigationState<State>)
}

There's a new case study that shows how it can be used in SwiftUI, and it's great. Navigation is simple, decoupled, and ongoing effects are automatically canceled once the destination that produced them is dismissed.

UIKit and UINavigationController

In my daily work, I still use UIKit in some projects. While the concept of a navigation stack is quite new in SwiftUI it existed in UIKit for years now. I did a little experiment and implemented a UINavigationController that drives its view controller stack with a Store. It uses the same ComposableArchitecture's API as mentioned above.

class DestinationViewController: UIViewController, NavigationDestinationViewController {
  let navigationId: AnyHashable
  let store: StoreOf<Destination>

  init(destination: NavigationStateOf<Destination>.Element, store: StoreOf<Destination>) {
    self.navigationId = destination.id
    self.store = store
    // ...
  }

  // ...
}

let store: StoreOf<Example> = // ...

let controller = NavigationControllerWithStore(
  store: store.scope(
    state: \.$navigation,
    action: Example.Action.navigation
  ),
  destinationViewController: DestinationViewController.init(destination:store:)
)

It's open source and you can find it here:

👉 https://github.com/darrarski/store-navigation-controller

I've included an example iOS application built with UIKit to show how it can be used. It looks like this:

SwiftUI vs UIKit

The SwiftUI.NavigationStack and UIKit.UINavigationController can be driven by the same ComposableArchitecture component. There's however a difference in how they work.

The NavigationStack has an additional Root view displayed when there're no destinations (the path is empty), while the UINavigationController presents the first view controller on the stack as root. My initial approach to this issue is to ignore it 😄

At the moment I'm not sure if, and how, we can implement consistent behavior in UIKit and SwiftUI. One way would be to use the first destination on the stack as a Root view in SwiftUI, and exclude it from the path. The other approach would be to allow providing a rootViewController of the UINavigationController separately, and then the viewControllers array will be the root + destination view controllers.

We can also do nothing and it should work well in both UIKit and SwiftUI, assuming we accept that the actual UI behavior depends on the framework.

---

I appreciate any feedback and support with development of the UINavigationController driven by Store. Let me know what you think, and what's your experience with using ComposableArchitectre and UIKit, regarding the navigation.

My question to @stephencelis and @mbrandonw is - do you plan to support UIKit with the new navigation APIs introduced on the navigation branch? Or is it just focused on the SwfitUI? I think it could be used in UIKit out of the box, as my little PoC project proofs, but I might be wrong.

[mbrandonw]

Hey @darrarski, this looks really awesome, thanks for sharing! I've only briefly perused the code, but it's very exciting to see that you were able to leverage all of the core navigation tools (NavigationState, NavigationAction, Reducer.navigationDestination, etc), and then just sprinkle on a bit of UIKit.

Our plan is to support UIKit as much as we can, though our initial focus has been on SwiftUI since we feel that helps us best understand the problem space, and then we apply those ideas to UIKit. But your experiment shows that even if we don't get around to fully supporting UIKit, it can always be provided by the community.

[darrarski]

I’m thinking about resurrecting this topic. My PoC project needs alignment with the latest Composable Architecture API, especially the new StackState type that will drive navigation in UINavigationController.

@mbrandonw did you have a chance to explore navigation in UIKit? Perhaps, there are some community projects/experiments you are aware of? I wasn't able to find anything on that matter yet. I'm happy to do the work, but I don't want to reinvent the wheel :-)

[Alex293]

Hey @darrarski I never had the chance to make further progress on this but some time ago I made a POC mixing a backport of iOS 16 apis using UINavigationController with TCA here. Please note that this was before observation but it was working nicely at the time. The next step was to unify the types representing the stack.

[mbrandonw]

@mbrandonw did you have a chance to explore navigation in UIKit? Perhaps, there are some community projects/experiments you are aware of?

We have experimented a bit with UIKit navigation in TCA here. It's very promising, but we just need more time to polish it. If you want to copy-paste it into your project and give a test then please let us know how it goes.

[darrarski]

@mbrandonw Thanks! I'll definitely check it out, as it may resolve the issues I'm experiencing with v1.9.3 (mentioned in another comment)

[Alex293]

Hey @darrarski @mbrandonw
I gave another shot at my POC using the latest TCA and the NavigationStack backport I already used last time. You can find it here. I was able to backport TCA's recent Onboarding case study to iOS 14 by adding a single file inside the study i.e. anyone can do it without TCA changes. Though I needed to use both @testable and @_spi(Internals). It would be lovely to be able to drop the @testable. @mbrandonw wdyt about moving those behind spi too ?

I'll look into the branch mentioned above too but I went for the path of least resistance for now :)

[darrarski]

I've tried to migrate my PoC to the latest Composable Architecture (v1.9.3) but I'm experiencing two issues, that were absent when using the navigation-beta branch. You can find the updated PoC on a separate branch.

1. To create view controllers for the UINavigationController, we need to scope the store. Previously I used this function:

   let store: Store<StackState<Path.State>, StackActionOf<Path>> = ...
   store.scope(
     state: { $0[id: id] ?? state },
     action: { .element(id: id, action: $0) }
   )

   The scope function that takes closures is now deprecated in favor of a function that takes KeyPath and CaseKeyPath. I'm trying to follow the migration guide, however, somehow I can't figure it out how to update my code.

   The scope with closures still works fine, so it's not a big issue. I just don't know if migrating is possible in my use case.

   Here is the code that uses deprecated scope function.

2. To handle UINavigationController stack changes, like when the user pops a screen, we need to send some action to our store, that updates StackState so it matches the change.

   Previously what I did was to rebuild the path based on what's actually presented, and then send NavigationAction<State, Action>.setPath(NavigationState<State>) to the store. It was working fine.

   The NavigationAction is no longer available, as it was replaced by StackAction<State, Action>. Unfortunately, the latter does not have .setPath case that would allow updating the whole path with a single action.

   What I already tried was to send .popFrom(id:) action to pop all elements, and then .push(id:state:) to push multiple elements one after another. This however does not play nicely with UINavigationController and causes glitches. I think we need a way to send a single action to the store, that will update the whole stack atomically.

   Here is the old code that was working fine with Composable Architecture navigation-beta branch.

   Here is the new code that tries to update StackState by calling multiple actions one after another, which unfortunately does not work correctly when bind to UINavigationController.

I'm a bit stuck with the above issues. I can't make it work with Composable Architecture v1.9.3. @mbrandonw @Alex293 I would appreciate your support!

[Alex293]

I (sadly) don't work with TCA these days so I won't be of great help but I pretty sure always replacing the whole stack is not a great idea regarding effect cancellation. I didn't dive deep into the POC and I too had UINavVC glitches but was pretty confident that once TCA's and the lib's StackState version merged one could backport TCA navigation.