Canonical Example for using TCA in UIKit CollectionView/TableView Cells

[heyltsjay]

The DataSource pattern in UIKit is an awkward seam for TCA to transcend - The usual pattern of "subscribe to a scoped store, re-render", can be dangerous if a collectionView.dataSource isn't updated in-step.

One very feasible solution is to not model cell state with TCA - I'd wager that cells should never manipulate their own state directly. But the Action handling of TCA is too compelling to ignore.

I'd love to drive towards an example implementation that is a bit more robust than what exists in the CaseStudies today.

One approach I explored in #472 is exposing some synchronous unwrapping of stores. This removes some of the optional-but-not-really babysitting that a few other TCA/UIKit developers are using right now. Now moving the discussion over here.

Some "how might we's" around this domain:

• How might we scope a cell's store so that its State is readonly, but it can emit Actions
• How might we model a cell in TCA so that its contents could subscribe to a publisher just once, and survive re-use
• How might we let the compiler know that we have our ViewStore.dataSource and CollectionView.datasource in sync, so that mismatching indices fail fast and hard.

[heyltsjay]

This idea from @stephencelis seems promising - rather than give the cell a store, give it a publisher of stores directly:

An alternative that we wonder if you've considered is pushing the cancellable into the cell. That way it would be the cell's responsibility to manage the lifecycle. Rather than configure the cell with a store directly, I think you could use publisherScope to configure the cell with a publisher of stores instead. This is the method store.ifLet calls under the hood. Sketching this out for a dequeued cell:

cell.publisher = self.store.publisherScope(
  state { storePublisher in storePublisher.compactMap(\.cells[id: item.id]) },
  action: { Action.cell(id: item.id, action: $0) }
}

[heyltsjay]

This direction, however, brings me back to the main pain point I'd like to avoid - A cell's store would have to start as nil, which I think is the wrong place to reconcile this "optionality."

I think the 2 main features of a good solution here would involve:

• Some sort of strict enforcement that a collectionView's dataSource and the data backing it stay in sync.
• A call-site for the cell where viewStore.send and viewStore.publisher both continue to work through reuse (without having to re-set subscriptions)

This would allow a cell to have the same contract of all the other views/VC's in TCA/UIKit land.

[simme]

How would it start as anything other than nil? A default empty store in the cell class itself?

[heyltsjay]

Well we know the cell gets created when the datasource has data ready to go to create it.
So it really should only need an init(store: Store)

[simme]

How would you make that jive with cell reuse though? I'm with you in theory, but don't see how it would work in practice since we don't have the option to override the initialization point? Or am I missing something?

[acosmicflamingo]

Looks like using publisherScope might not be ideal now that it was deprecated September 2021: 4bdcaaf.

[simme]

How might we scope a cell's store so that its State is readonly, but it can emit Actions

I'm not 100% convinced readonly State is a given. What I've found is that something like for example async image loading is pretty nice to do in the scope of a cell. It also means that cancellation when a cell moves off screen can be achieved by cancelling an effect loading the image via an action sent from prepareForReuse().

I usually do the image loading and scaling/cropping via an "ImageClient" on the environment that stores a ready to use image at a given URL and then returns the URL, which updates the state that triggers a viewStore.publisher.imageURL-subscription to load the actual image and show it in a UIImageView.

This could of course be achieved in the parent reducer as well. But makes sense to me to keep it local.

How might we model a cell in TCA so that its contents could subscribe to a publisher just once, and survive re-use

I wonder if this is desirable? Say you have a collection view with thousands of items and the user scrolls through them all. Would that mean thousands of active subscriptions that can potentially trigger store updates even when the cell is off-screen? I guess the way I do it the scoped stores are all sticking around, but no one is observing them.

How might we let the compiler know that we have our ViewStore.dataSource and CollectionView.datasource in sync, so that mismatching indices fail fast and hard.

