Seri SwiftUI 01｜Batasan SwiftUI yang berlaku

Saat saya pertama kali mengenal SwiftUI, pertanyaan yang paling sering diajukan adalah:

• Bisakah ini menggantikan UIKit?
• Apakah semua proyek baru harus menggunakan SwiftUI?
• Apakah proyek lama layak untuk direlokasi?

Persoalan-persoalan ini tentu saja penting, namun jika diskusi terfokus pada “penggantian” sejak awal, maka penilaian akan sering diambil secara ekstrem. Pertanyaan yang lebih praktis adalah:

Kompleksitas halaman seperti apa yang paling baik ditangani oleh SwiftUI, dan masalah seperti apa yang tidak mendominasi?

Hanya jika pertanyaan ini dijawab dengan jelas terlebih dahulu, pertanyaan “seharusnya digunakan” dan “sejauh mana” digunakan selanjutnya akan memiliki arti praktis.

1. Kekuatan sebenarnya dari SwiftUI adalah ia mengutamakan “bagaimana perubahan status dipetakan ke dalam antarmuka”

Ide default UIKit lebih seperti:

• lihat dulu
• Pergi dan perbarui tampilan lagi
• Kemudian tangani hubungan sinkronisasi antara beberapa komponen UI

Ide default SwiftUI lebih dekat dengan:

• Status yang sudah ada sebelumnya
• Kemudian jelaskan “seperti apa tampilan antarmuka dalam keadaan ini”

Ini berarti secara alami lebih cocok untuk halaman di mana “kompleksitas utama antarmuka berasal dari ekspresi keadaan”. Misalnya:

• Kosong / memuat / dimuat / kesalahan beralih ke halaman yang jelas
• halaman formulir
• Halaman pengaturan
• Menampilkan halaman detail
• Halaman tempat beberapa widget dihubungkan bersama berdasarkan serangkaian status bisnis

Tentu saja, halaman-halaman ini dapat ditulis dalam UIKit, namun banyak hubungan sinkronisasi sering kali perlu dipertahankan secara manual. Keunggulan SwiftUI justru memudahkan untuk mengekspresikan hubungan tersebut secara keseluruhan.

2. Sangat cocok untuk halaman bisnis di mana “status lebih penting daripada detail interaksi”

Kesulitan sebenarnya dengan banyak halaman bisnis adalah:

• Bagaimana statusnya saat ini?
• Apa yang akan ditampilkan di berbagai negara bagian
• Area mana yang perlu diubah bersama setelah tindakan bisnis tertentu?

Misalnya:

• Pusat pribadi
• Halaman pengaturan
• Halaman detail artikel
• Halaman hasil pencarian
• Halaman detail pesanan

Halaman seperti itu jarang memerlukan koordinasi pengguliran atau desain gerakan tingkat ekstrem, namun halaman tersebut melibatkan banyak hal:

• Peralihan status
• Tampilan bersyarat
• Kombinasi komponen
• Penyegaran sebagian

Hal-hal inilah yang paling berguna bagi SwiftUI.

3. Ini juga sangat cocok untuk halaman dengan “iterasi cepat dan perubahan UI yang sering”

Ini sangat penting dalam tim nyata.

Beberapa halaman tidak sering mengalami perubahan produk:

• Revisi copywriting
• Perubahan struktural
• Ubah urutan kartu
• Mengubah kondisi tampilan modul tertentu

Dalam skenario seperti itu, keuntungan SwiftUI seringkali bukan hanya “lebih sedikit kode”, tetapi juga beban mental yang lebih rendah dalam memodifikasi struktur UI. Lebih mudah untuk memperlakukan halaman sebagai pohon struktur yang digerakkan oleh negara untuk dimodifikasi, daripada melakukan patch bolak-balik di antara banyak tampilan parsial.

Jadi jika kenyataannya sebuah tim adalah “halaman sering berubah”, SwiftUI sering kali sangat menarik.

4. Namun SwiftUI secara alami tidak cocok untuk semua “halaman kompleks”

Ini juga merupakan hal yang paling perlu diperjelas.

Situasi yang umum terjadi adalah ketika Anda mendengar “SwiftUI lebih modern”, tanpa sadar Anda akan menyamakannya dengan “semua halaman lebih cocok”. Namun dalam proyek nyata, kompleksitas halaman yang kompleks berasal dari sumber yang berbeda.

Jika kesulitan inti suatu halaman adalah:

