List with different types of Views

[pepejeria]

I am trying to figure out to show different type of Views in a List based on the model's type:

struct Pasta {
    var name: String
    var type: PastaType // enum
}

struct PastaListState {
    var pasta: IdentifiedArrayOf<PastaState> = []
}

enum PastaListAction {
    case pasta(id: PastaState.ID, action: PastaAction)
}

struct PastaEnvironment {}

let pastaListReducer = Reducer<
    PastaListState, 
    PastaListAction, 
    PastaEnvironment
> { state, action, environment 
    switch action {
        case .pasta(id: let id, action: _):
            return .non
    }
}

let pastaReducer = Reducer<
    PastaListState, 
    PastaListAction, 
    PastaEnvironment
> { state, action, environment
    pastaReducer.forEach(
        state: \.pasta,
        action: /PastaListAction.pasta(id:action:),
        environment: { _ in init() }
    ),
    pastaListReducer
}

struct PastaListView: View {
    let store: Store<PastaListState, PastaListAction>

    var body: some View {
        NavigationView {
            WithViewStore(store) { viewStore in
                List {
                    ForEachStore(
                        store.scope(
                            state: \.pasta,
                            action: PastaListAction.pasta(id:action:)
                        )
                    ) { store in
                        // Depending on pasta type, show different type of views
                        PastaRowView(store: store)
                    }
                }
                .navigationBarTitle("Pasta")
            }
        }
    }
}

I would in vanilla SwiftUI use the following approach:

List {
    ForEach(viewModel.pasta, content: pastaView)
}

@ViewBuilder
func pastaView(_ pasta: Pasta) -> some View {
    switch pasta.type {
        case .farfalle:
            return FarfalleView()
        case .fusilli:
            return FusilliView()
    }
}

How can I achieve the same with TCA?
Different Views could also mean different functionality, meaning different type of reducers. How can this be achieved?

[stephencelis]

@pepejeria The main two components you'll want to work with enum state are:

1. There's an overload of Reducer.pullback that works with enum state. Note that it takes a CasePath for state, and not a WritableKeyPath. You can use this operator to pull back the associated value of each case of your PastaType enum back to a reducer that works on the enum.
2. SwitchStore, a view that allows you to switch over a store on enum state by using CaseLet views to handle each case.

The main example of using these tools in our repo is the Tic-Tac-Toe demo, which holds its root state in an enum for logged-in/logged-out flows:

1. The case-based reducer pullbacks:

   swift-composable-architecture/Examples/TicTacToe/tic-tac-toe/Sources/AppCore/AppCore.swift

   Lines 30 to 43 in 26dce23

   	loginReducer.pullback(
   	state: /AppState.login,
   	action: /AppAction.login,
   	environment: {
   	LoginEnvironment(
   	authenticationClient: $0.authenticationClient
   	)
   	}
   	),
   	newGameReducer.pullback(
   	state: /AppState.newGame,
   	action: /AppAction.newGame,
   	environment: { _ in NewGameEnvironment() }
   	),

2. The SwitchStore:

   swift-composable-architecture/Examples/TicTacToe/tic-tac-toe/Sources/AppSwiftUI/AppView.swift

   Lines 15 to 28 in 26dce23

   	SwitchStore(self.store) {
   	CaseLet(state: /AppState.login, action: AppAction.login) { store in
   	NavigationView {
   	LoginView(store: store)
   	}
   	.navigationViewStyle(.stack)
   	}
   	CaseLet(state: /AppState.newGame, action: AppAction.newGame) { store in
   	NavigationView {
   	NewGameView(store: store)
   	}
   	.navigationViewStyle(.stack)
   	}
   	}

[pepejeria]

Yes, this is the data model:

struct Pasta {
    var name: String
    var type: PastaType
}

enum PastaType {
    case paccheri
    case fregula
    case mostaccioli
    // etc
}

These data will be retrieve from a server and the idea is to display all pasta in a List, and for each pasta type show a different view.

[tgrapperon]

There are several ways to approach your problem, but it really depends on the complexity of each PastaRowView. Beside each one being specialized to a type of pasta, is there some logic the row needs to perform?

I'm trying to see of you really need a Store at this level, or if you could get away with a standard SwiftUI implementation, but it greatly depends on what your domain looks like. Are there actions in PastaAction, and thus non-trivial logic in the Reducer<PastaState, PastaAction>? Because using a ForEachStore suggests that you have non-trivial logic, but the kind of specialized pasta views you're showing suggests you don't, so I'm receiving mixed signals. Using SwitchStore would mean that your domain's behavior depends on the type of pasta (beside the view you're displaying). Is it the case?