What I tend to do is to have a computed property on my view state that is basically just a list of ids representing the items in the collection view. Sometimes ordered by sections in a multi-dimensional array. I then use a UICollectionViewDiffableDataSource that is generic over that id, not the entire cell model.

  typealias DataSource = UICollectionViewDiffableDataSource<ListSectionType, ListItem.Id>
  typealias Snapshot = NSDiffableDataSourceSnapshot<ListSectionType, ListItem.Id>

In the cell configuration step I then scope the store to a given id:

self.store.scope(
      state: { $0.cellStates[id: itemId] },
      action: { ListAction.listCellAction(id: item, action: $0) }
    ).ifLet { store in
      cell.configure(with: store)
    }.store(in: &self.cellStores, for: item)

Where in this case cellStates is an IdentifiedArrayOf<ListItem>.

---

One of the things I've been struggling the most with though is how to handle cell state vs. model. I find I often want to "augment" the state of the cell with additional data — not only the model being displayed. Like for example the above mentioned imageURL or other data like lastInSection. Perhaps that could be solved in my case by having a subscript or method on the list state that returns the full cell state in a computed fashion, instead of storing it in an identified array and trying to have it sync up with changes in the model (when observing changes in the database or having the data changed from another feature). Honestly I'm not quite sure of the performance implications of having potentially very many substates be computed like that.

---

Deleted my previous comment to keep things clean.

[mycroftcanner]

@heyltsjay what do you think of :

if let item = ViewStore(store.scope(state: { $0.items[id: propID] })).state {
 cell.update(
    id: item.id,
    with: store.scope(
      state: { _ in item },
      action: { ItemAction.item(id: item.id, action: $0) }
   )
  )
}

[mycroftcanner]

edited ^^ the if let was missing.

[mycroftcanner]

you don't need to setup any listener inside the cell. If your item identifier is a struct with a hash or modification timestamp then it will be updated whenever the view store of the collection view updates.

[heyltsjay]

@mycroftcanner The pattern I've landed on for now is to:

1. Bake Cell.State into the datasource of the collectionView's Snapshot
2. Have var snapshot: Snapshot be a derived property from State
3. Then yes, more or less what you've provided. Some sort of pattern where a cell has an update route, where all the publishers/subscriptions can be re-wired with the new values.

[acosmicflamingo]

For anyone who reads this thread, know that when you do not use the parameter being passed in the state closure that you run the risk of modifying a copy of state instead of the state itself. I found this out the hard way ;)

[acosmicflamingo]

Has anyone found a rather clean way to utilize both TCA and UICollectionViewDiffableDataSource in their projects since this ticket was last updated almost a year ago? Unfortunately, I can't find any examples that are widely embraced by the community :(

@heyltsjay are you still utilizing the same pattern? Or is there something you're now doing that is not reflected in this discussion?

Edit: does anyone see any problems with this tutorial: https://www.iamsim.me/composable-architecture-and-uikit-collection-views/ ? Seems like the only example out there that can be used as a guide.

[heyltsjay]

The most compelling pattern I've landed on is modeling state as readonly, and using the pattern they've used for alert views for relaying actions to the parent store. Away from computer this weekend but will edit this reply when I'm back.

Edit: sketched here: #484 (comment)

[CtrlJone]

@heyltsjay Hi, borther, for many different types of Cell and Model, do you have any better suggestions? Is there a specific implementation Demo that you can refer to?

[heyltsjay]

This is a sketch for my current recommendation for best practice, which should cover 90% of use cases.

• Cell has read-only state, no environment, no reducer, and makes no decisions
• Actions are forwarded using a send closure, similar to UIKit alerts + TCA

// State, Action, Reducer definitions
extension Parent {

    struct State {
        let data: [Model]
    }

    enum Action {
        case cell(id: String, action: Cell.Action)
    }

}

// Snapshot is a derived property of state
extension Parent.State {

