Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Recommended UIContentConfiguration / UIContentView pattern for table and collection cells

Abierto
#59 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Documentación
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
swift
Área
mobile-dev

Línea de trabajo

Comienza con Sources/QuickLayout/QuickLayoutBridge/ViewImplementation/HasBody.swift en el caso especial vinculado de UITableViewCell y UICollectionViewCell, y luego revisa el ejemplo de UIContentConfiguration y CardContentView en este issue. Documenta el comportamiento admitido de ownership, sizing e invalidation, las directrices de reutilización de supports(_:) y cualquier diferencia entre tablas y colecciones, con ejemplos para ambos tipos de celda.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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+
Lenguaje dominante
Swift
Estrellas
365
Forks
21
Métricas de merge de PR
Sin PR fusionados en 30 d

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de facebook/QuickLayout

Todos los issues de facebook/QuickLayout

Issues similares

Más issues de Swift

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.