Pop & Mengirim Data Balik

Kenapa Butuh Data Balik?

Bayangkan halaman pemilih: pilih alamat pengiriman, pilih warna tema, pilih foto dari galeri. User memilih sesuatu, lalu kembali ke halaman sebelumnya. Tanpa mekanisme data balik, kamu harus menyimpan pilihan di variabel global atau memakai state management yang berat untuk hal sepele. Navigator.pop dengan argumen kedua menyelesaikan ini secara elegan: route yang di-push mengembalikan Future, dan nilai yang kamu pop menjadi hasil dari Future tersebut. Ini pola "picker" yang dipakai hampir semua aplikasi, dan ia bekerja tanpa library tambahan apa pun.

Mengirim Data Saat Pop

Di halaman pemilih, cukup tambahkan argumen kedua pada pop:

// di halaman pilih menu:
ElevatedButton(
  onPressed: () => Navigator.pop(context, 'Kopi Susu'),
  child: const Text('Kopi Susu'),
)

Nilai kedua bisa bertipe apa pun: String, int, enum, bahkan object model. Tidak ada batasan khusus, yang penting halaman pemanggil tahu cara membacanya.

Menerima dengan await

Karena Navigator.push mengembalikan Future, halaman pemanggil bisa menunggu hasilnya:

ElevatedButton(
  onPressed: () async {
    final hasil = await Navigator.push<String>(
      context,
      MaterialPageRoute(builder: (context) => const HalamanPilihMenu()),
    );
    if (hasil != null) {
      setState(() => pilihanMenu = hasil);
    }
  },
  child: const Text('Pilih Menu'),
)

Catatan teknis: Navigator.push<String> memberi tipe generic sehingga hasil langsung bertipe String? tanpa cast manual. Ini lebih aman daripada hasil as String yang bisa throw kalau tipenya meleset.

Contoh yang lebih nyata: form tambah alamat yang mengembalikan object, bukan String.

onPressed: () async {
  final alamatBaru = await Navigator.push<Alamat>(
    context,
    MaterialPageRoute(builder: (_) => const FormAlamat()),
  );
  if (alamatBaru != null && context.mounted) {
    setState(() => daftarAlamat.add(alamatBaru));
  }
}

Catatan teknis: Setelah await, widget bisa saja sudah di-dispose (misalnya user sempat pindah halaman lain). Cek context.mounted sebelum setState untuk menghindari error "setState called after dispose".

Edge Cases & Best Practices

• User menekan tombol back bawaan: tidak ada data yang di-pop, jadi hasilnya null. Selalu cek null sebelum dipakai, jangan langsung pakai !.
• Butuh beberapa nilai balik: bungkus dalam class kecil atau Map. Jangan pop dua kali beruntun, karena pop kedua akan menutup halaman di bawahnya.
• Dialog juga bisa: showDialog mengembalikan Future<T?> dengan pola yang sama, cocok untuk dialog konfirmasi ya atau tidak.
• Jangan lupa async: fungsi onPressed harus async agar bisa memakai await di dalamnya.
• Batalkan dengan jelas: kalau halaman pemilih punya tombol Batal, panggil Navigator.pop(context) tanpa argumen agar hasilnya null dan konsisten dengan tombol back.

Kapan Jangan Pakai Cara Ini

Pola pop-data hanya cocok untuk hubungan satu ke satu: satu halaman meminta, satu halaman menjawab. Kalau datanya dibutuhkan banyak halaman (data user yang login, isi keranjang belanja), pakai state management (Provider, Riverpod) atau teruskan lewat constructor saat push. Pop-data juga tidak cocok untuk alur multi-langkah seperti wizard lima halaman, karena rantai await yang panjang menjadi rapuh dan sulit di-debug ketika satu langkah di tengah berubah.