    typealias Section = Parent.Section
    typealias Item = Parent.Item
    typealias Snapshot = NSDiffableDataSourceSnapshot<Section, Item>

    var snapshot: Snapshot {
        var snapshot = Snapshot()
        if !data.isEmpty {
            snapshot.appendSections([.data])
            snapshot.appendItems([data.map(Item.data)])
        }
    }

}

// Parent sets up diffable datasource, and populates cell
class Parent: UIViewController {

    init() {
        super.init(nibName: nil, bundle: nil)

        // set-up view
        // ...
        //

        observeDataSource()
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

}

extension Parent: UITableViewDelegate {

    enum Section: Hashable, CaseIterable {
        case data
    }

    enum Item: Hashable, Equatable {
        case data(Model)
    }

    func observeDataSource() {
        viewStore.publisher.snapshot
            .receive(on: DispatchQueue.main)
            .sink { [weak self] snapshot in
                self?.tableViewDataSource.apply(snapshot)
            }
            .store(in: &cancellables)
    }

    func cell(tableView: UITableView, indexPath: IndexPath, item: Item) -> UITableViewCell {
        switch item {
        case .data(let model):
            let cell: Cell = tableView.dequeueReusableCell(withIdentifier: "\(Cell.self)")
            cell.state = .init(
                id: model.id,
                title: model.title
            )
            cell.send = { [weak self] in
                self?.viewStore.send(.cell(id: model.id, action: $0))
            }
        }
    }

}

// Cell has readonly state, and sends actions to a `send` closure
class Cell: UITableViewCell {

    struct State: Hashable, Equatable {
        var id: String = ""
        var title: String?
    }

    enum Action {
        case ctaTapped
    }

    @Published var state = State()

    var send: ((Action) -> Void)?

    func onCTATapped() {
        send?(.ctaTapped)
    }

}

[acosmicflamingo]

Thanks for taking the time to write it out!!! Very intriguing how you're utilizing NSDiffableDataSourceSnapshot in your State. Makes sense; it adds another aspect of your module that you can test, to make sure everything is updating as it should be. Really cool!

[CtrlJone]

@heyltsjay Hi, big guy, for combining different sections and cells, as well as different models, is there a more reasonable way of writing? The point is that there will be sections.

[heyltsjay]

Just expand Section and Item like you would a normal DiffableDataSource

    enum Section: Hashable, CaseIterable {
        case data
        case otherSection
        case anotherSection
    }

