Reusing a list container component with different cell

[superx3man]

In my project, there's a list component that I'd like to reuse for another screen, but it has a different cell design and functionality.

My first thought was wrapping the different types of cells in an enum-driven ReducerProtocol.

struct MyList: ReducerProtocol {
  struct State {
    var cells: IdentifiableArrayOf<Cell>
  }
}

struct Cell: ReducerProtocol {
  enum State {
    case design1(CellWithDesign1)
    case design2(CellWithDesign2)
  }
}

Though this would require the module that hosts MyList to have knowledge of every variation of cells. In a modularized codebase, the list module would need to have dependencies on all cells' modules.

After playing around with generics, I have this pattern prototyped.

protocol StoreView: View {
    associatedtype State
    associatedtype Action

    var store: Store<State, Action> { get }
    init(store: Store<State, Action>)
}

protocol ReducerWithViewProtocol: ReducerProtocol {
    associatedtype View: StoreView
}

struct Wrapper<Child>: ReducerProtocol
where Child: ReducerWithViewProtocol,
      Child.State: Equatable, // Could potentially forces State to implement certain methods for the wrapper.
      Child.Action: Equatable,
      Child.View.State == Child.State,
      Child.View.Action == Child.Action {

    let makeChild: () -> Child
    struct State: Equatable {
        var child: Child.State
    }
    enum Action: Equatable {
        case child(Child.Action)
    }
    typealias Store = ComposableArchitecture.Store<State, Action>

    var body: some ReducerProtocol<State, Action> {
        Scope(state: \.child, action: /Action.child) {
            makeChild()
        }
    }

    struct View: StoreView {
        let store: Store
        var body: some SwiftUI.View {
            Child.View(store: store.scope(state: \.child, action: Action.child))
        }
    }
}

The above wrapper call takes in a ReducerProtocol with a bit of extra information and could work with a flexible type.
The advantage is now I could have cell designs in different modules and these modules would have a dependency on the list module. (Instead of the reverse)

I haven't dug too much into this pattern and wonder if anyone has tried it before. Not sure this would cause problems down the road when I expand on it.

[mbrandonw]

Hi @superx3man, I haven't personally used this pattern, but just wanted to say that nothing immediately stands out as problematic about it. I'd be curious to see an example of what it looks like at the call site when you construct the parent domain, both reducer and view.

[superx3man]

Neat! I'm going to explore a bit further on it!