Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Recommended UIContentConfiguration / UIContentView pattern for table and collection cells

Aperta
  • Qualcosa non va?
#59 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
swift
Ambito
mobile-dev

Direzione di ricerca

Inizia da Sources/QuickLayout/QuickLayoutBridge/ViewImplementation/HasBody.swift nel caso speciale collegato di UITableViewCell e UICollectionViewCell, quindi esamina l’esempio di UIContentConfiguration e CardContentView in questa issue. Documenta il comportamento supportato relativo a ownership, sizing e invalidation, le indicazioni sul riutilizzo di supports(_:) e le eventuali differenze tra tabelle e collezioni, con esempi per entrambi i tipi di cella.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Question

Related to #12, but this question is about UIKit’s configuration-based cell architecture rather than applying @QuickLayout directly to each cell subclass.

QuickLayout currently special-cases UITableViewCell and UICollectionViewCell so that a cell’s QuickLayout body is hosted in cell.contentView. With UIContentConfiguration, UIKit creates and manages a custom UIContentView. I could not find an example of this pattern and am unsure which object should own QuickLayout layout and sizing.

When a generic UITableViewCell or UICollectionViewCell receives a custom UIContentView, is applying @QuickLayout to that content view the supported approach?

Minimal example
struct CardConfiguration: UIContentConfiguration {
  let title: String

  @MainActor
  func makeContentView() -> any UIView & UIContentView {
    CardContentView(configuration: self)
  }

  func updated(for state: any UIConfigurationState) -> Self {
    self
  }
}

@QuickLayout
final class CardContentView: UIView, UIContentView {
  private let titleLabel = UILabel()
  private var model: CardConfiguration

  var configuration: any UIContentConfiguration {
    get { model }
    set {
      guard let configuration = newValue as? CardConfiguration else { return }
      model = configuration
      titleLabel.text = configuration.title
      setNeedsLayout()
    }
  }

  init(configuration: CardConfiguration) {
    model = configuration
    super.init(frame: .zero)
    self.configuration = configuration
  }

  @available(*, unavailable)
  required init?(coder: NSCoder) {
    fatalError()
  }

  var body: Layout {
    HStack {
      titleLabel
    }
    .padding(.horizontal, 16)
    .padding(.vertical, 8)
  }
}

// The same configuration is assigned to either cell type:
cell.contentConfiguration = CardConfiguration(title: title)

Could you clarify:

  • Should @QuickLayout live only on the custom UIContentView, leaving the cell generic, or should the cell also adopt @QuickLayout?
  • For self-sizing table rows and collection items with estimated dimensions, is the generated sizeThatFits(_:) on the content view sufficient, or is cell-level sizing customization still required as discussed in #12?
  • When applying a configuration that changes the content size, is setNeedsLayout() sufficient? Should invalidateIntrinsicContentSize(), a cell-level invalidation call, or a QuickLayout-specific helper be used?
  • On iOS 16+, should supports(_:) be implemented so UIKit can reuse the existing content view?
  • Are there any differences in the recommended pattern for UITableViewCell and UICollectionViewCell?

An official example covering both cell types would be very helpful. Thanks!

Environment
  • QuickLayout: main at 38020f2
  • Swift 6
  • iOS 15+
Lingua principale
Swift
Stelle
366
Fork
21
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di facebook/QuickLayout

Tutte le issue di facebook/QuickLayout

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.