CaseReducer and modularized path states

[seanmrich]

I love the simplification of path reducers and associated NavigationStack destinations in v1.8. However, I've had some trouble integrating into an app. It relates to the issue of how a child feature can push a path element onto the stack. The child feature can't see the Path state if it's defined in a separate module without importing the parent which causes a circular reference. From previous discussions, there are two recommendations to handling this:

• Use NavigationLink(state:label:) in the child feature to push a new path element. To avoid circular references between the parent and child features, create a separate module that holds the State types for the path and all associated child features.
• Use Button instead of NavigationLink and send a delegate action requesting a new element for the path. The parent feature monitors for those delegate actions and manages the StackState itself.

I've been using the first method, and it isn't clear how to use the new 1.8 features to clean up the path reducer. Here's the shape of the existing type where RootPathState is declared in a separate module StatesModule:

@Reducer
struct Path {
  typealias State = StatesModule.RootPathState
  enum Action {
    case child(Child.Action)
  }
  var body: some ReducerOf<Self> {
    Scope(state: \.child, action: \.child) {
      Child()
    }
  }
}

If I want to pare this down using the new 1.8 hotness:

@Reducer
enum Path {
  typealias State = StatesModule.RootPathState
  case child(Child)
}

Much better 👍 and this compiles, but using it in the parent reducer raises an error because Path.State didn't get conformance to CaseReducerState:

var body: some ReducerOf<Self> {
  Reduce { ... }
    .forEach(\.path, action: \.path)
     ^ Error: Instance method `forEach(_:action:)` requires that `Parent.Path.State` conform to `CaseReducerState`
}

It makes sense that the @Reducer macro doesn't fiddle with an explicitly declared State type, but otherwise using the NavigationLink method described above doesn't seem possible. When using this sugared version of path declaration, is it necessary to use Buttons for pushing navigation elements?

[stephencelis]

@seanmrich Can you extend the State to conform in the module containing Path?

@Reducer
enum Path {
  typealias State = StatesModule.RootPathState
  case child(Child)
}

extension Path.State: CaseReducerState {
  typealias StateReducer = Path
}

(You may need to move the extension to a separate file due to some macro bugs in Swift 5.9/10.)

This should unlock the shorthand forEach syntax as well as store.case.

Alternately, you can do the longhand forEach but refer to Path.body as the child reducer:

.forEach(\.path, action: \.path) {
  Path.body
}

[HerashchenkoElena]

@stephencelis I have tried to implement your approach and it’s working well with IOS 17, but unfortunately for IOS 16 there is no navigation to the child and I have an error

A NavigationLink is presenting a value of type “Component” but there is no matching navigationDestination declaration visible from the location of the link. The link cannot be activated.
Note: Links search for destinations in any surrounding NavigationStack, then within the same column of a NavigationSplitView.

Any suggestions how to solve it?

[stephencelis]

@HerashchenkoElena You'd need to provide a repro to debug further. It's not immediately clear to me why you would get such a warning in iOS 16 and not 17 with the same code.

[HerashchenkoElena]

@stephencelis Here is an example that represents this problem
TCA.zip

[stephencelis]

@HerashchenkoElena This looks like a behavior change in vanilla SwiftUI when it comes to its navigation tools. The issue appears to be in AppFeature.swift, where two NavigationStacks wrap the underlying feature views, but those feature views also use NavigationStacks. SwiftUI does not support multiple nested NavigationStacks in the same view hierarchy, and the behavior seems undefined across OS releases. To fix I think you can remove the outer NavigationStacks in AppFeature.swift and things should work!

[HerashchenkoElena]

@stephencelis Yes, thank you! It works!