Routing/Navigation in TCA

[ghost]

Good day everyone!

I'm attempting to use the routing ideas currently being discussed in the video series within TCA but I ran into a very unusual situation. In the example project I created, you can either present a series of nested scenes using a sheet presentation style or a stack navigation style.

The navigation works perfectly with sheet presentation but fails with stack navigation. It works fine when scene A pushes scene B but when scene B then pushes scene C, scene C appears for a brief moment then gets dismissed back to scene B, which is then left in an inconsistent state.

The code that calls them is identical and the data passed to them is identical, except for the fact that a sheet takes a closure that produces its destination view while a NavigationLink takes the actual view, ie, the NavigationLink API is "eager". Using a lazy wrapper view to build the view only when it's actually presented does not solve the issue so, in effect, both the sheet and the NavigationLink take the exact same data.

public var body: some SwiftUI.View {
    WithViewStore(store) { viewStore in
        VStack {
            // ...
            if viewStore.presentWithSheets {
                Button(action: { viewStore.send(.presentChild(true)) }) { Text("Present") }
                .sheet(
                    isPresented: boolBinding(viewStore),
                    content: { destView() }
                )
            } else {
                Button(action: { viewStore.send(.presentChild(true)) }) { Text("Push") }
                NavigationLink("",
                    destination: destView(),
                 // destination: Lazy(destView()),
                    isActive: boolBinding(viewStore)
                )
            }
            // ...
        }
        // ...
    }
}

private func boolBinding(_ viewStore: ViewStore<AScene.State, AScene.Action>) -> Binding<Bool> {
    viewStore.binding(
        get: { $0.isRoutingTo(/AScene.State.Route.child) },
        send: AScene.Action.presentChild
    )
}

@ViewBuilder
private func destView() -> some SwiftUI.View {
    IfLetStore(
        store.scope(
            state: { $0.state(for: /AScene.State.Route.child) },
            action: AScene.Action.child
        ),
        then: BScene.View.init(store:)
    )
}

I thought that maybe it's the logic in the reducer that is at fault but, if that was the case, why would the sheet presentation work flawlessly? Besides, the reducer logic is pretty simple and all the debug actions and state changes, in both sheets and nav links, are correct. In fact, the state after A pushes B and B pushes C is exactly what you'd expect but that is not what is rendered.

I then thought that since everything is effectively the same for both sheets and nav links, then the fact that the former work but the latter don't suggests that there's a bug in the implementation of NavigationLink itself, ie, a bug in SwiftUI itself.

So, I built an identical project using vanilla SwiftUI and the navigation links work perfectly fine.

The next alternative is that TCA itself has a bug but, then, its code is agnostic with respect to the rendering framework so if it works with sheets, it should also work with nav links.

The only alternative left is that I don't correctly understand how to model this problem but, then, this is a really simple project: just identical scenes that present one another in sequence, in a nested way (A presents B, then B presents C, then C presents D, then D presents some leaf scene).

I did find a solution, however. When creating the destination view, do not scope the presenting store down to the presented store but, rather, create a brand new store with the presented state. In code, it means to use

BScene.View(store: .init(
    initialState: BScene.State(),
    reducer: BScene.reducer,
    environment: BScene.Environment()
))

rather than

IfLetStore(
    store.scope(
        state: { $0.state(for: /AScene.State.Route.child) },
        action: AScene.Action.child
    ),
    then: BScene.View.init(store:)
)

This solution smells wrong in at least three ways:

• it requires an environment and the presenting view does not have access to the current one
• the presenting reducer does not get a chance to process actions fired by the presented view
• how do any changes in the presented view's state get incorporated back into the presenter's state if the presented state is "detached"?

I'm at a loss in what should be a really simple problem. At work, it's become a blocker, which is why I created a toy project and also why I'm here at the forum asking for help.

Any help is much appreciated!

[ghost]

