Tanyakan ke lima developer Flutter library state management mana yang harus dipakai, dan Anda akan mendapat lima jawaban, sering kali dengan perasaan yang menggebu-gebu. Perdebatan itu menutupi fakta yang lebih sederhana. Library-nya tidak sepenting di mana logika diletakkan dan bagaimana data mengalir di aplikasi. Meski begitu, pilihan ini tetap memengaruhi cara testing, kecepatan developer baru beradaptasi, dan banyaknya kode boilerplate. Berikut perbandingan pilihan utamanya dan cara kami memilih di proyek klien.
Masalah Apa yang Sedang Diselesaikan?
Flutter membangun ulang widget berdasarkan state. Sebagian state hanya milik satu widget, misalnya dropdown sedang terbuka atau isi sebuah text field. State lain dipakai bersama di banyak layar, seperti data user yang login, keranjang belanja, atau daftar yang dimuat dari API. State sementara cukup disimpan di StatefulWidget dengan setState. State aplikasi butuh tempat di luar widget tree supaya bisa dibaca beberapa layar, tetap ada saat berpindah halaman, dan logika bisnisnya bisa dites tanpa membangun widget.
Pilihan Utama
| Pilihan | Cara kerja | Kelebihan | Kekurangan |
|---|---|---|---|
| setState | State disimpan di StatefulWidget dan widget membangun ulang dirinya sendiri | Bawaan Flutter, tidak ada yang perlu dipelajari | Tidak cocok untuk state bersama, dan logika jadi bercampur dengan kode UI |
| Provider dengan ChangeNotifier | Sebuah class menyimpan state dan memanggil notifyListeners, lalu widget mendengarkan lewat widget tree | API-nya kecil, dipakai di dokumentasi resmi Flutter, mudah untuk pemula | Bergantung pada BuildContext, dan error baru muncul saat runtime kalau provider tidak ditemukan |
| Riverpod | Provider dideklarasikan secara global dan dibaca lewat ref, dengan dukungan bawaan untuk data async | Aman sejak compile time, testing mudah dengan override, penanganan state loading dan error yang rapi | Konsepnya lebih banyak, dan API-nya beberapa kali berubah antar versi mayor |
| Bloc atau Cubit | UI mengirim event atau memanggil method, lalu bloc mengeluarkan state baru yang immutable | Sangat mudah ditebak, pemisahan yang jelas, tooling dan library testing yang kuat | File dan boilerplate lebih banyak, terasa berat untuk aplikasi kecil |
Masih ada library lain seperti GetX dan MobX yang juga punya penggemar. Untuk aplikasi bisnis yang akan dipakai bertahun-tahun, kami tetap memakai pilihan di atas karena komunitasnya besar, dokumentasinya jelas, dan polanya sudah dikenal sebagian besar developer Flutter yang akan Anda rekrut.
Cara Kami Memilih
- Aplikasi kecil atau tim yang baru mengenal Flutter: Provider dengan ChangeNotifier. Pendekatannya mengikuti panduan arsitektur resmi Flutter dan mudah dijelaskan.
- Sebagian besar aplikasi bisnis baru yang banyak mengambil data dari API: Riverpod. AsyncValue membuat state loading, error, dan data jadi eksplisit, dan override membuat test jadi singkat.
- Tim besar, industri yang diatur ketat, atau aplikasi dengan alur rumit seperti pembayaran: Bloc. Model event ke state yang ketat membuat perilaku aplikasi mudah ditelusuri dan di-review.
- Codebase yang sudah berjalan: pertahankan yang sudah dipakai, kecuali memang menimbulkan masalah nyata. Mencampur tiga library di satu aplikasi lebih buruk daripada pilihan mana pun.
Struktur Lebih Penting daripada Library
- 1Letakkan pemanggilan API dan penyimpanan lokal di class repository. Widget dan class state tidak pernah memanggil http atau database secara langsung.
- 2Simpan aturan bisnis di lapisan state, seperti Notifier, Cubit, atau ChangeNotifier, supaya bisa di-unit test tanpa widget.
- 3Buat objek state immutable dan buat salinan baru setiap kali berubah. Package seperti freezed mengurangi boilerplate-nya.
- 4Modelkan state loading, berhasil, kosong, dan error secara eksplisit supaya setiap layar menangani semuanya.
- 5Inject repository supaya test bisa menggantinya dengan versi palsu.
- 6Kelompokkan kode per fitur, seperti auth, orders, dan profile, supaya satu fitur bisa dipahami dari satu folder saja.
Tips Performa
- Dengarkan hanya bagian state yang dibutuhkan widget, dengan select di Provider dan Riverpod atau buildWhen di Bloc, supaya tidak seluruh layar dibangun ulang.
- Turunkan posisi widget yang membaca state ke bagian bawah tree, supaya yang dibangun ulang cukup widget kecilnya saja.
- Pakai constructor const sebanyak mungkin.
- Periksa jumlah rebuild lewat tampilan performa Flutter DevTools dalam profile mode di perangkat asli.
Lapisan repository yang rapi dan state yang terdefinisi jelas membuat library mana pun enak dipakai. Tanpa keduanya, tidak ada library yang bisa menyelamatkan proyek.
Pelatihan Flutter kami membangun satu aplikasi kecil yang sama dengan Provider, Riverpod, dan Bloc secara berdampingan, supaya tim bisa melihat perbedaannya di kode nyata dan menyepakati satu standar sebelum memulai proyek sendiri.
Poin penting
- Pakai setState untuk state milik satu widget, dan library state management untuk state aplikasi yang dipakai bersama.
- Provider paling mudah untuk memulai, Riverpod cocok untuk sebagian besar aplikasi yang banyak memakai API, dan Bloc pas untuk tim besar dan alur yang rumit.
- Pakai satu pendekatan saja per codebase, jangan dicampur.
- Repository, state yang immutable, serta state loading dan error yang eksplisit lebih penting daripada pilihan library.
- Bangun ulang hanya bagian yang berubah dengan memilih state yang memang dibutuhkan widget.
