Working with child states without ForEachStore

[lukeredpath]

A common pattern when displaying a collection of states is to have a child view that takes a store of some child state and using it with ForEachStore to pull each child state out of a collection on the parent domain. For this to work, it requires that your child view fires actions in the form .child(id:action).

Sometimes you might want to use the same child view to display a single record outside the context of a collection. For example, imagine a List view with different sections - each section displays the same ChildRowView but some sections display a ChildRowView for a single specific Child whilst another section iterates over a collection of children using ForEachStore.

Currently this is very awkward to achieve because it requires a bit of hoop-jumping to map the child actions back to the parent domain - something you don't need to think about when working with a collection because ForEachStore handles this for you.

For example, given the following basic domain:

struct Widget: Identifiable, Equatable {}

struct WidgetsFeatureState: Equatable {
  var systemWidget: Widget
  var customWidgets: IdentifiedArrayOf<Widget>
}

enum WidgetsAction {
  case widget(id: Widget.ID, action: WidgetAction)
}

enum WidgetAction {
  case anything
}

In our view, we can easily iterate over the customWidgets and pass the child stores into a WidgetRowView:

struct WidgetsListView: View {
  let store: Store<WidgetsFeatureState, WidgetsAction>

  var body: some View {
    ForEachStore(
      store.scope(
        state: \.customWidgets,
        action: WidgetsAction.widget(id:action:)
      ),
      content: { WidgetRowView(store: $0) }
    )
  }
}

struct WidgetRowView: View {
  let store: Store<Widget, WidgetAction>

  var body: some View {}
}

If we want to display a WidgetRowView for the systemWidget we need to be able to scope the parent store down to a child store for just that one single widget. The state scoping is trivial but the action is a bit awkward:

var body: some View {
  ...

  WidgetRowView(
    store: store.scope(
      state: \.systemWidget,
      action: { 
        // We *could* be in a `WithViewStore` context here but we might not be so we're
        // forced to create one just so we can get the ID that we need.
        WidgetsAction.widget(id: ViewStore(store).systemWidget.id, action: $0)
      }
    )
  )
}

The example above might not look too bad if you already have access to a ViewStore that you can easily obtain the id from but that might not always be the case - you might not have access to a viewStore or you might have already scoped the store down from the current view's store (imagine if .systemWidget was optional and so you're using IfLetStore to get access to a store of some concrete value) so you need to create a ViewStore and pluck the ID out. It's not very obvious or ergonomic.

My current solution to make this better is a custom .scope overload that handles this for me.

public extension Store where State: Identifiable {
    func scope<LocalState, LocalAction>(
        state: @escaping (State) -> LocalState,
        identifiableAction: @escaping (State.ID, LocalAction) -> Action
    ) -> Store<LocalState, LocalAction> {
        // Because store.state is not public we need to use a view store to get the
        // actual ID value from the state. We pass in a custom removeDuplicates to
        // avoid having to constrain this extension to only equatable state.
        let id = ViewStore(self, removeDuplicates: { _, _ in false }).id

        return scope(
            state: state,
            action: { identifiableAction(id, $0) }
        )
    }

    func scope<LocalAction>(
        identifiableAction: @escaping (State.ID, LocalAction) -> Action
    ) -> Store<State, LocalAction> {
        scope(state: { $0 }, identifiableAction: identifiableAction)
    }
}

As you can see if this was part of the library, it would be able to just pull the .id out of the store directly, just like the ForEachStore implementation does.

I've opened this discussion to gauge whether or not there's a desire to incorporate something into TCA that might make this easier, or if there's another good way of approaching this? I'm conscious that too many overloads could be confusing so perhaps if something were to be incorporated into TCA it would be some kind of View that is like ForEachStore but for a single item rather than a scope overload?

[lukeredpath]

I've explored the idea of using a special view instead of a .scope overload and I think I prefer the result as it more closely mirrors the way ForEachStore works - in fact, they are used in almost exactly the same way at the call-site except this one requires a single identifiable state instead of an identified array of state:

public struct IdentifiableChildStore<ChildState, ChildAction, Content>: View
where ChildState: Identifiable & Equatable, Content: View {
    let content: () -> Content

    /// Initializes a structure that computes a child view from a store of a single identifiable value and
    /// an identified action.
    ///
    /// - Parameters:
    ///   - store: A store on an identified array of data and an identified action.
    ///   - content: A function that can generate content given a store of an element.
    public init<ChildContent: View>(
        _ store: Store<ChildState, (ChildState.ID, ChildAction)>,
        @ViewBuilder content: @escaping (Store<ChildState, ChildAction>) -> ChildContent
    )
    where
        Content == WithViewStore<ChildState, (ChildState.ID, ChildAction), ChildContent> {
        self.content = {
            WithViewStore(store) { viewStore in
                content(
                    store.scope(
                        state: { $0 },
                        action: { (viewStore.id, $0) }
                    )
                )
            }
        }
    }

    public var body: some View {
        self.content()
    }
}

Compare how they are used:

With a collection of identifiable state:

ForEachStore(
      store.scope(
        state: \.customWidgets,
        action: WidgetsAction.widget(id:action:)
      ),
      content: { WidgetRowView(store: $0) }
    )
  }

With a single item:

IdentifiableChildStore(
      store.scope(
        state: \.systemWidget,
        action: WidgetsAction.widget(id:action:)
      ),
      content: { WidgetRowView(store: $0) }
    )
  }

[AlexisQapa]

I think you can do something like

reducer.forEach(...).combined(with: reducer)

and simply drop the whole id dance as you don't use it.

edit: not sure if what I wrote is clear but you could handle the two cases separately but with the same reducer.

[lukeredpath]

@AlexisQapa actually, I do use the id in my parent reducer - not all of the row's domain actions are handled by the child reducer, there's a navigation link in the child view that sends an action (e.g. .selectionChanged(Bool)) via its binding which needs to be handled by the parent reducer as there's only a single selection state for the whole list view.

In this case I have a custom container type that holds onto a few individual items as properties and also some collections of items. It implements a custom subscript that can find the right item (whether or not its an individual item or in one of the collections) from a single id.

So I can see what you're saying, but in this case it feels a lot simpler for the reducer to not care how the items are being presented and just treat them like they are all children of one big collection.