SwiftUI Seri 07｜Konversi pemikiran dari UIKit ke SwiftUI

Banyak pengembang UIKit beralih ke SwiftUI untuk pertama kalinya. Bagian yang paling menyakitkan tidak selalu mereka rasakan:

• API-nya jelas tidak rumit
• Tapi kenapa menulis selalu sulit?

Alasannya sering kali karena model pemikiran yang mendasarinya belum terpotong.

Karena UIKit menanyakan secara default:

• Tampilan mana yang ingin saya buat sekarang?
• Kapan saya akan memperbaruinya?
• Bagaimana caranya secara manual agar tetap konsisten dengan data

SwiftUI lebih seperti bertanya:

• Bagaimana statusnya saat ini
• Seperti apa tampilan antarmuka dalam kondisi ini?
• Bagaimana antarmuka harus diatur ulang secara alami ketika keadaan berubah

Kedua gagasan ini adalah bahwa posisi kontrol telah berubah.

1. Hal pertama yang harus ditulis adalah “Saya terutama mengandalkan driver manual saya untuk pembaruan antarmuka”

Banyak pengalaman di UIKit berkisar pada hal ini:

• Kapan harus memuat ulang
• Kapan mengaturNeedsLayout
• Callback mana yang mengubah subview tertentu?

SwiftUI tentu saja perlu mengelola status, namun yang ingin dilakukannya adalah:

• Kelola sumber status
• Kelola batas negara
• Bagaimana status manajemen dipetakan ke UI

Daripada terus fokus pada “bagaimana cara menyegarkan antarmuka secara manual?”

Jika kebiasaan ini tidak diubah, kemungkinan besar keadaan yang akan terjadi di kemudian hari adalah:

• SwiftUI sepertinya ditulis dengan gaya deklaratif
• Tapi saya masih memikirkan driver penting UIKit

Pada akhirnya, kode tersebut akan menjadi campuran dari dua jenis pemikiran, tidak memanfaatkan SwiftUI atau kehilangan kendali atas UIKit.

2. Hal kedua yang harus dilakukan adalah memperlakukan View sebagai objek yang stabil.

Ini adalah kebiasaan yang kemungkinan besar dilakukan oleh pengembang dengan latar belakang UIKit secara default.

Di UIKit, wajar jika menganggap halaman atau sel sebagai:

• objek yang dibuat
• Akan diperbarui terus menerus di masa depan

Tapi View SwiftUI lebih seperti deskripsi negara. Ini bukan “objek yang telah lama saya ubah”, tetapi lebih seperti “ekspresi struktural antarmuka dalam kondisi saat ini”.

Artinya jika Anda selalu memulai dari “Tampilan ini akan selalu ada, saya ubah terus”, maka akan mudah untuk:

• Penilaian siklus hidup
• Lokasi penyimpanan status
• Pengikatan tugas asinkron

Sering terjadi kendala dalam masalah ini.

3. Hal ketiga yang harus dilepaskan adalah ketergantungan berlebihan pada patch lokal untuk memperbaiki UI.

Jalur yang sangat umum dalam pengembangan UIKit adalah:

• Pertama-tama matikan pandangan
• Perbaiki apa pun yang salah
• Jika ada kontrol yang sedikit salah, tempelkan secara lokal.

Metode ini tidak sepenuhnya tidak dapat digunakan di SwiftUI, tetapi jika Anda terus melakukan ini, halaman akan dengan mudah menjadi:

• Ada banyak pengubah
• Hierarki struktural yang tidak jelas
• Satu perbaikan kecil menyebabkan perubahan tata letak lainnya

Karena SwiftUI menganjurkan untuk mengekspresikan struktur dengan jelas terlebih dahulu, lalu melampirkan modifikasi lokal padanya. Jika strukturnya sendiri tidak stabil, perbaikan lokal akan memperbaiki masalah tersebut dan memecahnya menjadi beberapa bagian.

4. Hal keempat yang harus diubah adalah: kurangi berpikir tentang “kontrol” dan lebih banyak berpikir tentang “aliran keadaan”

Dalam pemikiran UIKit, banyak organisasi halaman yang berpusat pada kontrol:

-Apa yang ditunjukkan label ini?

• Apakah tombol ini dinonaktifkan
• Kapan tableView ini dimuat ulang?

SwiftUI mendorong mulai dari aliran status:

• Bagaimana status halaman saat ini?
• Fragmen UI mana yang harus dipetakan ke status ini
• Bagaimana keadaan berkembang setelah suatu tindakan

Perubahan ini penting karena berdampak langsung pada:

• Bagaimana mendesain ViewModel
• Cara membongkar komponen
• Cara menentukan status mana yang boleh dibagikan dan mana yang tidak boleh dibagikan

5. Hal kelima yang harus diubah adalah: jangan terburu-buru menerjemahkan semua pengalaman UIKit ke dalam metode penulisan yang sesuai dengan SwiftUI

Saat pertama kali mempelajari konten tentang SwiftUI ini, tanpa sadar saya menanyakan pertanyaan ini:

• Apa yang setara dengan ini di UIKit?
• Panggilan balik mana yang sesuai dengan siklus hidup ini
• Apakah perilaku ini setara dengan reloadData?

Jenis pemetaan ini berguna saat memulai, namun dapat menimbulkan masalah jika diandalkan dalam jangka panjang:

• Selalu mencari rekanan UIKit
• Namun saya tidak terlalu menerima bahwa SwiftUI adalah cara pengorganisasian yang lain

Titik balik yang sangat mudah digunakan biasanya:

Saya mulai memikirkan halaman secara langsung dalam kesadaran masalah SwiftUI, daripada menerjemahkan kembali ke UIKit terlebih dahulu dan kemudian membuat keputusan.

6. Metode transisi yang lebih praktis: Jangan mengejar “perubahan otak total segera”, ubah dulu cara Anda mengajukan beberapa pertanyaan berfrekuensi tinggi.

Hal yang paling bermanfaat adalah mengubah cara Anda menanyakan pertanyaan-pertanyaan ini terlebih dahulu:

Letakkan:

• Kapan saya menyegarkan tampilan ini?

Ubah menjadi:

• Perubahan negara bagian apa yang harus mendorong pembaruan area ini

Letakkan:

• Kapan kontrol ini harus diubah?

Ubah menjadi:

• Siapa yang seharusnya memiliki nilai ini?

Letakkan:

• Apakah halaman ini muncul sekali atau beberapa kali?

Ubah menjadi:

• Pada kondisi atau siklus hidup apa tugas ini harus terikat?

Perubahan dalam cara bertanya ini mungkin tampak kecil, tetapi perlahan-lahan akan menarik pemikiran default ke arah SwiftUI.

7. Kesimpulan: Hal terpenting saat berpindah dari UIKit ke SwiftUI adalah memposisikan ulang pemikiran tentang kontrol.

Singkatnya, saya akan mengatakan:

Dari UIKit ke SwiftUI, yang benar-benar perlu diubah adalah dari “Saya akan mengarahkan antarmuka secara manual” menjadi “Saya akan menentukan negara bagian dan batas-batasnya, dan membiarkan antarmuka dibuat sesuai dengan negara bagian.”

Saat hal ini mulai terjadi, banyak hal yang awalnya terasa seperti “Mengapa SwiftUI begitu canggung?” perlahan akan menjadi alami.