View Protocol — konsep kunci, protokol View di SwiftUI

Apa itu View Protocol di SwiftUI?

View Protocol — adalah protokol pusat SwiftUI yang mendefinisikan bagaimana setiap elemen visual mendeskripsikan kontennya. Berbeda dengan UIKit, di mana setiap elemen mewarisi dari UIView melalui kelas, SwiftUI menggunakan pendekatan berorientasi protokol: tipe apa pun yang sesuai dengan protokol View dapat ditampilkan di layar.

Protokol View memerlukan implementasi satu properti komputasi body, yang mengembalikan suatu konten. Namun di balik kesederhanaan ini terdapat sistem komposisi yang kuat: body dapat mengembalikan tipe apa pun yang sesuai dengan View, termasuk primitif (Text, Image, Button), kontainer (VStack, HStack, ZStack), dan komponen gabungan kustom.

Menurut WWDC 2023, lebih dari 95% seluruh layar dalam aplikasi SwiftUI dibangun melalui komposisi struktur yang mengimplementasikan protokol View. Hal ini menjadikan View Protocol sebagai fondasi seluruh arsitektur SwiftUI.

Value type vs reference type

SwiftUI mengharuskan View menjadi value type (struktur, struct), bukan kelas. Ini adalah keputusan arsitektur kunci: value types memiliki masa hidup yang dapat diprediksi, tidak memiliki status yang dapat diubah bersama, dan memungkinkan SwiftUI menentukan secara efisien bagian hierarki mana yang telah berubah dan memerlukan penggambaran ulang.

Jika Anda mencoba membuat View sebagai kelas, kompiler akan memberikan kesalahan: protokol View mewarisi dari protokol DynamicViewProperty, yang memerlukan value semantics. Kelas dapat sesuai dengan View, tetapi ini melanggar pendekatan idiomatis dan menghilangkan keuntungan pembaruan otomatis.

body: properti komputasi dari protokol View

body — satu-satunya persyaratan wajib dari protokol View. Ini adalah properti komputasi yang mengembalikan konten yang ditampilkan di layar. Tipe nilai yang dikembalikan — some View, yang berarti "tipe tertentu yang sesuai dengan View, yang akan ditentukan oleh kompiler".

struct GreetingView: View {
    var name: String

    var body: some View {
        VStack {
            Text("Halo, \(name)!")
                .font(.title)
                .foregroundColor(.blue)
            Button("Mulai") {
                print("Tombol ditekan")
            }
        }
    }
}

Bagaimana body bekerja: SwiftUI memanggil body setiap kali status aplikasi berubah dan diperlukan penggambaran ulang. Framework membandingkan pohon View baru dengan yang lama dan hanya menerapkan perubahan yang diperlukan (diffing). Ini adalah pendekatan yang sepenuhnya deklaratif — Anda mendeskripsikan apa yang harus ditampilkan, dan SwiftUI mengurus cara mengimplementasikannya.

Detail penting: body tidak boleh memiliki efek samping. Ini dipanggil berkali-kali selama masa hidup aplikasi, dan jika di dalam body status eksternal berubah — ini menyebabkan perilaku yang tidak dapat diprediksi. Untuk efek samping, gunakan task, onChange, atau DispatchQueue.

Batasan jumlah elemen

SwiftUI memberlakukan batasan: body hanya dapat mengembalikan satu elemen akar. Jika Anda perlu menampilkan beberapa elemen pada level yang sama, bungkus dalam kontainer — VStack, HStack, ZStack, atau Group. Dengan munculnya @ViewBuilder, batasan ini menjadi kurang terlihat, tetapi secara konseptual body selalu mengembalikan satu View.

some View: tipe buram dalam protokol

some View — adalah sintaks tipe buram (opaque type) yang diperkenalkan di Swift 5.1 khusus untuk SwiftUI. Ini berarti fungsi atau properti mengembalikan tipe konkret yang sesuai dengan protokol View, tetapi kode pemanggil tidak tahu dan tidak perlu tahu tipe pasti apa yang dikembalikan.

Kompiler Swift menetapkan tipe konkret pada tahap kompilasi untuk setiap implementasi body, tetapi menyembunyikannya dari dunia luar. Ini memungkinkan SwiftUI mengoptimalkan hierarki View dengan mengetahui tipe pasti semua komponen, tetapi memberikan pengembang fleksibilitas dalam mengubah implementasi tanpa mengubah tanda tangan.

struct ContentView: View {
    var body: some View {
        Text("Halo, Dunia!") // Kompiler tahu ini adalah Text
    }
}