• Kontrol gulir yang sangat bagus
• Banyak koordinasi gerakan tingkat rendah
• Waktu animasi yang sangat dapat disesuaikan
• Kontrol yang sangat menuntut atas rendering dan detail interaksi

Maka SwiftUI mungkin tidak lebih mudah secara alami.

adalah:

• Beberapa kemampuan perlu dielakkan
• Terkadang Anda harus mencampur UIKit
• Beberapa perilaku mendasar lebih mahal untuk di-debug

Oleh karena itu, “halaman itu rumit” bukanlah kriteria itu sendiri, kuncinya adalah di mana halaman itu rumit.

5. Penilaian yang lebih praktis: Apakah kesulitan inti halaman adalah “ekspresi status” atau “kontrol yang mendasari”?

Ini adalah metode penilaian saya yang paling umum.

Jika kesulitan inti halaman adalah:

• Cara memetakan beberapa status bisnis ke antarmuka
• Cara menggabungkan komponen secara alami seiring perubahan keadaan
• Bagaimana menjaga struktur halaman tetap jelas

Maka SwiftUI seringkali cocok.

Jika kesulitan inti halaman adalah:

• Cara mengontrol interaksi mendasar secara akurat
• Cara mengoordinasikan perilaku pengguliran yang kompleks
• Cara menerapkan animasi non-standar dan perilaku tata letak

UIKit itu cenderung lebih stabil, atau setidaknya lebih “terkendali”.

Penilaian ini tidak mutlak, namun cukup praktis dalam proyek nyata. Ini dapat memandu pemilihan harian dengan lebih baik daripada pertanyaan “Dapatkah SwiftUI menggantikan UIKit?”

6. Strategi paling realistis dalam proyek lama biasanya adalah “pencampuran sesuai batasan”

Jika proyek sudah memiliki struktur UIKit yang matang, kemungkinan besar masalahnya adalah “imajinasi migrasi yang terlalu ideal”.

Dalam proyek nyata, jalur yang lebih umum dan stabil biasanya adalah:

• Gunakan SwiftUI terlebih dahulu untuk halaman baru
• Halaman UIKit yang stabil tidak dapat diubah dengan mudah
• Campur bila diperlukan
• Jangan melakukan migrasi penuh sekaligus

Karena biaya migrasi sendiri merupakan biaya bisnis. Jika peralihan kerangka kerja tidak memberikan manfaat yang jelas dan hanya bertujuan untuk “menyatukan tumpukan”, kemungkinan besar keuntungannya akan lebih besar daripada kerugiannya.

7. Kesalahpahaman umum: memperlakukan SwiftUI sebagai “versi sintaksis UIKit yang ditingkatkan”

Ketika saya pertama kali mempelajari SwiftUI ini, saya masih menanyakan pertanyaan-pertanyaan ini di benak saya:

• Apakah tampilan ini hanya dibuat satu kali?
• Kapan saya ingin menyegarkan secara manual?
• Tidak seperti UIKit yang hanya perlu mengubahnya secara langsung.

Keraguan ini wajar, tetapi jika Anda tetap pada sudut pandang ini untuk waktu yang lama, akan sulit untuk menggunakan SwiftUI dengan baik. Karena SwiftUI adalah cara yang sangat berbeda dalam mengatur antarmuka.

Hal ini membutuhkan pemikiran prioritas tentang:

• Siapa yang bertanggung jawab atas status tersebut?
• Cara memetakan status ini ke UI
• Apakah pembaruan antarmuka merupakan bagian dari aliran status?

Jika Anda masih menggunakan pemikiran UIKit, SwiftUI dapat dengan mudah menjadi “terlihat deklaratif, tetapi sebenarnya logikanya lebih membingungkan”.

8. Kesimpulan: Cocok atau tidaknya SwiftUI tidak bergantung pada baru atau tidaknya, tetapi bergantung pada sumber kompleksitas halaman.

Singkatnya, saya akan mengatakan:

SwiftUI paling cocok untuk halaman yang kompleksitas intinya sebagian besar berasal dari ekspresi status, kombinasi antarmuka, dan frekuensi iterasi; dan untuk halaman-halaman yang kompleksitasnya terutama berasal dari interaksi mendasar dan kontrol yang baik, halaman tersebut mungkin tidak dominan secara alami.

Jadi penilaian praktis sebenarnya adalah:

• Apa rumitnya halaman ini?
• Bisakah SwiftUI mencapai kompleksitas seperti ini?

Setelah pertanyaan ini terjawab dengan jelas, pemilihannya biasanya tidak terlalu membingungkan.