@ObservedObject: apa itu, mengamati objek dan memperbarui View

Apa itu @ObservedObject di SwiftUI

@ObservedObject adalah property wrapper yang melanggankan View ke perubahan ObservableObject. Ketika objek yang ditandai dengan @ObservedObject mengubah salah satu propertinya yang dideklarasikan dengan @Published, SwiftUI secara otomatis menggambar ulang View. @ObservedObject tidak membuat objek — ia hanya membuat koneksi antara instance ObservableObject yang sudah ada dan View yang harus bereaksi terhadap perubahannya.

Perbedaan utama antara @ObservedObject dan @StateObject — adalah kepemilikan. @ObservedObject mengasumsikan bahwa objek telah dibuat dan disimpan di suatu tempat yang lebih tinggi dalam hierarki View. View anak menerima referensi ke objek ini melalui inisialisator dan hanya mengamatinya. Jika View anak dibuat ulang, ia akan menerima referensi yang sama dari induk — data tidak akan hilang.

Menurut Apple Developer Documentation — SwiftUI (2025), @ObservedObject tersedia mulai iOS 13, yang menjadikannya satu-satunya opsi untuk mengamati ObservableObject di proyek yang mendukung versi iOS lama. Di iOS 14+ @StateObject lebih disukai untuk membuat objek, tetapi @ObservedObject tetap relevan untuk meneruskan objek yang sudah ada.

Bagaimana @ObservedObject bekerja

Mekanisme @ObservedObject didasarkan pada protokol ObservableObject dari framework Combine. Setiap kelas yang sesuai dengan ObservableObject secara otomatis mendapatkan publisher objectWillChange yang mengirim sinyal sebelum perubahan properti @Published. SwiftUI berlangganan publisher ini melalui @ObservedObject dan setelah menerima sinyal, menandai View sebagai perlu digambar ulang.

class TaskViewModel: ObservableObject {
    @Published var tasks: [Task] = []
    @Published var isLoading = false
    
    func loadTasks() async {
        isLoading = true
        // ambil data
        isLoading = false
    }
}

struct TaskListView: View {
    @ObservedObject var viewModel: TaskViewModel
    
    var body: some View {
        List(viewModel.tasks) { task in
            Text(task.title)
        }
        .task { await viewModel.loadTasks() }
    }
}

Ketika View induk meneruskan viewModel ke TaskListView melalui inisialisator, SwiftUI membuat koneksi antara objek dan View. Saat array tasks atau flag isLoading berubah, SwiftUI menggambar ulang TaskListView. Objek tetap tidak berubah — ia disimpan di View induk melalui @StateObject.

@ObservedObject vs @StateObject: kapan menggunakan apa

Perbedaan antara @ObservedObject dan @StateObject — adalah perbedaan antara pengamat dan pemilik. @StateObject membuat objek dan mengelola siklus hidupnya. @ObservedObject hanya mengamati objek yang telah dibuat dan disimpan di tempat lain. Pilihan di antara mereka ditentukan oleh tanggung jawab View atas data.

Aturan utama: jika View membuat objek — @StateObject. Jika View menerima objek — @ObservedObject. Pelanggaran aturan ini ke arah @ObservedObject untuk membuat objek menyebabkan kehilangan data saat View dibangun ulang. Pelanggaran ke arah @StateObject untuk menerima objek membuat instance duplikat, independen dari induk.

Contoh penggunaan @ObservedObject

Skenario tipikal penggunaan @ObservedObject — daftar tugas, di mana View akar membuat view model, dan sel daftar menerimanya melalui @ObservedObject. Setiap sel dapat memanggil metode view model, dan perubahan secara otomatis ditampilkan di seluruh daftar, karena semua sel mengamati objek yang sama.

struct TaskRow: View {
    @ObservedObject var viewModel: TaskViewModel
    let task: Task
    
    var body: some View {
        HStack {
            Text(task.title)
            Spacer()
            Button("Selesai") {
                viewModel.completeTask(task)
            }
        }
    }
}

struct TaskListContainer: View {
    @StateObject var viewModel = TaskViewModel()
    
    var body: some View {
        List(viewModel.tasks) { task in
            TaskRow(viewModel: viewModel, task: task)
        }
    }
}

Dalam contoh ini TaskListContainer membuat viewModel melalui @StateObject, dan setiap TaskRow menerimanya melalui @ObservedObject. Ketika pengguna mengklik “Done” di baris mana pun, viewModel.completeTask mengubah properti published, dan semua View yang mengamati objek ini diperbarui secara otomatis.

Kesalahan umum dengan @ObservedObject

Kesalahan paling umum — menggunakan @ObservedObject untuk membuat objek di dalam View. Ketika View dibangun ulang (misalnya, saat state berubah), SwiftUI membuat instance ObservableObject baru, yang menyebabkan hilangnya semua data yang terkumpul. Kesalahan ini sangat menyakitkan di NavigationStack, di mana pengguna dapat mengisi formulir dan kehilangan data saat kembali.

Kesalahan: @ObservedObject bukannya @StateObject

// ❌ Kehilangan data: @ObservedObject tidak menyimpan objek
struct FormView: View {
    @ObservedObject var formVM = FormViewModel()
    // FormVM baru dibuat setiap View dibangun ulang!
}

// ✅ Benar: @StateObject menyimpan objek
struct FormView: View {
    @StateObject var formVM = FormViewModel()
    // Objek dibuat sekali selama umur View
}

Kesalahan: meneruskan @StateObject di mana @ObservedObject diperlukan

Jika View anak mendeklarasikan ObservableObject yang sama melalui @StateObject, ia membuat salinan independen. Perubahan pada objek induk tidak akan terlihat di anak dan sebaliknya. Selalu gunakan @ObservedObject untuk View anak yang menerima objek dari luar.

Alternatif @ObservedObject di SwiftUI

Di SwiftUI modern, ada beberapa alternatif untuk @ObservedObject, masing-masing dengan kelebihannya sendiri. Pilihan tergantung pada arsitektur aplikasi, versi iOS, dan skenario penggunaan spesifik.

• @EnvironmentObject — memungkinkan mendapatkan objek dari lingkungan SwiftUI tanpa penerusan eksplisit melalui inisialisator. Nyaman untuk objek yang dibutuhkan di banyak layar, tetapi memerlukan injeksi eksplisit melalui .environmentObject().
• @State + @Binding — untuk tipe nilai sederhana tidak diperlukan ObservableObject. Gunakan @State untuk penyimpanan dan @Binding untuk penerusan ke View anak.
• @AppStorage — untuk nilai UserDefaults yang harus disinkronkan secara otomatis dengan View.
• @SceneStorage — untuk menyimpan status sementara antara restart scene (misalnya, posisi dalam daftar).

Pilihan antara @ObservedObject dan @EnvironmentObject — adalah masalah gaya dan arsitektur. @ObservedObject secara eksplisit menunjukkan ketergantungan View melalui inisialisator, yang membuat kode lebih dapat diprediksi. @EnvironmentObject nyaman untuk hierarki yang dalam, tetapi menyembunyikan ketergantungan, yang dapat mempersulit debugging.