Mengapa some View, bukan hanya View? Jika body hanya mengembalikan View (sebagai protokol), SwiftUI tidak akan dapat menentukan tipe konkret selama kompilasi. Ini menyebabkan overhead tambahan untuk pembungkusan ke dalam kontainer eksistensial (existential container). some View memberikan kompiler informasi yang cukup untuk optimasi, sambil mempertahankan fleksibilitas protokol.

Batasan some View

Batasan utama — body harus mengembalikan tipe yang sama. Tidak dapat mengembalikan Text di satu cabang kondisi dan Image di cabang lain tanpa pembungkus khusus (AnyView, Group, atau @ViewBuilder). Kompiler memeriksa ini pada tahap kompilasi: semua jalur pengembalian yang mungkin harus memiliki tipe yang sama.

Untuk mengatasi batasan ini digunakan @ViewBuilder (membuat tipe TupleView tunggal), Group (yang juga mengembalikan tipe tunggal), atau AnyView (menghapus tipe, tetapi menambah overhead). AnyView hanya boleh digunakan ketika opsi lain tidak memungkinkan, karena menonaktifkan optimasi SwiftUI.

@ViewBuilder: menggabungkan beberapa View

@ViewBuilder — adalah result builder yang notasinya memungkinkan penggabungan beberapa View menjadi satu komposisi tanpa kontainer bersarang. @ViewBuilder secara otomatis membungkus beberapa ekspresi ke dalam tuple (TupleView) atau menerapkan logika kondisional (If / else / switch) dengan tipe pengembalian yang benar.

struct DashboardView: View {
    var isLoggedIn: Bool

    @ViewBuilder
    var body: some View {
        if isLoggedIn {
            Text("Selamat datang!")
                .font(.largeTitle)
            ProfileCard()
        } else {
            LoginButton()
                .padding()
        }
    }
}

Bagaimana @ViewBuilder bekerja: kompiler mengubah setiap blok kode di dalam @ViewBuilder menjadi panggilan ke metode statis buildBlock, buildEither, buildOptional, dll. Jika blok berisi beberapa ekspresi — ekspresi tersebut dibungkus dalam TupleView. Jika blok berisi logika kondisional — kompiler menghasilkan ConditionalContent yang menyembunyikan tipe cabang.

@ViewBuilder memberlakukan batasan: hingga 10 elemen dalam satu blok (batasan TupleView). Jika perlu menggabungkan lebih dari sepuluh elemen, gunakan Group, ForEach, atau bagi menjadi subkomponen. Batasan ini ada karena Swift menghasilkan kelebihan beban terpisah dari buildBlock untuk setiap aritas dari 1 hingga 10.

Komposisi View dan pengubah

Komposisi — prinsip kunci SwiftUI: antarmuka kompleks dibangun dari komponen View kecil yang dapat digunakan kembali. Setiap komponen mengimplementasikan protokol View dan bertanggung jawab atas bagian layarnya sendiri. Pengubah (font, padding, foregroundColor) diterapkan ke View dan mengembalikan View baru dengan pengaturan yang dimodifikasi.

Pengubah di SwiftUI bukanlah mutasi, melainkan pembuatan pembungkus baru di sekitar View asli. Setiap pengubah mengembalikan tipe baru (ModifiedContent), memungkinkan SwiftUI membangun pohon pengubah dan menggambar ulang hanya bagian yang berubah secara efisien. Urutan penerapan pengubah penting: urutan yang berbeda memberikan hasil visual yang berbeda.

Text("Halo, SwiftUI!")
    .font(.title)        // ModifiedContent
    .padding()           // ModifiedContent<..., PaddingModifier>
    .background(.yellow) // ModifiedContent<..., BackgroundModifier>
    .cornerRadius(8)    // ModifiedContent<..., CornerRadiusModifier>

Optimasi kinerja: SwiftUI membandingkan bukan nilai konkret View, melainkan identitasnya melalui mekanisme identity (id, ForEach, identitas stabil struktur). Jika struktur View tidak berubah — body tidak dipanggil. Ini dicapai melalui perbandingan Equatable dan mekanisme PreferenceKey untuk mengirimkan data ke atas hierarki.

Untuk komposisi yang efektif, disarankan untuk membagi layar kompleks menjadi subkomponen independen, masing-masing dengan status minimalnya sendiri. Ini memungkinkan SwiftUI menggambar ulang hanya bagian hierarki yang berubah, bukan seluruh layar.