Tree-based navigation with multiple .navigationDestination views

[jessedoescode]

Hey! How does one have different views presented with .navigationDestination from the enum state for different cases? The tutorial and docs show this enum state for handling navigation driven by optional stores:

@ObservableState
struct State {
  @Presents var detailItem: DetailFeature.State?
  @Presents var editItem: EditFeature.State?
  @Presents var addItem: AddFeature.State?
  // ...
}

However, for the view part of the example, all of the cases are handled my different modifiers:

var body: some View {
  List {
    // ...
  }
  .sheet(
    item: $store.scope(
      state: \.destination?.addItem,
      action: \.destination.addItem
    )
  ) { store in 
    AddFeatureView(store: store)
  }
  .popover(
    item: $store.scope(
      state: \.destination?.editItem,
      action: \.destination.editItem
    )
  ) { store in 
    EditFeatureView(store: store)
  }
  .navigationDestination(
    item: $store.scope(
      state: \.destination?.detailItem,
      action: \.destination.detailItem
    )
  ) { store in 
    DetailFeatureView(store: store)
  }
}

What if all of them would be .navigationDestination? I could handle them with separate .navigationDestination, but the expression becomes too complex for the compiler. I could also use only one .navigationDestination and use a switch-case inside it, but can't get it to work yet. Something like the one used with NavigationStack:

 .navigationDestination(item: $store.scope(
                state: \.presentEvent?.destination,
                action: \.presentEvent.destination
            )) { destination in
                
                switch destination.state {
                case let .inviteGuests(store):
                    InviteGuestsView(store: store)
                    
                case .addHosts(store):
                    AddHostsView(store: store)
                }

But can't get it to work yet. Am I on the right path?

[mbrandonw]

What if all of them would be .navigationDestination? I could handle them with separate .navigationDestination, but the expression becomes too complex for the compiler.

This is the way to do it, but you may need to employ some tricks to work around the compiler issues. You can move your navigation view modifiers to a helper like this:

extension View {
  func navigation(store: Binding<StoreOf<Feature>>) -> some View {
    self
      .navigationDestination(
        item: $store.scope(
          state: \.destination?.addItem,
          action: \.destination.addItem
        )
      ) { store in 
        AddItemView(store: store)
      }
      .navigationDestination(
        item: $store.scope(
          state: \.destination?.editItem,
          action: \.destination.editItem
        )
      ) { store in 
        EditItemView(store: store)
      }
      .navigationDestination(
        item: $store.scope(
          state: \.destination?.detailItem,
          action: \.destination.detailItem
        )
      ) { store in 
        DetailFeatureView(store: store)
      }
  }
}

And then you would use it like so:

.navigation(store: store)

That should get around any compilation problems.

Also once we can release 2.0 we will be able to delete hundreds of deprecated APIs, and that too should help out the compiler.

[jessedoescode]

Thanks for the quick reply! Appreciate the hard work.

I had to split each .navigationDestination to its own modifer for the compiler to be happy, so a bit tricky.

Would the StackState style switch-case actually be cleaner than having to have multiple navigationDestinations?

NavigationStack(path: $store.scope(state: \.path, action: \.path)) {
  // Root view
} destination: { store in
  switch store.case {
  case let .detail(store):
    DetailView(store: store)
  case let .meeting(store):
    MeetingView(store: store)
  case let .record(store):
    RecordView(store: store)
  }
}

[mbrandonw]

I don't know which is cleaner, but I'm not sure that would be any less taxing for the compiler. It is possible to make that syntax work, but you'd probably want to nest all navigationDestination cases in its own @Reducer enum, which means you will just have additional nesting to deal with.