How to decouple NavigationStack and ChildFeatures with modular architecture?

[wynioux]

Architecture:

App module have a main feature that contains NavigationStack and all child features have own modules. (with Tuist)

Module 1: App that imports NetworkUI, xUI, yUI, zUI.
Module 2: NetworkUI that imports NetworkKit
Module 3: NetworkKit
Module 4: xUI that imports xKit
Module 5: xKit
Module 6: yUI that imports yKit
Module 7: yKit
Module 8: zUI that imports zKit
Module 8: zKit
...

Main feature:

import ComposableArchitecture
import SwiftUI
import NetworkUI
import xUI
import yUI
import zUI

@Reducer
public struct ModuleList {
    @ObservableState
    public struct State: Equatable {
        var path = StackState<Path.State>()
        
        public init(path: StackState<Path.State> = StackState<Path.State>()) {
            self.path = path
        }
    }

    public enum Action {
        case path(StackAction<Path.State, Path.Action>)
    }

    public var body: some Reducer<State, Action> {
        ...
            .forEach(\.path, action: \.path) {
                Path()
            }
    }
    
    public init() {}
    
    @Reducer
    public struct Path {
        @ObservableState
        public enum State: Equatable {
            case network(NetworkPath.State = .list())
            // case x(XPath.State)
            // case y(YPath.State)
            // case z(ZPath.State)
        }
        
        public enum Action {
            case network(NetworkPath.Action)
            // case x(XPath.Action)
            // case y(YPath.Action)
            // case z(ZPath.Action)
        }

        public var body: some Reducer<State, Action> {
            Scope(state: \.network, action: \.network) {
                NetworkPath()
            }
            ...
        }
    }
}

@Reducer
public struct NetworkPath {
    @ObservableState
    public enum State: Equatable {
        case list(NetworkList.State = .init())
        case detail(NetworkDetail.State)
    }
    
    public enum Action {
        case list(NetworkList.Action)
        case detail(NetworkDetail.Action)
    }
    
    public var body: some Reducer<State, Action> {
        Scope(state: \.list, action: \.list) {
            NetworkList()
        }
        Scope(state: \.detail, action: \.detail) {
            NetworkDetail()
        }
    }
}

...

NetworkUI feature:

import ComposableArchitecture
import SwiftUI
import NetworkKit

struct NetworkListView: View {
    @Bindable var store: StoreOf<NetworkList>

    var body: some View {
        List {
            ForEach(store.entities, id: \.id) { entity in
                NavigationLink(state: ModuleList.Path.State.network(.detail(.init(entity: entity)))) {
                    NetworkListCellView(store: Store(initialState: NetworkListCell.State(entity: entity)) {
                        NetworkListCell()
                    })
                }
            }
        }
        .listStyle(.plain)
        .navigationTitle("Network")
    }
}

The problem is in order to use NavigationLink we need ModuleList.Path.State. Which its part of the App, so we need to import App that couses Circular dependency between modules 'App' and 'NetworkUI'.

How can i decouple NavigationStack and child features?

[mbrandonw]

Hi @wynioux, you have two options for decoupling the child features.

First, and the easiest, is to simply not use NavigationLink(state:). As you can see it necessarily means that the child feature must be able to compile Path.State, which means it must compile every child feature's State. Instead you can use a Button that sends an action, and then a parent domain listens for that actions and appends to the path. This is what we do the SyncUps demo app provided in the repo (see here).

It's also worth noting that NavigationLink(state:) only really works with the most basic kinds of navigation. You are not allowed to perform any logic when the link is tapped. All that can happen is that the link is tapped and a drill-down happens immediately. But you aren't able to do validation or effects first, and then perform the navigation. This is another reason why Buttons can be preferred over NavigationLinks, and we filed a Feedback about this, and recommend you do the same.

The second option is to pull Path.State (and all child feature States) into a separate module. Note that I am specifically saying only Path.State (and child stats). It is not necessary to pull the Path reducer or any child reducers into this module. And then any child feature can depend on this module in order to construct navigation links, and it will be able to do so without building all other features and without circular dependency errors.

[wynioux]

Thanks for the explanation, I choose to go with Button method for real decoupling.