It looks like there are a few other posts in the forum raising the same, or a related, issue:

• Navigation
• When hiding the navigation bar in the parent and show it in the child, it doesn't work properly when using Store.scope for some reason
• Multiple NavigationLink with composable architecture

The last one may hold the solution to the problem I'm raising here. More specifically, I'm intrigued by @stephencelis's comment in that last thread whereby he says

This means trying not to observe child state in a view that also presents that child via a NavigationLink.

so I'll investigate further and will report back soon.

[ghost]

Following up on the above, I attempted to replace all uses of WithViewStore (which wraps the NavigationLink in all scenes of the toy project) with an @ObservedObject private var viewStore property in the views. I'm not sure if that would prevent the presenting views from observing changes to the presented views but it was worth a try. It did not work, however. The problem remains.

[ghost]

Yet another forum post on issues using NavigationLinks:

Navigation

[ghost]

I did find a solution where the state of the presented view is scoped from the state of the presenting view but it seems to work only if/when the state of the child is scoped at the time the child view is initialised, as follows:

public struct View: SwiftUI.View {

    @SwiftUI.Environment(\.dismiss) private var dismiss

    private let store: Store<State, Action>
    @ObservedObject private var viewStore: ViewStore<State, Action>

    private var destination: IfLetStore<BScene.State, BScene.Action, BScene.View?>
    private var isActive: Binding<Bool>

    public init(store: Store<State, Action>) {
        self.store = store
        let viewStore = ViewStore(store)
        self.viewStore = viewStore
        let childStore = store.scope(
            state: { $0.routeState(for: /State.Route.child) },
            action: Action.child
        )
        self.destination = IfLetStore(childStore, then: BScene.View.init(store:))
        self.isActive = viewStore.binding(
            get: { $0.isRoutingTo(/State.Route.child) },
            send: Action.presentChild
        )
    }

    public var body: some SwiftUI.View {
        VStack {
            // ...

            Button(action: { viewStore.send(.presentChild(true)) }) { Text("Push") }
            NavigationLink("", destination: destination, isActive: isActive)

            // ...
        }
        // ...
    }

}

It's not clear to me that this solution is free from problems but it appears to work.

This solution has been added to the toy project repository as a second package, TCA2.

[surajbarkale]

The WithViewStore block containing one or more NavigationLinks must not include the state of NavigationLink targets. Otherwise, if an effect mutates the state of destination view; then it will cause the WithViewStore block to be refreshed. This probably recreates the NavigationLink and shows navigation animations.

The easiest way of doing this is by scoping the store before passing on to WithViewStore.

[ghost]

Hello @surajbarkale, and thank you for your response. 😄

I think what you're saying is effectively what I did in my most recent post above. I couldn't make it work in any other way. What I'm concerned, though, is whether my approach above might cause unforeseen issues.

[surajbarkale]

In my code I ended up creating a separate ViewState for the parent view that excludes child state. This has been recommended for performance reasons as well (although this does bring in complexity when using BindableState). In my experience this has resulted in bug free navigation.

I found your solution to be too complex for the problem you are trying to solve. I also wouldn't have had the necessary insight before watching the recent PointFree episodes about navigation. Here is my solution for you:

// In utilities
public enum ViewPresentationMode: Equatable {
  case sheet
  case push
}

extension ViewPresentationMode {
  func wrap(for mode: Self, binding: Binding<Bool>) -> Binding<Bool> {
    .init(
      get: { self == mode && binding.wrappedValue },
      set: {
        guard self == mode else { return }
        binding.wrappedValue = $0
      }
    )
  }
}

extension View {
  public func present<Content: View>(as mode: ViewPresentationMode, isPresented: Binding<Bool>, content: @escaping () -> Content) -> some View {
    self
      .sheet(isPresented: mode.wrap(for: .sheet, binding: isPresented)) {
        // Sheets need a separate navigation view which should always be in stack mode
        NavigationView(content: content)
          .navigationViewStyle(.stack)
      }
      .overlay {
        NavigationLink(
          isActive: mode.wrap(for: .push, binding: isPresented),
          destination: content,
          label: EmptyView.init
        )
      }
  }
}

