TabView Navigation with different navigation stacks

[dehlen]

I am currently struggling with the way navigation should work when building a tab based application.
I structured my project pretty much like the isowords codebase (meaning a separate Swift Package per feature f.e).
In my AppFeature package I hold onto the state of the different tabs (lets assume there are only 2 tabs to shorten the code samples):

import ComposableArchitecture
import FeedFeature
import SearchFeature

@Reducer
public struct AppFeature {
    public enum Tab: Hashable, Equatable, Sendable, Identifiable {
        case feed
        case search

        public var id: Self { self }
    }

    @ObservableState
    public struct State {
        public var selectedTab: Tab?
        public var feed: FeedFeature.State
        public var search: SearchFeature.State

        public init(
            selectedTab: Tab = .feed,
            feed: FeedFeature.State,
            search: SearchFeature.State
        ) {
            self.selectedTab = selectedTab
            self.feed = feed
            self.search = search
        }
    }
    
    public enum Action: ViewAction {
        @CasePathable
        public enum View {
            case tabSelected(Tab?)
        }
        
        case view(View)
        case feed(FeedFeature.Action)
        case search(SearchFeature.Action)
    }
    
    public init() {}

    public var body: some ReducerOf<Self> {
        Scope(state: \.feed, action: /Action.feed) {
            FeedFeature()
        }
        
        Scope(state: \.search, action: /Action.search) {
            SearchFeature()
        }
        
        
        Reduce { state, action in
            switch action {
            case let .view(.tabSelected(tab)):
                state.selectedTab = tab
                return .none
            case .feed:
                return .none
            case .search:
                return .none
            }
        }
    }
}

I now want to introduce a NavigationStack per tab. I would assume I need one StackState per tab, in order to be able to distinguish the navigation path for the tabs, sth. like

// Inside of AppFeature.swift

public var feedPath: StackState<Path.State> = .init()
public var searchPath: StackState<Path.State>

enum Action {
    case feedPath(StackAction<Path.State, Path.Action>)
    case searchPath(StackAction<Path.State, Path.Action>)
}

// and then implement the path reducer
@Reducer
    public struct Path {
        @ObservableState
        public enum State {
            case childView(ChildFeature.State)
        }
        
        public enum Action {
            case childView(ChildFeature.Action)
        }
        
        public var body: some ReducerOf<Self> {
            Scope(state: /State.childView, action: /Action.childView) {
                ChildFeature.Action()
            }
        }
    }

I then can use the path to drive the NavigationStack:

TabView(selection: selectionBinding) {
    NavigationStack(path: $store.scope(state: \.searchPath, action: \.searchPath)) {
        SearchView(store: store.scope(state: \.search, action: \.search))
    } destination: { store in
        switch store.state {
        case .childView:
            if let store = store.scope(state: \.childView, action: \.childView) {
                ChildView(store: store)
            }
        }
    }
    .tag(AppFeature.Tab.search)
    .tabItem { Label("Search", systemImage: "magnifyingglass") }

    NavigationStack(path: $store.scope(state: \.feedPath, action: \.feedPath)) {
        FeedView(store: store.scope(state: \.feed, action: \.feed))
    } destination: { store in
        switch store.state {
        case .childView:
            if let store = store.scope(state: \.childView, action: \.childView) {
                ChildView(store: store)
            }
        }
    }
    .tag(AppFeature.Tab.feed)
    .tabItem { Label("Feed", systemImage: "house") }
}

However since the path is now part of the AppFeature reducer. How can I navigate from the FeedView to the ChildView f.e?
Inside my FeedView I would create a NavigationLink but since the Path reducer is part of the AppFeature the FeedView does not know it and I would welcome any hint on best practice here:

