Best practice when using @Presents with children of the same type but different identities?

[notcome]

I am working on a simple main-detail app, where you can open a child page representing some document:

@Reducer
struct DocumentFeature {
  @ObservableState
  struct State: Equatable, Identifiable {
      // ...
  }
  // ...
}

@Reducer
struct MainFeature {
  @ObservableState
  struct State: Equatable {
    @Presents
    var document: DocumentFeature.State?
  }
  // ...
}

In this design, the child store is always the same object, thanks to the scoping cache, even if the child feature changes its identity logically. For instance, there could be a “Create a Copy” button, which would do something like:

switch action {
case .document(.presented(.delegate(.createCopy(let oldDoc)))):
  let newDoc = DocumentFeature.State.createCopy(from: oldDoc)
  assert(oldIDoc.id != newDoc.id)
  state.document = newDoc
}

One issue I have observed is that for some conditional view that might crash on the new doc, a re-render is triggered before it is removed:

struct ActiveSelectionView: View {
  var store: StoreOf<DocumentFeature>

  var body: some View {
    // This will crash if there is no selection, and a new copy gets rid of its selection
  }
}

This view would have being fine:

var body: some View {
  if store.hasActiveSelection {
    ActiveSelectionView(store: store)
  }
}

But when the underlying document is swapped, under some complicated case (in my code, I used UIHostingController and put resolved views (from the new custom container API) into states, so it is really hard to analyze), ActiveSelectionView will re-render and just crash.

I have to admit that this is not a good example. For instance, we should scope to an active selection store and pass it to the ActiveSelectionView instead. But I just want to address the other problem. Is there a way to actually get a new child store for the new document?

I know that TCA supports multiple presentation destinations using enum:

// From the doc

@Reducer
struct InventoryFeature {
  // ...


  @Reducer
  enum Destination {
    case addItem(AddFeature)
    case detailItem(DetailFeature)
    case editItem(EditFeature)
  }
}

Is there a similar way for my case here, like

@Reducer
enum Documents {
  case document(UUID, DocumentFeature)
}

, which does not work with the current macro. It just generates an empty reducer.

[notcome]

One fix I can find is to use a StackState, which would handle dismiss for me. However, to use it without a NavigationStack requires some custom container view, which I hope I don't get wrong:

struct StackForEach<State: ObservableState, Action, Content: View>: View {
    var store: Store<StackState<State>, StackAction<State, Action>>
    var content: (Store<State, Action>) -> Content
    private var pathView: StackState<State>.PathView

    init(store: Store<StackState<State>, StackAction<State, Action>>,
         @ViewBuilder content: @escaping (Store<State, Action>) -> Content,
         fileID: StaticString = #fileID,
         filePath: StaticString = #filePath,
         line: UInt = #line,
         column: UInt = #column
    ) {
        self.store = store
        self.content = content
        pathView = store[fileID: #fileID, filePath: #filePath, line: #line, column: #column]
    }

    var body: some View {
        ForEach(pathView, id: \.id) { component in
            content(scope(to: component))
        }
    }

    func scope(to component: StackState<State>.Component) -> Store<State, Action> {
        let scopeID = store.id(state: \.[id: component.id], action: \.[id: component.id])
        var element = component.element

        return store.scope(
            id: scopeID,
            state: ToState {
                element = $0[id: component.id] ?? element
                return element
            },
            action: { .element(id: component.id, action: $0) },
            isInvalid: { !$0.ids.contains(component.id) })
    }
}

IMO this is still not ideal. One reason I opt for @Presents is that it could maintain the invariant that only one page could be opened at any given time. Using a StackState, this variant cannot be enforced at type level.