DTTableViewManager

In 7.0, header and footer APIs have been rewritten to be closure-based. Note the following behavioral changes:

1. Manual Reload Required: Setting header or footer models no longer automatically triggers UITableView.reloadData(). You must call reloadData() manually if you update them after the table view is on screen.
2. Section Creation: Setting header/footer models no longer automatically creates sections in storage. If you need a section with 0 items (to show a header, for example), you must explicitly set items in the storage (e.g., memoryStorage.setItems([Int](), forSectionAt: index)).
3. Protocol Removal: The SupplementaryAccessible protocol and its extensions (tableHeaderModel, tableFooterModel) have been removed. To retrieve a model, use storage.header(for:) or storage.footer(for:) directly.

To automate the mapping between a data model and a cell, implement the ModelTransfer protocol in your UITableViewCell subclass. When you register the cell, DTTableViewManager uses this protocol to infer the relationship, enabling type-safe delegate closures and automatic model updates.

If you do not want to use the protocol, you can provide a manual handler during registration to update the cell with the model.

// Using ModelTransfer protocol (Recommended)
class VideoPostCell: UITableViewCell, ModelTransfer {
    func update(with model: VideoPost) {
        // update cell logic
    }
}

// Manual handler (Alternative for simple cells)
manager.register(UITableViewCell.self, for: MenuItem.self) {
    mapping in
    mapping.didSelect { cell, model, indexPath in
        // handle selection
    }
} handler: { cell, model, indexPath in
    cell.textLabel.text = model
}

The recommended way to establish a mapping between a UITableViewCell/UITableViewHeaderFooterView and a data model is by conforming your view to the ModelTransfer protocol. This protocol requires implementing a single update(with:) method to handle data transfer.

When you register a cell that conforms to ModelTransfer, DTTableViewManager automatically establishes the mapping between the model type and the cell type.

class FoodTableViewCell : UITableViewCell, ModelTransfer {
    func update(with model: Food) {
        // Display food in a cell
    }
}

// Registration
manager.register(FoodTableViewCell.self)

Previously, all cell and view subclasses were required to conform to the ModelTransfer protocol. DTTableViewManager 8.0 removes this restriction, allowing you to use standard, unsubclassed views.

Note: For views that do not conform to ModelTransfer, you must use the new event registration style (via the mapping closure).

// Registering an unsubclassed UITableViewCell
manager.register(UITableViewCell.self, for: String.self) { mapping in
    // customize mapping
} handler: { cell, model, indexPath in
    cell.textLabel.text = model
}

// Registering an unsubclassed UITableViewHeaderFooterView
manager.registerHeader(UITableViewHeaderFooterView.self, for: String.self) { mapping in
    // customize mapping
} handler: { header, model, indexPath in
    // ...
}

Event closures in DTTableViewManager follow two main signature patterns depending on whether the delegate method provides access to the cell/view:

1. With View/Cell access: (View, Model, IndexPath) -> ReturnType. Used when the cell or reusable view is available.

   • Example: mapping.didSelect { cell, model, indexPath in ... }
   • Example: mapping.willDisplay { cell, model, indexPath in ... }

2. Without View/Cell access: (Model, IndexPath) -> ReturnType. Used when the cell/view is not yet created or required by the delegate method.

   • Example: mapping.heightForCell { model, indexPath in return 44 }

Standard UITableView selection and SwiftUI interaction (like Button) can clash.

Best Practices:

• Avoid SwiftUI Buttons: Do not use SwiftUI.Button inside a cell if you also rely on tableView(_:didSelectRowAt:). They do not play well together.
• Use Gestures: Instead, use the .onTapGesture modifier on your SwiftUI view and communicate the event through your data model/view model.
• Selection Style: HostingTableViewCell sets UITableViewCell.SelectionStyle = .none by default to prevent visual clashes.

If the provided storage options do not meet your needs, you can implement your own. You can either subclass one of the five existing storage types or create a new one from scratch.

Requirements:

• Implement the Storage protocol.
• (Optional) Implement the SupplementaryStorage protocol if you need to manage header/footer models.

DTTableViewManager provides optional access to supplementaryStorage. This accessor is available for all five built-in storages and any custom storage that implements the SupplementaryStorage protocol.

manager.supplementaryStorage?.setSectionHeaderModels([1])

DTTableViewManager detects common usage errors (e.g., registering an empty XIB) and emits anomalies. By default, these are non-fatal errors logged to the console.

You can customize the behavior by setting an anomaly handler to send errors to analytics providers, or you can silence specific or all anomalies.

SingleSectionEquatableStorage is designed for a single section and calculates UI updates using a provided differ. Since DTModelStorage does not provide a built-in differ, you must provide an adapter for your chosen differ (e.g., Changeset, Dwifft, or HeckelDiff).

To set it up, initialize the storage with your items and a differ, then assign it to the manager's storage property.

let storage = SingleSectionEquatableStorage(items: arrayOfPosts, differ: ChangesetDiffer())
storage.setItems(startingItems)
manager.storage = storage

storage.addItems(newItems)