SwiftUI: struct View vs @ViewBuilder

Question

Wenn ich eine Liste von Elementen in SwiftUI rendern möchte, könnte ich Folgendes tun (mit XCode 12):

struct MyView: View {
    let texts: [String]
    var body: some View {
        ScrollView {
            LazyVStack {
                ForEach(texts.indices, id: \.self) { index in
                    MyRow(label: texts[index])
                }
            }
        }
    }

    struct MyRow: View {
        let label: String
        var body: some View {
            Text(label).font(.title3).padding()
        }
    }
}

Anstatt eine Struktur zu sein, MyRowkann es sich um eine Funktion handeln, die den Code etwas prägnanter und funktionaler macht:

struct MyView: View {
    let texts: [String]
    var body: some View {
        ScrollView {
            LazyVStack {
                ForEach(texts.indices, id: \.self) { index in
                    MyRow(label: texts[index])
                }
            }
        }
    }

    @ViewBuilder func MyRow(label: String) -> some View {
        Text(label).font(.title3).padding()
    }
}

Ich möchte den Unterschied zwischen den beiden Ansätzen verstehen. Gibt es Fälle, in denen Sie einander vorziehen würden?

Das erste, was Ihnen in den Sinn kommt, ist, dass Sie keine @StateEigenschaften mit Funktionen haben können. Dies bedeutet, dass Sie den structAnsatz verwenden müssen, wenn Ihre Ansicht den Status benötigt.

Ist das alles? Gibt es Fälle, in denen ein Ansatz hinsichtlich der Optimierung besser ist? Debuggen? Eigenschaften? Portabilität?

Answer 1

@ViewBuilderwird meistens verwendet, um Ansichten bedingt zu rendern, ohne Parser wie zu verwenden AnyView(YourView). So zitieren Sie die Website von Apple Developer : "Clients dieser Funktion können Schließungen mit mehreren Anweisungen verwenden, um mehrere untergeordnete Ansichten bereitzustellen." Wenn Sie beispielsweise eine Ansicht in Abhängigkeit von einer Variablen anzeigen möchten, z. B. Ansicht1 rendern, wenn eine bestimmte Variable wahr ist, und Ansicht2, wenn sie falsch ist.