Die Herausforderung
Beim Erstellen von Views, die von asynchronen Daten abhängen, hast du typischerweise einen Ladezustand, der einen Spinner oder Platzhalter anzeigt. In der Produktion erscheint dieser Zustand kurz, während Daten aus dem Netzwerk oder der Datenbank geladen werden. Aber in SwiftUI Previews sind deine Mock-Daten sofort verfügbar, sodass der Ladezustand zu schnell vorbeihuscht, um ihn zu begutachten – oder gar nicht erst erscheint.
Ein rein auf Previews beschränkter Delay-Helper
Die Lösung ist ein kleiner Helper, der eine künstliche Verzögerung einführt, aber nur im Preview- oder Debug-Kontext. Hier ist das Muster:
struct DelayedStatePreview<Content: View>: View {
@State private var isLoaded = false
let delay: Duration
let content: (Bool) -> Content
init(
delay: Duration = .seconds(2),
@ViewBuilder content: @escaping (Bool) -> Content
) {
self.delay = delay
self.content = content
}
var body: some View {
content(isLoaded)
.task {
try? await Task.sleep(for: delay)
isLoaded = true
}
}
}Du verwendest es in einem Preview so:
#Preview {
DelayedStatePreview { isLoaded in
if isLoaded {
ArticleListView(articles: mockArticles)
} else {
LoadingView()
}
}
}
Warum das wichtig ist
Der entscheidende Vorteil ist, dass dein Produktionscode sauber bleibt. Du fügst keine künstlichen Verzögerungen oder Debug-Flags zu deinen eigentlichen Views hinzu. Der Helper existiert rein auf der Preview-Ebene und gibt dir die Möglichkeit, visuell zu überprüfen, ob deine Ladezustände korrekt aussehen, ob Übergänge flüssig animieren und ob das Layout nicht springt, wenn Daten ankommen.
Das ist besonders nützlich für Views mit Skeleton-Loadern oder Shimmer-Effekten, bei denen die visuelle Qualität des Ladezustands Teil der User Experience ist.