// AppFeature not known...
NavigationLink("Navigate to child", state: AppFeature.Path.State.childView(.init())

One way to solve this is to make Path a separate package which would be a dependency of AppFeature and FeedFeature I think. However is this the right approach? I am wondering if this is best practice here.

[mbrandonw]

Hi @dehlen, a few comments:

I would assume I need one StackState per tab, in order to be able to distinguish the navigation path for the tabs, sth. like

This is correct, however I would recommend putting the StackState in each feature, not in the AppFeature. So FeedFeature and SearchFeature would each have their own path stacks. And then the NavigationStack would move into the FeedView and SearchView.

How can I navigate from the FeedView to the ChildView f.e?
Inside my FeedView I would create a NavigationLink but since the Path reducer is part of the AppFeature the FeedView does not know it and I would welcome any hint on best practice here:

This is just a problem with NavigationLink(value:) in general, which is what NavigationLink(state:) uses under the hood. In order to construct that view you must have access to the data, which means access to the full Path.State.

There are a few approaches you can take:

• You can abandon the NavigationLink and just use a Button. Then you can send an action that the parent domain intercepts and appends the state to the path. The downside to this is that you lose the automatic styling of the navigation link, but you can recreate it yourself.
• You can extract Path.State to its own module so that it can be included in other modules. We would recommend only extracting the state enum since that's all features need access to. No need to extract the Path reducer, actions, dependencies, etc. Then any child feature can import that module in order to construct a navigation link.

[dehlen]

Thanks that was exactly the information I needed.

[swasta]

@mbrandonw, In this context, could you please clarify if it is crucial to pass the entire Path.State to NavigationLink? I'd like to continue using NavigationLink due to its semantics and styling, but extracting the entire Path.State seems suboptimal. For instance, in this situation:

@Reducer
struct Path {
    enum State: Equatable {
        case child1(Child1.State)
        case child2(Child2.State)
    }
    ...
}

If I understand correctly, I would also need to extract Child1.State and Child2.State. However, what if to open Child2, Child1 only needs to have some simple piece of data, like an identifier. Can we pass only this identifier to NavigationLink? In vanilla SwiftUI, I believe I could receive this identifier in the .navigationDestination modifier at the root level. Then, I would use it to create a fully fleshed-out Child2.State for the Child2 view, meaning Child1 doesn't have to know anything about the Child2.State type. Is it possible to achieve something similar using the current tools in TCA?

[mbrandonw]

Hi @swasta, it is indeed true that Path.State, and hence all child feature states, would need to be extracted to a module.

However, what if to open Child2, Child1 only needs to have some simple piece of data, like an identifier. Can we pass only this identifier to NavigationLink?

That's not really relevant unfortunately. If you are modeling your navigation stack with TCA, then the only way to push a feature onto the stack is to construct all of Child.State. Hence NavigationLink(value:) must take all of Child.State.

In vanilla SwiftUI, I believe I could receive this identifier in the .navigationDestination modifier at the root level. Then, I would use it to create a fully fleshed-out Child2.State for the Child2 view, meaning Child1 doesn't have to know anything about the Child2.State type. Is it possible to achieve something similar using the current tools in TCA?

While it is true you can do that in vanilla SwiftUI, it is done via the type erased NavigationPath type, and so it comes at the cost of losing all integration with the child features on the stack. For example, there's no way for the parent feature to see what is happening inside the child features so that it can coordinate things.

It's a trade off, and you have to figure out what kind of powers you want.

I'd like to continue using NavigationLink due to its semantics and styling, but extracting the entire Path.State seems suboptimal.

Really the problem is that NavigationLink(value:) is extremely restrictive. Not only is it problematic for the situation you are coming across, but it also limits all types of other navigation patterns. For example, if you wanted to have a navigation link that when tapped first performed an API request, and then based on the response it would perform the navigation. That is completely impossible with NavigationLink(value:).

We filed a feedback asking Apple to make a version of NavigationLink that behaves more like button so that you can execute logic when the link is tapped. We highly recommend you dupe this feedback if you are interested in this.