// suggested changes to your view
extension AScene {
  public struct View: SwiftUI.View {
    // snipped code
    public var body: some SwiftUI.View {
      WithViewStore(store) { viewStore in
        VStack {
          // snipped code
          Button(viewStore.presentWithSheets ? "Present" : "Push") {
            viewStore.send(.presentChild(true))
          }
          // snipped code
        }
        .padding()
        .navigationTitle(Text(viewStore.navBarName))
        .present(
          as: viewStore.presentWithSheets ? .sheet : .push,
          isPresented: boolBinding(viewStore),
          content: destView
        )
        .ignoresSafeArea()
      }
    }
  }
}

[ghost]

Hello again @surajbarkale, and thank you again for your response and code.

I found your solution to be too complex for the problem you are trying to solve.

Perhaps that's because I didn't make myself clear enough. My problem is not how to user or display sheets and stacks at the same time. I'm only using sheets in this toy example, and doing so in the way I did, ie, nearly identically to how I did the stack navigation, because I wanted to show that sheets work just fine with the most straight-forward implementation using optional routes but stack navigation does not.

By "work just fine" I mean that A presents B which presents C which presents D which presents some leaf scene Detail works as expected when presenting with sheets, and all dismissals also work as expected. However, an identical implementation (sans argument names) using NavigationLinks does not. After A presents B, when B presents C, the scene returns to B rather than stay at C.

In my code I ended up creating a separate ViewState for the parent view that excludes child state. This has been recommended for performance reasons as well (although this does bring in complexity when using BindableState). In my experience this has resulted in bug free navigation.

I think I'll give that a try. Thanks!

[surajbarkale]

I have been bitten by the exact same bug when navigating from A->B->C the B->C path never stayed stable in my app. This was on iPad so I thought the issue was with the dual pane view that NavigationView defaults to. However, it eventually turned out to be re-creation of NavigationLink because of changes in the child state. In my case the issues were:

1. Putting NavigationLink inside IfLetStore
2. Supplying a const binding to isActive
3. Ignoring state changes in isActive binding of NavigationLink
4. Using the tag & selection based initializer of NavigationLink (no idea why this didn't work properly)
5. Conditionally rendering NavigationLink (similar to how you have put it in the else branch)
6. Not creating NavigationView inside a sheet
7. Putting NavigationView inside WithViewStore (not sure about this one as moving NavigationView to child view did work)

So I can echo your experience that NavigationLinks are not as straightforward to use as sheets :)

[ghost]

I did find a solution that works with NavigationLinks but I had to move the binding to boolean, the destination view, and the NavigationLink itself all out of WithViewStore, which meant dropping the use of WithViewStore altogether.

[AlexisQapa]

I didn’t checked your example but point free released a lib for navigation

[ghost]

Yes, I'm aware of their navigation library. I'm using the general ideas they developed for that library (namely, driving navigation through state, in particular an enumeration of routes) but in the context of the composable architecture, since the navigation library is for vanilla SwiftUI applications.

[maximkrouk]

@stephencelis @mbrandonw
Hi, I'll use this discussion to give some feedback about the nav branch.

Here are some pretty convenient concepts for navigation are implemented here https://github.com/CaptureContext/composable-architecture-extensions/tree/main/Sources/ComposableNavigation (example in repo is outdated + the package has some private dependencies yet (@pointfree have full access, but each library is on a prototyping stage yet, so a bunch of things may change, hopefully I'll be able to open-source everything by the end of the year)).
These concepts are nice to use with both SwiftUI & UIKit, also I'll push Optional-State based modals soon. But keeping a state on dismiss might be helpful for UIKit modals.