It is also completely possible to open the Store<PastaState, PastaAction> in PastaRowView's body using a WithViewStore and switch over the kind of pasta you'll get from there, but it is also possible that you don't need a ForEachStore and thus the Store<PastaState, PastaAction> to begin with. Can you post what PastaAction looks like?

[pepejeria]

There are several ways to approach your problem, but it really depends on the complexity of each PastaRowView. Beside each one being specialized to a type of pasta, is there some logic the row needs to perform?

Using SwitchStore would mean that your domain's behavior depends on the type of pasta (beside the view you're displaying). Is it the case?

Optimally different types of pasta would have their own actions and their own specific reducer. Would this be possible?

If not, then the alternative would be that all pasta types would have the same actions and same reducer.

I don't think that this would work with vanilla SwiftUI without a reducer, since each pasta type has it's own actions.

Thank you for taking the time to help out.

[tgrapperon]

Yes, it is definitely possible to have each type of pasta having its own set of actions. I think your problem is a domain modelling one, so let work "backward", as it is often simpler to do in TCA. I'm assuming that there are only 2 types of pastas, Farfalle and Fusilli. I'm furthermore assuming that you can have several fusillis and farfalles in your array (for example different brands).
So you have a Farfalle domain with FarfalleState and FarfalleAction, and a farfalle reducer, and the same thing with Fusilli. For example, one has:

struct FarfalleState {
  var id: UUID
  var name: String
}

struct FusilliState {
  var id: UUID
  var name: String
}

The first step is to gather these domains into a larger one that will not perform logic on its own. Its only purpose is to unify both Farfalle and Fusilli domains. Let call this domain Pasta, with a PastaState, and PastaAction, and pastaReducer. Because a pasta is either a Farfalle or a Fusilli and never a little of both, the natural type to handle the state is an enum:

enum PastaState {
  case farfalle(FarfalleState)
  case fusilli(FusilliState)
}

Let make this type Identifiable in prevision of what's coming next:

extension PastaState: Identifiable {
  var id: UUID {
    switch self {
    case let .farfalle(state): return state.id
    case let .fusilli(state): return state.id
    }
  }
}

It is the same for actions, they can only be a FarfalleAction or a FusilliAction, so:

enum PastaAction {
  case farfalle(FarfalleAction)
  case fusilli(FusilliAction)
}

The pasta reducer is then:

let pastaReducer = Reducer<PastaState, PastaAction, Void>.combine(
  farfalleReducer.pullback(state: /PastaState.farfalle, action: /PastaAction.farfalle),
  fusilliReducer.pullback(state: /PastaState.fusilli, action: /PastaAction.fusilli)
)

We finally define the Pastas domain with PastasState, PastasAction and pastasReducer:

struct PastasState {
  var pastas: IdentifiedArrayOf<PastaState>
}
enum PastasActions {
  case pasta(UUID, PastaAction)
}
let pastasReducer = Reducer<PastasState, PastasAction, Void>.combine(
  pastaReducer.forEach(state:\.pastas, action: /PastasAction.pasta),
  Reducer<PastasState, PastasAction, Void> { … } // perform additional logic
)

So your objective is to build the IdentifiedArray from the values you receive from the server. As everything is fully typed, it should be rather straightforward.

Now, on the view's side, you need to drill down in the other direction:

ForEachStore(state: \.pastas, action: PastasAction.pastas) { pastaStore in
  SwitchStore(pastaStore) {
    CaseLet(state: /PastaState.farfalle, action:PastaAction.farfalle) { farfalleStore in
      FarfalleView(store: farfalleStore)
    }
    CaseLet(state: /PastaState.fusilli, action:PastaAction.fusilli) { fusilliStore in
      FusilliView(store: fusilliStore)
    }
  }
}

I hope it'll help. It is possible that I made mistakes here and there. Please let me know if you still have issues. You can probably simplify a lot your model you're only presenting types of pastas (that is only one Fusilli in your array, one Farfalle, etc) and not pastas with types like I assumed from your earlier messages. In this case, you can modify PastaState's Identifiable conformance to return its PastaType as id instead.

[pepejeria]

Thank you very much for your reply tgrapperon, this was what I was looking for.