    enum Item: Hashable, Equatable {
        case data(Model)
        case cellType2(Cell2Model)
        case cellType3(Cell3Model)
    }

[CtrlJone]

thanks a lot

[mycroftcanner]

Doesn’t have to be UIKit would be similar in SwiftUI.On 22 Sep 2022, at 15:00, Jay Clark ***@***.***> wrote: This is a sketch for my current recommendation for best practice, which should cover 90% of use cases. Cell has read-only state, no environment, no reducer, and makes no decisions Actions are forwarded using a send closure, similar to UIKit alerts + TCA extension Parent { struct State { let data: [Model] } enum Action { case cell(id: String, action: Cell.Action) } } extension Parent.State { typealias Section = Parent.Section typealias Item = Parent.Item typealias Snapshot = NSDiffableDataSourceSnapshot<Section, Item> var snapshot: Snapshot { var snapshot = Snapshot() if !data.isEmpty { snapshot.appendSections([.data]) snapshot.appendItems([data.map(Item.data)]) } } } class Parent: UIViewController { init() { super.init(nibName: nil, bundle: nil) // set-up view // ... // observeDataSource() } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } } extension Parent: UITableViewDelegate { enum Section: Hashable, CaseIterable { case data } enum Item: Hashable, Equatable { case data(Model) } func observeDataSource() { viewStore.publisher.snapshot .receive(on: DispatchQueue.main) .sink { [weak self] snapshot in self?.tableViewDataSource.apply(snapshot) } .store(in: &cancellables) } func cell(tableView: UITableView, indexPath: IndexPath, item: Item) -> UITableViewCell { switch item { case .data(let model): let cell: Cell = tableView.dequeueReusableCell(withIdentifier: "\(Cell.self)") cell.state = .init( id: model.id, title: model.title ) cell.send = { [weak self] in self?.viewStore.send(.cell(id: model.id, action: $0)) } } } } class Cell: UITableViewCell { struct State: Hashable, Equatable { var id: String = "" var title: String? } enum Action { case ctaTapped } @published var state = State() var send: ((Action) -> Void)? func onCTATapped() { send?(.ctaTapped) } } —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[acosmicflamingo]

Has anyone been able to figure out how to handle cells comprising a toggle switch? I'm stuck on trying to figure out the most appropriate way to handle this from a conceptual level.

For example, suppose we have a view controller that displays one section with a navigation cell and a toggle switch cell:

let viewController = TableViewController(
  store: Store(
    initialState: .init(
      section: .init(
        header: "Options",
        items: [
          TableViewItem(
            title: "Switch Cell",
            subtitle: "Toggles a switch and does something useful afterwards",
            isOn: ??????
          )
        ]
      )
    ),
    reducer: TableViewExample()
  )
)

What I can't wrap my head around is what I pass to TableViewExampleItem.isOn in a way that abides by TCA principles. The non-TCA way would perhaps be passing an action closure that modifies state in some way:

TableViewItem(
  isOn: { toggleValue in
    @Dependency(\.userDefaults) var userDefaults: UserDefaultsClient
    userDefaults.userInterfaceStyle = toggleValue ? .dark : .light
  }
)

This is a no-no in TCA-world because an external dependency has been used to modify state in some manner but there is no way the Reducer would be aware of this, making it untestable. Perhaps what the parameters should be is an action, so it'd look like this:

TableViewItem(
  isOn: viewStore.send(.darkModeToggleSwitchTapped(nil))
)
// or
TableViewItem(
  isOn: /Action.darkModeToggleSwitchTapped(nil)
)

Then, in the reducer I could do something like this:

switch action {
case let .darkModeToggleSwitchTapped(toggleValue):
  if let toggleValue {
    state.userSettings.userInterfaceStyle = toggleValue ? .dark : .light
  }
}

Or maybe I could even utilize TableViewItem.ID in a way that makes it possible to know which cell received the action:

enum TableViewItemID {
  static let darkModeToggleCell = UUID()
}

TableViewItem(
  id: TableViewItemID.darkModeToggleCell
)

Reducer { state, action in
  switch action {
  case let tableViewCellTapped(cellId):
    switch cellId {
      case is TableViewItemID.darkModeToggleCell:
        state.userSettings.userInterfaceStyle = toggleValue ? .dark : .light
    }
  }
}

The second option actually seems the most practical, with the least amount of boilerplate code. Is this the way I should go about it or does anyone have any better suggestions?

[acosmicflamingo]

@rcarver was able to point me in the right direction with how to use generics here, and it is the perfect solution. What I essentially want to do is this:

public enum TableViewItem<Reducer: ReducerProtocol> {
  case switchRow(SwitchRowItem<Reducer>)
  case navigationRow(NavigationRowItem)
}

...

public struct SwitchRowItem<Reducer: ReducerProtocol> {
  public var id: UUID
  public var title: String
  public var subtitle: String?
  public var isOn: Bool?
  public var action: CasePath<Reducer.Action, Bool>?

  public init(
    id: UUID = .init(),
    title: String,
    subtitle: String? = nil,
    isOn: Bool? = nil,
    action: CasePath<Reducer.Action, Bool>? = nil
  ) {
    self.id = id
    self.title = title
    self.subtitle = subtitle
    self.isOn = isOn
    self.action = action
  }
}

Of course, there may some boilerplate involved with making sure isOn is properly set, but at least there's a path forward such that I can now map an item to a reducer's action.