Handling Scoped Stores with Different Types

[Kilo-Loco]

I'm currently running into an issue with bubbling up view-specific actions to the App/Root Reducer. The problem is that my SwiftUI view takes in a very specific type of store (Store<EventListState, EventListAction> in this example) and allows the view to navigate to different views that have their own types of stores (see EventDetailsView and EventView lines).

I couldn't use ForEachStore in this scenario because the different views require different store types. Since I am initializing new stores for each view, and they both require an Event object for the state, I use a regular ForEach and initialize new stores for each view. This cuts off their connection with the App/Root Reducer.

What is the proper way to handle a scenario where your item rows require their own state and action, but can also navigate to another view which has its own state and action types?

struct EventListView: View {

    // Store scoped to specific view
    let store: Store<EventListState, EventListAction>
    
    var body: some View {
        WithViewStore(store) { viewStore in
            List {

                // Can't use ForEachStore because I need event for both views below
                ForEach(viewStore.events) { event in
                    NavigationLink {

                        // View with its own store type
                        EventDetailsView(
                            store: .init(
                                initialState: .init(event: event),
                                reducer: eventDetailsReducer,
                                environment: .init(eventClient: .live)
                            )
                        )
                    } label: {

                        // View with its own store type
                        EventView(
                            store: .init(
                                initialState: event,
                                reducer: eReducer,
                                environment: .init(eventClient: .live))
                        )
                    }
                }
            }
            .onAppear {

                // Left here to show that this view requires specific actions
                viewStore.send(.onAppear)
            }
        }
    }
}

[mbrandonw]

It is not going to work to create EventDetailsView by creating a whole new store like this:

EventDetailsView(
  store: .init(
    initialState: .init(event: event),
    reducer: eventDetailsReducer,
    environment: .init(eventClient: .live)
  )
)

That will effectively make the behavior of EventDetailsView inert since any re-render of the list will cause it to reset its state back to event.

Typically if feature A needs to navigate to feature B, then feature A's domain needs to contain feature B. We have a lot of examples of this in the case studies, demo applications and in isowords.

For example, in this case study the parent domain holds onto some optional CounterState. When the state becomes non-nil a sheet is shown and a scoped store is passed to the sheet view, and when the state flips to nil the sheet is dismissed.

So, in your situation you may want to hold onto optional EventDetailState inside the state for each row of the list to drive navigation. Or you can hold optional EventDetailState at the root of the feature, and use a hidden navigation link to drive navigation (a necessary "hack" until you can make use of NavigationStackView).

And for EventView, that does seem like it could just be handed the store that is derived from ForEachStore:

ForEachStore(
  store.scope(state: \.events, action: EventListAction.event)
) { eventStore in 
  EventView(store: eventStore)
}

It is worth noting that the navigation APIs aren't fully baked in the library yet. It's possible to accomplish, and all of the case studies and demo applications show how, but it isn't very ergnomic right now. We have some new tools coming soon that will make the situation much better.