SwiftUI Seri 05｜Penggunaan NavigationStack dan lompatan halaman yang benar

Saat Anda menggunakan NavigationStack untuk pertama kalinya, Anda akan mengira itu adalah versi wadah navigasi SwiftUI:

• Klik
• dorong satu halaman
• Cukup banyak

Namun dalam proyek nyata, bagian navigasi yang paling menyusahkan selalu:

• Halaman akan melompat
• Apakah status lompatan dan status bisnis konsisten
• Apakah jalur masih tetap benar saat melakukan deep linking, kembali, dan masuk kembali ke halaman

Dengan kata lain, apa yang sebenarnya harus dihadapi NavigationStack bukan hanya peralihan antarmuka, tetapi keadaan navigasi itu sendiri.

1. Masalah navigasi pada banyak proyek di masa lalu pada dasarnya berasal dari “aksi lompat yang tersebar di mana-mana”

Di era UIKit, cara penulisan yang sangat umum adalah:

• Tekan langsung tombol
• Hadir langsung dalam panggilan balik
• Saat ViewModel memanggil kembali, ia melompati delegasi

Tentu saja ini akan berhasil dalam jangka pendek, tetapi masalahnya logika navigasi akan semakin tersebar. Sulit untuk dijawab:

• Mengapa kamu ada di halaman ini?
• Ke negara bagian mana Anda harus kembali setelah kembali?
• Setelah bisnis tertentu selesai, bisnis tersebut akan melompat ke dua level.

NavigationStack SwiftUI memberikan peluang yang lebih baik: Ubah “jalur navigasi saat ini” dari tindakan implisit menjadi keadaan eksplisit.

2. Hal terpenting tentang NavigationStack adalah jalurnya

Saat pertama kali mempelajari konten NavigationStack ini, saya hanya menatap:

• NavigationLink
• navigationDestination

Tentu saja hal-hal tersebut perlu Anda ketahui, namun yang sebenarnya harus dipahami terlebih dahulu adalah:

Navigasi dapat dinyatakan sebagai jalur status di SwiftUI.

Ini berarti tidak lagi sekadar “melompat saat diklik”, namun mempertahankan:

• Halaman apa yang ada di jalur saat ini?
• Status bisnis mana yang sesuai dengan tujuannya
• Bagaimana jalurnya berubah setelah operasi tertentu?

Jika dilihat dari perspektif ini, navigasi tidak lagi sekadar peristiwa UI dan mulai menjadi bagian dari alur keadaan.

3. Banyak navigasi yang kacau karena status bisnis dan status perutean tidak selaras.

Untuk memberikan contoh yang sangat umum:

• Pengguna memilih artikel
• Halaman detail artikel akan muncul
• Bagaimana cara keluar dari halaman detail setelah menghapus artikel?

Jika Anda hanya memahami navigasi sebagai “klik untuk masuk”, maka banyak pertanyaan selanjutnya akan mulai membingungkan:

• Cara memulihkan jalur ketika tautan dalam masuk
• Cara menyesuaikan jalur setelah kegagalan data
• Di negara bagian mana daftar tersebut harus tetap berada saat dikembalikan

Jadi hal yang paling sulit mengenai navigasi adalah bahwa navigasi tidak boleh ada secara independen dari kondisi bisnis.

Ide yang lebih stabil adalah:

• Jalur navigasi dan status bisnis dapat ditafsirkan satu sama lain
• Mengapa Anda saat ini berada di halaman ini dapat dijelaskan dengan jelas dari statusnya.

4. NavigationLink sangat nyaman, tetapi karena proyeknya rumit, Anda tidak dapat mengandalkannya untuk mengekspresikan semua navigasi

NavigationLink sangat cocok untuk lompatan langsung, parsial, dan sederhana, seperti:

• Klik pada daftar untuk detailnya
• Tetapkan pengaturan umpan halaman

Namun jika proyeknya rumit, jika semua navigasi mengandalkan NavigationLink yang tersebar, Anda akan segera menjumpai:

• Jalur sulit dikelola secara seragam
• Tautan dalam sulit diakses
• Lompatan proses tertentu tidak lagi sekadar didorong oleh klik.
• Jalur kembali terputus dari status bisnis

Inilah sebabnya mengapa lebih cocok untuk menghadapi pintu masuk lokal dan tidak cocok untuk menjalankan strategi navigasi seluruh aplikasi saja.

5. Ide yang lebih praktis: rancang “halaman tujuan” sebagai nilai yang dapat dijelaskan oleh bisnis

Salah satu akar penyebab banyak kecelakaan navigasi proyek adalah:

• Lompatan hanya ditulis sebagai sekumpulan tindakan UI
• Tidak ada model tujuan yang masuk akal yang terbentuk

Metode yang lebih stabil biasanya membiarkan jalur tersebut membawa “tujuan mana yang ingin dituju oleh bisnis saat ini”.

Misalnya:

• artikelDetail(id: String)
• Profil pengguna(id: String)
• pengaturan

Dengan cara ini navigasi lebih terasa seperti keadaan dibandingkan kumpulan tindakan yang terputus-putus. Manfaatnya adalah:

• Jalur dapat direkonstruksi
• Tautan dalam lebih alami
• Pengujian dan debugging juga lebih mudah dijelaskan

6. Bau busuk yang paling umum dalam proyek nyata: Tindakan Tampilan, TampilanModel, dan perutean saling terkait satu sama lain

Banyak kode navigasi SwiftUI yang terlihat seperti ini:

• Tulis bagian NavigationLink di View
• ViewModel diam-diam memutuskan untuk melompat lagi
• Panggilan balik layanan tertentu memicu perubahan status navigasi

Pada akhirnya tidak ada yang tahu dengan jelas:

• Siapa pemilik navigasi sebenarnya
• Negara bagian mana yang menentukan jalur saat ini
• Apakah tindakan pengembalian tertentu merupakan perilaku pengguna atau perilaku bisnis?

Setelah navigasi memasuki keadaan ini, biaya penambahan tautan dalam atau penambahan jalur pemulihan akan meningkat secara signifikan.

7. Penilaian praktis: Apakah halaman saat ini “karena saya mengklik” atau “karena status menentukan bahwa halaman tersebut seharusnya ada di sini”

Ini adalah sesuatu yang sering saya tanyakan pada diri saya sendiri.

Jika ada halaman yang muncul, itu hanya dapat diartikan sebagai:

• Karena aku baru saja mengklik tombol

Itu biasanya berarti navigasinya masih terlalu didorong oleh tindakan.

Penjelasan yang lebih ideal adalah:

• karena status jalur saat ini memuatnya
• karena konteks bisnis saat ini mengharuskannya ditampilkan

Perbedaan ini penting. Yang pertama lebih seperti tindakan sementara, yang terakhir lebih seperti kondisi navigasi yang dapat dipertahankan.

8. Kesimpulan: Apa yang NavigationStack benar-benar memungkinkan untuk dikelola bukan hanya lompatan, tetapi status jalur.

Singkatnya, saya akan mengatakan:

NavigationStack Yang paling penting adalah memungkinkan navigasi ditutup secara lebih alami dari “tindakan klik tersebar” ke “status jalur yang dapat dikelola”.

Oleh karena itu, cara yang benar untuk membuka lompatan halaman bukan hanya dengan menulis NavigationLink, tetapi memungkinkan status navigasi dan status bisnis saling menjelaskan. Hanya dengan cara ini, navigasi tidak akan menjadi semakin membingungkan karena proyek menjadi semakin kompleks.