• As far as I understand Reducer.navigates keeps track of the previous state and it might be helpful for TabViews and I like it
• I guess it is worth separating navigation and presentation
• I'm not a native speaker, but probably on a logical level Route is more semantic base for navigation naming, Modal is probably not less semantic base than Presentation and it's more tiny.

TCA-Extensions lib navigation API is

// Navigation
Effect(value: .route(to: .derivedModule)) // Naivgate forward (uses protocol-based default implementation of static method and sends `.router(.route(to: .derivedModule))` | or .route(to: .derivedModule(derivedModuleState)) if you use tagged routes
Effect(value: .router(.dismiss)) // Navigate back | or `.route(to: .none)`
Effect(value: .derivedModule(.derivedModuleAction)) // Interact

// Presentation
Effect(value: .derivedModule(.present)) // Present
Effect(value: .derivedModule(.dismiss)) // Dismisss
Effect(value: .derivedModule(.action(.derivedModuleAction))) // Interact (`action` is a bit more tiny and generic than `presented(_)`)

• In SwiftUI there is a bug when showing multiple modals on one view, so maybe presentation wrappers should add a view for presentation to background to keep each presentation modifier separate from each other (another bug and inline example of this behavior can be found here ConfirmationDialog sends an unexpected dismiss when presenting the second one #902 (comment))
• UIKit needs some wrappers for navigation/presentation sync (extension for navigation can be found in tca-extensions package, extension for presentation will be pushed soon)
• Use of protocols for states and actions (like BindableAction) may simplify reducers' declarations

I'll be posting updates here when I push useful additions to the TCA-Extensions repo's ComposableNavigation target

Plus one more ping for PR#847, this is not actually a routing problem, but sync for UICollectionView cells is kinda navigation-related stuff (#847 (comment))

[ghost]

Hello, and thank you for replying to my post!

I appreciate your efforts but I'm trying to keep things as simple as possible for the time being, in an effort to

• find the simplest and most direct use of enumerated routing navigation within TCA
• identify sources of problems in either SwiftUI navigation APIs or TCA or both

Basically, in this toy project, I want to have an enumeration of routes and an optional property of that enumerated type, in each scene, then apply the ideas developed for the SwiftUI Navigation library, but within the architecture of TCA.

To that end, I'd rather not layer additional structure on top of the project. Having said that, I will keep an eye on what you're developing and would be grateful for any updates you post here.

And to summarise what I've found so far, doing what I set out to do works when using sheet navigation but does not work when using stack navigation:

• Using sheets, scene A presents scene B which presents scene C, etc and all of those presentations work as expected and also can be dismissed as expected both by dragging the sheet down and from tapping a "dismiss" button.
• Using NavigationLinks, after scene A presents scene B and scene B presents scene C, scene C appears momentarily then the stack returns to showing scene B, which is left in an inconsistent state.

As I described in previous messages above, I found a solution that works for NavigationLinks, by storing both the destination view and the boolean binding as view properties at the time the child view is initialised. This approach works but I am uncertain whether it causes other issues because, as I understand, the child view is getting a "static" snapshot of the parent's state.

[maximkrouk]

My reply was more like a reply for the nav branch, maybe it's not a completely appropriate discussion for the reply, but the title looks generic, so I decided to use it 🙂

Using NavigationLinks, after scene A presents scene B and scene B presents scene C, scene C appears momentarily then the stack returns to showing scene B, which is left in an inconsistent state.

https://github.com/johnpatrickmorgan/FlowStacks seems to work btw, but anyway there is another bug in SwiftUI if you try to deeplink into some nested route (second navigation link doesn't shows up. I guess I found a workaround too, but I'm uncertain about the solution 🌚
johnpatrickmorgan/FlowStacks#3 (comment)

[ghost]

the title looks generic, so I decided to use it

No worries. It's all good.

Thanks for the links to FlowStacks. I'll take a look. 👍