NavigationStack, Path & SPM

[ghost]

Good morning,

I'm struggling with the following problem and would like to know if this is already identified elsewhere, and if there are solutions for it.

When using NavigationStackStore and Path, like here:
https://github.com/pointfreeco/episode-code-samples/blob/main/0246-tca-tour-pt4/Standups/Standups/StandupsList.swift

in combination with packages, a problem is raised:

• In the example, the superior AppFeature could be separated in an own package, as well as the subordinate ListFeature, which may be a different package with its Detail.
• The AppFeature defines the Path that is used by the subordinate feature.
• When both are in two separate packages, then this causes a cyclic reference.

This means: When the app is separated into packages for each feature, the NavigationStackStore cannot be used currently.

Any ideas hereon?

[mbrandonw]

Hi @innoreq, the complication is with the NavigationLink(state:) API, and same goes for vanilla SwiftUI's NavigationLink(value:) and even all the way back to the now deprecated NavigationLink initializers. All of them necessarily couple the destination of the link to the source of the link.

So, the problem exists in vanilla SwiftUI too. However, vanilla SwiftUI does have a tool to help with coupling, and that's NavigationPath. It is a type-erased collection that allows you to fully decouple destinations from the stack. However, that tool does not play nicely with integrating features together or testing. So, there are always tradeoffs with using that tool.

Now, TCA can't leverage NavigationPath at all because of the aforementioned problems with feature integrating and testing. But you still do have 2 options for using NavigationStackStore and decoupling the features:

• If you want to use NavigationLink(state:), as we do in the Standups demo app, then you just need to pull all of the feature's states into a shared module. And only the State structs need to be pulled out. Not the full reducers, dependencies, views, or any of that. And then any feature that wants to be able to construct NavigationLink(state:) to link to a feature will import that shared module.
• Or you can just ditch the NavigationLink(state:) entirely and have a regular Button, send an action in the child domain, and have the parent domain intercept that action and perform the navigation by appending to the StackState.

Both of those approaches allow you to achieve feature decoupling in the navigation stack.