Seri SwiftUI 06｜Pemisahan komponen SwiftUI dan pemeliharaan kode

Ketika topik “pembongkaran komponen” muncul, reaksi pertama adalah:

• Tampilan ini terlalu panjang
• Bagi menjadi beberapa sub-Tampilan

Ini tentu saja merupakan permulaan, tetapi jika kriteria pemisahan hanya “terlalu banyak baris kode”, maka akan mudah untuk berakhir dengan kebingungan lain:

• Memang ada lebih banyak file
• Tapi hubungan status lebih sulit untuk dipahami
• Nama komponen menjadi semakin abstrak
• Berikan banyak parameter antara ayah dan anak

Dengan kata lain halamannya tidak lebih jelas, hanya berubah dari satu file besar menjadi banyak file rusak.

Jadi pemisahan komponen yang benar-benar efektif adalah:

Membuat batasan struktur, menyatakan batasan, dan menggunakan kembali batasan secara lebih jelas pada saat yang bersamaan.

1. Pertama-tama bedakan: apakah strukturnya dibongkar atau digunakan kembali?

Adalah biasa jika kedua hal ini tercampur aduk.

1. Pisahkan agar strukturnya mudah dibaca

Tujuannya adalah untuk memperjelas hierarki halaman saat ini. Jenis pemisahan ini sepenuhnya masuk akal meskipun hanya digunakan sekali pada satu halaman.

2. Pisahkan untuk digunakan kembali lintas halaman

Tujuannya adalah untuk mengekstrak komponen yang dapat digunakan kembali. Jenis pemisahan ini memerlukan batasan yang lebih stabil dan antarmuka yang lebih terkendali.

Jika kedua jenis tujuan ini tidak dibedakan, akibat yang paling umum adalah:

• Jelas saya hanya ingin membuat halaman lebih jelas, tetapi akhirnya mengekstraknya sebelum waktunya sebagai “komponen universal”
• Atau pola ini sudah berulang berkali-kali, namun masih dianggap sebagai sub-pandangan parsial

Oleh karena itu, langkah pertama dalam pemisahan komponen adalah menentukan jenis masalah apa yang sedang dipecahkan.

2. Alasan mengapa banyak halaman menjadi semakin berantakan adalah karena View mengambil terlalu banyak peran.

Setelah halaman melakukan hal-hal ini pada saat yang sama, halaman akan mudah diperluas dengan cepat:

• struktur tata letak
• Status UI lokal -Pemetaan status bisnis
• Pemformatan data
• Perakitan aksi interaktif

Saat ini, Anda akan menemukan bahwa kode panjang bukanlah penyebab utama. Masalah sebenarnya adalah:

• Logika apa yang dimiliki View
• Logika apa yang seharusnya ada di luar
• Struktur lokal mana yang layak mendapatkan ekspresi independen

Nilai sebenarnya dari pemisahan komponen adalah untuk memaksa penilaian batas ini dilakukan lagi.

3. Yang paling layak untuk dihapus terlebih dahulu biasanya adalah “bagian dengan semantik terlengkap di halaman saat ini”

Situasi yang umum terjadi adalah segera setelah komponen dibongkar, mereka bergegas mencari bagian yang paling serbaguna. Namun dalam perkembangan nyata, pendekatan yang lebih stabil sering kali adalah dengan terlebih dahulu membongkar bagian-bagian yang secara semantik lengkap di halaman saat ini.

Misalnya:

• Area tajuk data
• Kartu ringkasan artikel
• Atur baris item
• Blok kosong

Keuntungan dari struktur ini adalah:

• Mereka awalnya merupakan unit independen di halaman
• Semantik struktural akan menjadi lebih jelas setelah dihilangkan
• Meskipun Anda tidak menggunakannya kembali untuk sementara waktu, Anda tidak akan kehilangan uang

Ini jauh lebih stabil daripada mencoba mengeluarkan “Wadah Sel Super Universal” dari awal.

4. Setelah komponen dihapus, antarmuka menjadi masalah desain yang nyata

