Seri SwiftUI 04｜Manajemen status SwiftUI: pemilihan @State, @Binding, @ObservedObject, @StateObject

Tempat yang paling mungkin membuat orang “terjebak” di SwiftUI adalah negara bagian.

Pertanyaan paling umum biasanya adalah sebagai berikut:

• Haruskah kita menggunakan @State atau @Binding untuk nilai ini?
• ViewModel akan diinisialisasi berulang kali
• Mengapa subview tidak dapat mengubah data tampilan induk?
• Nilainya jelas telah berubah, tetapi halaman tidak disegarkan seperti yang diharapkan.

Jika Anda hanya mengandalkan menghafal pembungkus atribut untuk masalah ini, Anda akan menjadi semakin bingung. Karena akar permasalahan sebenarnya biasanya adalah:

Tanpa terlebih dahulu berpikir jernih tentang “siapa pemilik negara ini?”

1. Jangan terburu-buru memilih bungkusnya. Pertanyaan pertama: Data siapa yang dimilikinya?

Ini adalah pertanyaan yang paling penting.

Di SwiftUI, setiap kali Anda melihat nilai status, tanyakan pada diri Anda:

• Apakah nilai ini dimiliki oleh Tampilan saat ini?
• Tampilan induk masih memilikinya, dan subview hanya dipinjam dan dimodifikasi.
• Masih dimiliki oleh objek luar, Tampilan saat ini hanya mengamati

Setelah pertanyaan ini terjawab dengan jelas, banyak pilihan pembungkus akan muncul secara alami. Sebaliknya, jika Anda melewatkan langkah ini dan langsung bertanya “mana yang umum digunakan dalam skenario ini”, maka akan mudah untuk menumpuk kode melalui trial and error.

2. @State sangat cocok untuk “status lokal View saat ini”

@State paling cocok untuk:

Status ini hanya dimiliki oleh Tampilan saat ini. Keberadaan lokal, konsumsi lokal, dan meninggalkan Pandangan ini pada dasarnya tidak ada artinya.

Misalnya:

• Isi kotak masukan saat ini
• Apakah akan menampilkan lembar
• Keadaan tertentu yang diperluas dan diruntuhkan sebagian
• Pilihan tab saat ini

Kesamaan yang dimiliki negara-negara bagian ini adalah:

• Kepemilikan yang jelas
• Siklus hidup sangat terikat pada Pandangan ini
• Tidak layak untuk ditingkatkan ke status bisnis eksternal

Jika suatu bagian keadaan tidak masuk akal di luar Tampilan saat ini, biasanya bagian tersebut cocok untuk @State.

3. Poin kunci dari @Binding adalah “kepemilikan tidak berubah, tetapi izin menulis telah dipinjamkan”

Situasi umum adalah memahami @Binding sebagai “subview juga dapat mengubah nilai tampilan induk”. Pemahaman ini tidaklah salah, namun kurang tepat.

Terlebih lagi:

• Keadaan ini masih milik tampilan induk
• subview tidak memilikinya
• Subview hanya mendapatkan saluran baca dan tulis

Hal ini penting karena menentukan apakah atribusi data yang benar dipertahankan ketika komponen diberi skor.

Artinya:

• @State adalah “milikku”
• @Binding “masih sama, tapi saya berwenang mengubahnya”

Setelah dipahami dalam hal kepemilikan, @Binding tidak lagi bisa disalahartikan sebagai “solusi berbagi data yang universal.”

4. @ObservedObject dan @StateObject paling mudah tertukar karena orang sering mencampurkan “observasi” dan “possession”

Penyalahgunaan paling umum dari kedua pembungkus ini pada dasarnya berasal dari masalah yang sama:

Tidak jelas apakah “Tampilan saat ini mengamati objek eksternal” atau “Tampilan saat ini membuat dan menahan objek ini secara stabil”.

@ObservedObject

Lebih baik mengungkapkan:

• Benda ini dimasukkan dari luar
• Tampilan saat ini hanya mengamatinya
• Tampilan saat ini tidak bertanggung jawab untuk membuatnya, juga tidak bertanggung jawab untuk menyimpannya secara stabil

@StateObject

Lebih baik mengungkapkan:

• Tampilan saat ini membuat objek ini sendiri
• dan ingin menahannya dengan stabil selama penyegaran Tampilan

Perbedaan mendasar keduanya bukanlah “mana yang lebih maju”, melainkan:

