NavigationStackStore backport for iOS 15

[mtzaquia]

Hey peeps!

I’m trying to incorporate the new StackState/StackAction tools in my app, which should support iOS 15.

I have successfully used NavigationLinkStore + UINavigationController pushing UIHostingController instances, but I'm looking for a way to ease migration, whenever we need to drop iOS 15 support.

In a non-TCA context, I have this "pure" SwiftUI.Representable. It wraps a UINavigationController and exposes a path Binding, so that the it can be controlled with state, just like NavigationStack does. Code here.

What I am trying to achieve now, in a TCA world, is to create this wrapper for graceful migration. The idea is to use the same initialiser as NavigationStackStore, but internally decide whether to use NavigationStackStore or "NavigationControllerRepresentableStore" (name TBD).

For that, I am trying to replicate the NavigationStackStore.init, and decide which View to render in the body - but I quickly stumbled upon some private APIs.

I realise some of those are “nice-to-haves” (such as EnvironmentValues.navigationDestinationType, which is used to provide helpful warning messages rather than deriving actual functionality). However, being unable to incorporate some of the others (such as $0.path, .invalidate(…), and the Component type) is a bit of a deal-breaker.

Any ideas on how to get this off the ground? Should this be perhaps made available behind a @_spi(NavigationStackStore)? Or am I missing a different approach that would allow me to achieve this without mimicking the initialiser?

Thanks!

[acosmicflamingo]

The impression that I have (probably a bad one from my inexperience but the one I got after trying to create the UIKit-support tools myself) is that this conversation is pretty much dead until TCA's SwitchStore and/or CaseLet also has UIKit support. This is important because the StackStore needs to be split to its potential navigation paths that can then be passed to its child view controllers and you can't do something clean like that with Store's ifLet/else UIKit functions.

Disclaimer: my codebase is 100% UIKit so I never use UIHostingController or any of that stuff

[Alex293]

I don't think there is a need for UIKit version of SwitchStore or CaseLet, the approach I found people use is to register a builder per destination in the environment and when the destination is appended append the view built by the builder.

[acosmicflamingo]

Register a builder? Might reveal my absolute ignorance but that sounds like Swift-UI speak, and there's not a bit of Swift-UI code in my codebase ;)

[Alex293]

Isn’t this discussion about backporting NavigationStackStore to iOS 15 ?

[acosmicflamingo]

Hm, the combination of seeing "NavigationLinkStore + UINavigationController" in the description above and Brandon saying in the Slack channel "We haven't personally put any time into seeing how StackState/StackAction can be used in UIKit" led me to believe that this discussion is not so much about getting NavigationStackStore to work as much as it is trying to get the navigation tools to work on UIKit by any means necessary, even if it means using code and tools from the Swift-UI framework.

[Alex293]

I guess I was too focused on the discussion title. Anyway better tools for uikit would be handy too !

[agarrharr]

What does your NavigationControllerRepresentableStore look like?

[mtzaquia]

I have linked my vanilla NavigationControllerRepresentable.swift on the post above, but I believe a rough sample of how the file would look like would be something like that:

struct NavigationControllerRepresentableStore<State, Action, Root: View, Destination: View>: View {
    // mimicking NavigationStackStore
    private let root: Root
    private let destination: (Component<State>) -> Destination // had to copy the definition of `Component` over, it's private
    @StateObject private var viewStore: ViewStore<StackState<State>, StackAction<State, Action>>

    var body: some View {
        // mimicking how NavigationStackStore initialises NavigationStack, but still missing some private API replacements.
        NavigationControllerRepresentable(
            navigationPath: self.viewStore.binding(
                get: { $0.path }, // private, cannot use
                send: { newPath in
                  if newPath.count > self.viewStore.path.count, let component = newPath.last {
                    return .push(id: component.id, state: component.element)
                  } else {
                    return .popFrom(id: self.viewStore.path[newPath.count].id)
                  }
                }
              ),
            rootView: { root },
            navigationDestination: { component in
                self.destination(component) // dropped environment stuff as it's not adding functionality, just asserts
                    .id(component.id)
            }
        )
    }

    // mimicking the NavigationStackStore init as much as possible, but still missing some private API replacements.
    public init(
      _ store: Store<StackState<State>, StackAction<State, Action>>,
      @ViewBuilder root: () -> Root,
      @ViewBuilder destination: @escaping (Store<State, Action>) -> Destination
    ) {
      self.root = root()
      self.destination = { component in
        var state = component.element
        return destination(
          store
            .invalidate { !$0.ids.contains(component.id) } // private, cannot use
            .scope(
              state: {
                state = $0[id: component.id] ?? state
                return state
              },
              action: { .element(id: component.id, action: $0) }
            )
        )
      }
      self._viewStore = StateObject(
        wrappedValue: ViewStore(
          store,
          removeDuplicates: { // copied the implementation of `areOrderedSetsDuplicates` as it is private
              let lhs = $0.ids
              let rhs = $1.ids
              return withUnsafePointer(to: lhs) { lhsPointer in
                withUnsafePointer(to: rhs) { rhsPointer in
                  memcmp(lhsPointer, rhsPointer, MemoryLayout<OrderedSet<StackElementID>>.size) == 0 || lhs == rhs
                }
              }
          }
        )
      )
    }
}

[Alex293]

I had success backporting the stack apis many months ago using navigation-stack-backport, have a look here. The POC was working though there were still some warning from UIKit about some apis that were used in wrong order or thing like that and the initial animation was not perfect IIRC. I had not time to spend on this recently but I hope to in the coming weeks or months. Also if this goes nowhere there is NavigationBackport or FlowStacks which could be used as an alternative. The same guy also made TCACoordinators which is dedicated to TCA but with another approach to navigation.

[Alex293]

From what I remember, navigation-stack-backport was promising as it was relying on UINavigationController which would mean that it would work identically on any iOS version. The other back port I linked is based on SwiftUI and use a recursive approach which I successfully used long ago in native SwiftUI but this is riskier as SwiftUI apis behaviour has changed a lot since v1 and would require a lot of testing on different devices and sims.

[Alex293]

Updated the fork to 1.x and rewrote the poke here : https://github.com/Alex293/swift-composable-architecture/tree/navigation-backport. NavigationStackStore and navigationDestination() are available on iOS 14+. I added an example which outside of case studies as I couldn't easily lower case studies iOS requirements. The demo does deeplink into 3 levels which is not working with official apis but there is a small glitch and a warning in the console from UIKit. I'll try to fix those when I can.

[agarrharr]

@Alex293 This is fantastic! I tried it out on a sample project and it works great. Have you made a PR to see if they would like to add this functionality? I have to support iOS 15 and would love to be able to use this.

[Alex293]

I discussed this recently a bit in the slack. This was more of a proof of concept, there are still some quirks to be sorted out and the code is poorly written. I thought about making this an add-on lib but TCA should add more SPI for this. I don't think this si something @mbrandonw and @stephencelis would want to merge, back porting SwiftUI is not really the library role. My ultimate goal was to replace the stack code in the lib by those provided by TCA.
Anyway if you want to clean up a bit what I did and/or list what api are not available to make this a lib outside of TCA you are welcome. I don't have time to work on this right now but I can't review, help you.

[agarrharr]

Yes, I tried copy/pasting your code into my project to see if it would work, but realized that even with @_spi imports, I couldn't get it to work. I'll see if I can list out the apis it needs access to.

[dk-jlew]

+1 for this effort. It would be great to have a backwards compatibility story for stack/tree nav.