Salah satu manfaat terbesar dari pemisahan komponen adalah memaksa Anda memikirkan tentang antarmuka.

Anda akan segera mengetahui:

• Haruskah subkomponen ini mengambil model asli atau data tampilan yang diformat?
• Perlu mengetahui cara melompat setelah mengklik, atau hanya mengekspos satu tindakan
• Apakah harus memiliki negara bagian lokal, atau digerakkan oleh lapisan induk

Jika Anda tidak ingin memahami masalah ini dengan jelas, komponennya dapat dengan mudah menjadi:

• Banyak parameter
• Semantik bisnis yang tidak jelas
• Lapisan induk perlu mengetahui segalanya

Jadi pemisahan komponen adalah pekerjaan desain antarmuka.

5. Bau busuk yang sangat umum: mencampurkan “pemisahan struktur parsial” dan “pemisahan logika bisnis” menjadi satu

Misalnya, jika kartu daftar dihilangkan, ia juga bertanggung jawab untuk:

• Tampilan tata letak
• Pemformatan data
• kubur intinya
• Penilaian bisnis setelah klik

Meskipun komponen ini bersifat independen, namun tanggung jawabnya masih beragam.

Pendekatan yang lebih stabil biasanya:

• Komponen tampilan harus fokus pada tampilan sebanyak mungkin
• Sebisa mungkin pertahankan keputusan bisnis pada tingkat yang lebih tinggi
• Subkomponen memaparkan kejadian-kejadian penting tanpa secara langsung menelan seluruh proses bisnis

Jika tidak, semakin banyak komponen yang dibongkar, logikanya akan semakin terfragmentasi, namun kompleksitasnya tidak akan berkurang.

6. Kapan sebaiknya Anda tidak terburu-buru merokok “komponen umum”?

Ini adalah titik di mana banyak proyek SwiftUI dapat dengan mudah dirancang secara berlebihan.

Jika suatu pola saat ini hanya muncul sekali pada suatu halaman, dan:

• Struktur bisnis belum stabil
• Detail UI masih berubah dengan cepat
• Saya belum yakin tentang batasannya

Saat ini, lebih tepat untuk membaginya menjadi sub-Tampilan lokal di dalam halaman daripada segera memutakhirkannya ke komponen umum.

Karena “penggunaan kembali secara prematur” sering kali membawa satu konsekuensi:

• Antarmuka komponen menjadi sangat luas
• Agar kompatibel dengan kemungkinan skenario masa depan, banyak opsi disertakan terlebih dahulu

Akibatnya pemeliharaannya lebih sulit dibandingkan tidak dibongkar.

7. Penilaian praktis: Jika substruktur ini dihilangkan sendiri, dapatkah orang lain mengetahui apa itu?

Ini adalah cara yang sangat umum bagi saya untuk menilai.

Jika substruktur tertentu dihilangkan, semua orang secara alami dapat berkata:

• Ini adalah header profil pengguna
• Ini adalah baris pengaturan
• Ini adalah kartu ringkasan artikel

Maka biasanya cocok untuk dibongkar.

Jika Anda mengeluarkannya, Anda hanya bisa mengatakan:

• Ini adalah “wadah kombinasi”
• Ini adalah “Tampilan Blok Konten”
• Ini adalah “kotak kartu multi-adegan”

Hal ini kemungkinan besar berarti semantiknya tidak cukup stabil, dan waktu untuk pemisahan mungkin belum tiba.

8. Kesimpulan : Yang sebenarnya diupayakan dari pemisahan komponen adalah memiliki batasan yang lebih jelas.

Singkatnya, saya akan mengatakan:

Standar yang benar-benar efektif untuk memisahkan komponen SwiftUI adalah setelah pemisahan, batas struktur, batas negara bagian, dan batas antarmuka menjadi lebih jelas dari sebelumnya.

Hanya dengan cara ini, komponen akan menjadi lebih ringan saat dibongkar; jika tidak, file akan menjadi lebih banyak dan sistem akan lebih sulit dibaca.