• siapa yang menciptakan objek tersebut
• Siapa yang bertanggung jawab atas siklus hidup objek

Hal ini juga menunjukkan bahwa banyak masalah inisialisasi berulang ViewModel pada dasarnya adalah kepemilikan objek yang salah tempat.

5. Penilaian teknik yang sangat praktis: status UI lokal dan status bisnis harus dipikirkan secara terpisah

Status banyak halaman akan membingungkan, dan status level yang berbeda akan disatukan menjadi satu bola.

Misalnya, sebuah halaman mungkin berisi:

• Isi kotak masukan
• Filter apakah jendela pop-up terbuka
• Hasil permintaan jaringan
• Status pemuatan halaman
• Daftar objek bisnis

Nilai-nilai ini tampaknya disebut “negara bagian”, tetapi keduanya bukan tipe negara yang sama.

Saya biasanya membaginya menjadi dua kategori:

1. Status UI lokal

Misalnya:

• Apakah akan memperluas
• Konten masukan saat ini
• Item yang dipilih saat ini
• Sakelar tampilan sebagian

Jenis status ini lebih dekat dengan @State / @Binding.

2. Status data bisnis

Misalnya:

• Informasi pengguna
• Daftar data
• Proses pemuatan
• Permintaan kesalahan

Jenis keadaan ini biasanya lebih baik ditempatkan di objek eksternal yang dapat diamati atau wadah keadaan tingkat yang lebih tinggi.

Setelah kedua jenis status ini tidak dibedakan, halaman akan dengan mudah memiliki nilai penerusan status lokal, status ViewModel, dan lapisan induk. Pada akhirnya, tidak jelas siapa pemiliknya.

6. Banyak masalah “nilai berubah tetapi antarmuka salah” pada dasarnya disebabkan oleh tercampurnya batas negara.

Situasi yang umum adalah:

• Saya jelas-jelas mengubah nilainya, tetapi mengapa halamannya tidak berubah seperti yang saya kira?

Ini tentu saja terkadang merupakan pembungkus yang salah, tetapi lebih sering:

• Keadaan yang seharusnya dimiliki oleh lapisan induk untuk sementara dipegang oleh lapisan anak.
• Benda-benda yang seharusnya sudah ada sejak lama diperlakukan sebagai benda pengamatan sementara.
• Status UI lokal dan status bisnis saling menimpa

Dengan kata lain, apa yang terlihat seperti “masalah penyegaran” sebenarnya adalah masalah kepemilikan.

Untuk banyak masalah status di SwiftUI, setelah Anda mencentang “siapa yang memiliki data ini”, Anda biasanya dapat menemukan akar masalahnya lebih cepat daripada menatap fenomena antarmuka.

7. Metode penilaian sederhana yang sering saya gunakan

Meskipun proyek nyata akan lebih rumit, saya sering menggunakan serangkaian penilaian sederhana ini dalam pengembangan sehari-hari:

1. Apakah ini keadaan sederhana dari Tampilan saat ini?

Ya, berikan prioritas pada @State

2. Apakah ini dimiliki oleh tampilan induk dan hanya dipinjam dan dimodifikasi oleh subtampilan saat ini?

Ya, berikan prioritas pada @Binding

3. Apakah ini objek observasi yang diteruskan dari luar?

Ya, berikan prioritas pada @ObservedObject

4. Apakah ini objek yang dibuat oleh Tampilan saat ini dan diharapkan dapat bertahan dengan stabil?

Ya, berikan prioritas pada @StateObject

Rangkaian penilaian ini tentu saja tidak mencakup semua detailnya, namun cukup praktis untuk sejumlah besar halaman bisnis.

8. Kesimpulan: Yang perlu kita pahami terlebih dahulu mengenai pengelolaan negara adalah kepemilikan.

Singkatnya, saya akan mengatakan:

Di SwiftUI, hal terpenting tentang pengelolaan status adalah menanyakan terlebih dahulu “Siapa pemilik data ini dan siapa yang bertanggung jawab untuk mengubah antarmuka dengannya.”

Setelah kepemilikannya jelas terlebih dahulu, banyak pilihan pembungkus akan muncul secara alami. Di sisi lain, jika Anda tidak berpikir jernih tentang kepemilikan dan kemudian terbiasa dengan API, akan mudah untuk menulis halaman yang “berjalan tetapi menjadi semakin berantakan”.