Pola State Management yang Saya Pakai di Semua Proyek Flutter

Pertanyaan arsitektur pertama di setiap proyek Flutter: "pakai state management apa?". Jawaban saya setelah belasan proyek: konsisten lebih penting daripada "terbaik". Pola yang sama di semua proyek membuat kode bisa dibaca siapa pun — termasuk Anda, enam bulan setelah serah terima.

Aturan dasar saya

1. State lokal UI tetap di widget — setState untuk animasi, toggle, form field. Tidak semua state perlu solusi global.
2. State aplikasi di satu tempat — data yang hidup lintas layar (sesi user, keranjang, cache) dikelola solusi state management.
3. Tidak ada logika bisnis di widget — widget memanggil use case, use case yang mengubah state.

Riverpod untuk mayoritas proyek

Riverpod pas untuk aplikasi menengah: compile-safe, mudah di-test, dan tidak butuh context. Pola yang saya pakai:

• Notifier per fitur untuk state yang berubah
• FutureProvider untuk data yang di-fetch sekali
• ref.watch di UI, ref.read di event handler

Keunggulan praktisnya: dependency antar provider eksplisit, jadi alur data mudah dilacak saat debugging.

Bloc untuk alur yang kompleks dan berurutan

Bloc saya pilih ketika alurnya benar-benar proses — misalnya alur checkout multi-langkah dengan validasi per tahap, atau integrasi payment dengan status yang harus eksplisit. Event → state yang dipaksa Bloc membuat alur seperti ini terdokumentasi sendiri di kode.

Di CHAS — aplikasi transportasi alat berat, mayoritas state UI cukup ditangani StatefulWidget; state lintas layar (sesi login, status absensi) yang masuk ke solusi global.

Struktur folder yang terbukti

lib/
  core/          # konstanta, util, error, theme
  data/          # model, repository, sumber data
  domain/        # use case, entitas
  features/
    kasir/
      presentation/  # screen, widget, controller
      application/   # state (notifier/bloc)
  main.dart

Prinsipnya: fitur berdampingan, bukan berlapis per teknologi. Menambah fitur baru = menambah folder, bukan menyentuh lima file lintas lapisan.

Kesalahan yang sering saya temukan

• Provider raksasa — satu notifier memegang state seluruh aplikasi. Pecah per fitur.
• Rebuild berlebihan — ref.watch di widget yang seharusnya hanya butuh sekali baca.
• State yang bisa dihitung disimpan — kalau nilai bisa diturunkan dari state lain, jangan simpan; hitung.

Penutup

State management bukan soal framework favorit — soal disiplin pola. Pilih satu, tulis aturannya di README proyek, dan patuhi. Aplikasi Anda enam bulan kemudian akan berterima kasih.

Sedang merencanakan aplikasi Flutter? Layanan mobile app saya mencakup arsitektur sejak hari pertama — atau konsultasi dulu, gratis.