Perbandingan & Kapan Memilih #

Setelah kita menjelajahi berbagai pustaka manajemen state di Flutter — mulai dari yang paling sederhana seperti setState dan ValueNotifier, hingga solusi tingkat lanjut seperti Provider, Riverpod, Bloc/Cubit, dan MobX — satu pertanyaan krusial yang pasti muncul di benak kita adalah: manakah yang harus kita pilih untuk proyek kita?

Sering kali, para pengembang terjebak dalam perdebatan tanpa ujung tentang pustaka mana yang “terbaik”. Faktanya, tidak ada peluru perak (no silver bullet) di dunia rekayasa perangkat lunak. Pustaka yang sangat cocok untuk aplikasi korporasi skala besar dengan puluhan pengembang bisa jadi merupakan beban yang berlebihan untuk aplikasi hobi yang dikerjakan sendiri dalam waktu seminggu. Pilihan terbaik selalu merupakan hasil kompromi yang disesuaikan dengan konteks proyek, kapabilitas tim, dan kebutuhan pemeliharaan jangka panjang.

Dokumen ini disusun untuk memberikan kerangka keputusan yang objektif, mendalam, dan terstruktur. Kita akan membandingkan berbagai dimensi dari kelima pendekatan tersebut, melihat perbandingan kode dalam skenario yang identik, menganalisis pohon keputusan, serta mengevaluasi faktor-faktor penentu yang krusial.

Matriks Perbandingan Fitur #

Untuk memberikan gambaran awal yang komprehensif, berikut adalah tabel perbandingan fitur dan karakteristik utama dari masing-masing pendekatan manajemen state yang telah kita pelajari:

Mari kita bahas beberapa parameter penting dari tabel di atas agar kita memiliki pemahaman yang lebih kaya:

1. Kurva Belajar: setState adalah bagian mendasar dari Flutter, sehingga semua pengembang pasti bisa langsung menggunakannya. Bloc memiliki kurva belajar tertinggi karena memaksa kita memahami konsep arsitektur berbasis event-stream, sedangkan MobX dan Riverpod berada di tengah-tengah karena membutuhkan pemahaman tentang konsep reaktivitas transparan atau dekorator khusus.
2. Ketergantungan pada BuildContext: Provider dan Bloc sangat bergantung pada BuildContext untuk mencari instansi state di dalam widget tree menggunakan metode InheritedWidget di belakang layar. Hal ini menyulitkan jika kita ingin mengakses state di luar UI (misalnya pada layer background service atau pendeteksi lokasi). Riverpod dan MobX melepaskan diri dari ketergantungan ini, memungkinkan akses state yang lebih fleksibel.
3. Keamanan Waktu-Kompilasi (Compile-time Safety): Salah satu kelemahan terbesar Provider adalah potensi munculnya error ProviderNotFoundException saat aplikasi dijalankan (runtime). Riverpod memecahkan masalah ini sepenuhnya dengan memindahkan definisi provider menjadi variabel global yang aman dari masalah pencarian tipe data pada runtime.

Perbandingan Kode untuk Fitur yang Sama #

Cara terbaik untuk memahami perbedaan filosofi antar pustaka adalah dengan melihat bagaimana mereka menyelesaikan masalah yang sama. Di bawah ini, kita akan melihat implementasi fitur sederhana: mengambil daftar produk dari API, mengelola status loading, menangani error, dan menampilkan hasilnya ke UI.

1. setState #

Pendekatan bawaan tanpa pustaka eksternal. Semua state disimpan langsung di dalam kelas State dari widget.

class _HalamanProdukState extends State<HalamanProdukScreen> {
  List<Produk> _daftarProduk = [];
  bool _sedangMemuat = false;
  String? _pesanError;

  @override
  void initState() {
    super.initState();
    _ambilData();
  }

  Future<void> _ambilData() async {
    setState(() {
      _sedangMemuat = true;
      _pesanError = null;
    });
    try {
      final hasil = await produkRepository.ambilSemua();
      if (mounted) {
        setState(() {
          _daftarProduk = hasil;
          _sedangMemuat = false;
        });
      }
    } catch (e) {
      if (mounted) {
        setState(() {
          _pesanError = e.toString();
          _sedangMemuat = false;
        });
      }
    }
  }

  @override
  Widget build(BuildContext context) {
    if (_sedangMemuat) return const Center(child: CircularProgressIndicator());
    if (_pesanError != null) return Center(child: Text(_pesanError!));
    return ListView.builder(
      itemCount: _daftarProduk.length,
      itemBuilder: (context, index) => ListTile(title: Text(_daftarProduk[index].nama)),
    );
  }
}

• Analisis: Sangat cepat ditulis dan tidak memerlukan konfigurasi proyek. Namun, logika bisnis bercampur aduk dengan UI, kode sulit diuji dengan unit test, dan state bersifat lokal sehingga tidak bisa dibagikan ke layar lain dengan mudah.

2. Provider #

Memisahkan state ke dalam kelas kelas ChangeNotifier yang memicu pembaruan UI melalui metode notifyListeners().

// Model / State Controller
class ProdukNotifier extends ChangeNotifier {
  final ProdukRepository _repo;
  List<Produk> daftarProduk = [];
  bool sedangMemuat = false;
  String? pesanError;

  ProdukNotifier(this._repo);

  Future<void> ambilData() async {
    sedangMemuat = true;
    pesanError = null;
    notifyListeners();

    try {
      daftarProduk = await _repo.ambilSemua();
    } catch (e) {
      pesanError = e.toString();
    } finally {
      sedangMemuat = false;
      notifyListeners();
    }
  }
}

// Widget UI
class TampilanProdukProvider extends StatelessWidget {
  const TampilanProdukProvider({super.key});

  @override
  Widget build(BuildContext context) {
    return Consumer<ProdukNotifier>(
      builder: (context, notifier, _) {
        if (notifier.sedangMemuat) {
          return const Center(child: CircularProgressIndicator());
        }
        if (notifier.pesanError != null) {
          return Center(child: Text(notifier.pesanError!));
        }
        return ListView.builder(
          itemCount: notifier.daftarProduk.length,
          itemBuilder: (context, index) => ListTile(title: Text(notifier.daftarProduk[index].nama)),
        );
      },
    );
  }
}

• Analisis: Logika bisnis sudah berhasil dipisahkan dari UI. Kita dapat menulis unit test untuk ProdukNotifier. Namun, kita harus menulis notifyListeners() secara manual di setiap akhir perubahan state, yang berpotensi terlewat jika fungsi kita kompleks.

3. Riverpod #

Menggunakan paradigma fungsional modern dan memanfaatkan kelas AsyncNotifier untuk mengelola state asinkron secara otomatis.

// Notifier
class AsyncProdukNotifier extends AutoDisposeAsyncNotifier<List<Produk>> {
  @override
  Future<List<Produk>> build() async {
    // Cukup kembalikan future dari API, Riverpod akan mengurus status loading/error
    return ref.watch(produkRepositoryProvider).ambilSemua();
  }
}

// Provider Definition
final produkNotifierProvider = AsyncNotifierProvider.autoDispose<AsyncProdukNotifier, List<Produk>>(
  AsyncProdukNotifier.new,
);

// Widget UI
class TampilanProdukRiverpod extends ConsumerWidget {
  const TampilanProdukRiverpod({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final stateProduk = ref.watch(produkNotifierProvider);

    return stateProduk.when(
      loading: () => const Center(child: CircularProgressIndicator()),
      error: (err, _) => Center(child: Text(err.toString())),
      data: (daftarProduk) => ListView.builder(
        itemCount: daftarProduk.length,
        itemBuilder: (context, index) => ListTile(title: Text(daftarProduk[index].nama)),
      ),
    );
  }
}

• Analisis: Kode menjadi jauh lebih pendek dan ekspresif. Riverpod menangani status loading, error, dan data secara terstruktur melalui AsyncValue.when. Keamanan waktu kompilasi terjamin dan tidak ada ketergantungan pada BuildContext.

4. Bloc / Cubit #

Menggunakan arsitektur berbasis pemancaran state (state emission) yang ketat untuk menjamin ketertelusuran perubahan (traceability).

// States
sealed class StateProduk {}
class ProdukInitial extends StateProduk {}
class ProdukLoading extends StateProduk {}
class ProdukLoaded extends StateProduk {
  final List<Produk> daftar;
  ProdukLoaded(this.daftar);
}
class ProdukError extends StateProduk {
  final String pesan;
  ProdukError(this.pesan);
}

// Cubit (Versi sederhana dari Bloc)
class ProdukBloc extends Cubit<StateProduk> {
  final ProdukRepository _repo;
  ProdukBloc(this._repo) : super(ProdukInitial());

  Future<void> ambilData() async {
    emit(ProdukLoading());
    try {
      final hasil = await _repo.ambilSemua();
      emit(ProdukLoaded(hasil));
    } catch (e) {
      emit(ProdukError(e.toString()));
    }
  }
}

// Widget UI
class TampilanProdukBloc extends StatelessWidget {
  const TampilanProdukBloc({super.key});

  @override
  Widget build(BuildContext context) {
    return BlocBuilder<ProdukBloc, StateProduk>(
      builder: (context, state) {
        return switch (state) {
          ProdukLoading() => const Center(child: CircularProgressIndicator()),
          ProdukError(:final pesan) => Center(child: Text(pesan)),
          ProdukLoaded(:final daftar) => ListView.builder(
              itemCount: daftar.length,
              itemBuilder: (context, index) => ListTile(title: Text(daftar[index].nama)),
            ),
          _ => const Center(child: Text('Tidak ada data')),
        };
      },
    );
  }
}

• Analisis: Sangat terstruktur dan mudah dipahami alur perubahannya karena setiap kondisi didefinisikan sebagai kelas terpisah. Hal ini mempermudah pelacakan bug (debugging) dan audit log. Kekurangannya adalah kita harus menulis banyak kelas boilerplate untuk state dan event.

5. MobX #

Menggunakan prinsip reaktivitas transparan dengan otomatisasi pembaruan UI melalui code generation.

// Store Definition
import 'package:mobx/mobx.dart';
part 'produk_store.g.dart';

class ProdukStore = _ProdukStore with _$ProdukStore;

abstract class _ProdukStore with Store {
  final ProdukRepository _repo;
  _ProdukStore(this._repo);

  @observable
  ObservableList<Produk> daftarProduk = ObservableList<Produk>();

  @observable
  bool sedangMemuat = false;

  @observable
  String? pesanError;

  @action
  Future<void> ambilData() async {
    sedangMemuat = true;
    pesanError = null;
    try {
      final hasil = await _repo.ambilSemua();
      daftarProduk = ObservableList.of(hasil);
    } catch (e) {
      pesanError = e.toString();
    } finally {
      sedangMemuat = false;
    }
  }
}

// Widget UI
class TampilanProdukMobX extends StatelessWidget {
  final ProdukStore store;
  const TampilanProdukMobX({super.key, required this.store});

  @override
  Widget build(BuildContext context) {
    return Observer(
      builder: (_) {
        if (store.sedangMemuat) {
          return const Center(child: CircularProgressIndicator());
        }
        if (store.pesanError != null) {
          return Center(child: Text(store.pesanError!));
        }
        return ListView.builder(
          itemCount: store.daftarProduk.length,
          itemBuilder: (context, index) => ListTile(title: Text(store.daftarProduk[index].nama)),
        );
      },
    );
  }
}

• Analisis: Mendekati efisiensi penulisan setState namun dengan pemisahan logika yang bersih. Kita tidak perlu memanggil listener secara manual karena dideteksi otomatis oleh Observer. Namun, kita wajib bergantung pada proses run build_runner selama masa pengembangan.

Pohon Keputusan (Decision Tree) Pemilihan #

Untuk mempermudah kita menentukan pilihan yang paling objektif berdasarkan situasi nyata, kita dapat menggunakan pohon keputusan di bawah ini sebagai panduan awal:

graph TD
    classDef default stroke:#333,stroke-width:2px;
    
    A["Mulai Evaluasi State Management"] --> B{"Apakah state hanya digunakan di satu widget?"}
    B -->|Ya| C["Gunakan setState atau ValueNotifier"]
    B -->|Tidak| D{"Berapa perkiraan skala proyek dan tim?"}
    
    D -->|"Kecil: 1-3 devs, <10 screen"| E{"Apakah tim familiar dengan React atau konsep reaktif?"}
    E -->|Ya| F["Gunakan MobX"]
    E -->|Tidak| G["Gunakan Provider"]
    
    D -->|"Menengah: 3-8 devs, 10-30 screen"| H{"Apakah membutuhkan safety tinggi & penanganan async elegan?"}
    H -->|Ya| I["Gunakan Riverpod"]
    H -->|Tidak| J["Tetap gunakan Provider / Cubit"]
    
    D -->|"Besar: 8+ devs, 30+ screen"| K{"Apakah membutuhkan audit trail penuh dan arsitektur super ketat?"}
    K -->|Ya| L["Gunakan Bloc"]
    K -->|Tidak| M["Gunakan Riverpod atau MobX (dengan arsitektur modular)"]

Langkah Evaluasi Berdasarkan Pohon Keputusan #

Jika kita mengikuti alur di atas, proses pengambilan keputusan dapat dijabarkan sebagai berikut:

1. Lokalitas State: Selalu mulai dengan menanyakan apakah data tersebut dibutuhkan oleh widget lain. Jika data tersebut hanya digunakan di dalam satu widget saja (misalnya status animasi tombol, input form sementara sebelum dikirim, atau tab aktif), jangan gunakan pustaka eksternal. Gunakan setState atau ValueNotifier bawaan Flutter. Ini menjaga aplikasi kita tetap ringan dan bersih.
2. Skala Proyek: Untuk aplikasi skala kecil dengan tim yang ramping, prioritas utama kita adalah kecepatan rilis produk (time-to-market). Provider atau MobX sangat unggul di sini karena tidak memerlukan banyak boilerplate.
3. Kebutuhan Lanjutan: Jika proyek mulai berkembang ke arah skala menengah atau besar, kebutuhan akan stabilitas arsitektur meningkat. Jika kita menginginkan kode yang sangat modular dengan kemampuan pengujian kelas dunia tanpa terikat BuildContext, Riverpod adalah jalan terbaik. Namun, jika kita bekerja di korporasi dengan banyak tim paralel dan membutuhkan standar kode yang super ketat agar kode siapa pun terlihat seragam, Bloc adalah standar industri yang tak terbantahkan.

Evaluasi Faktor-Faktor Utama Keputusan #

Mari kita bedah secara lebih detail empat faktor penentu yang harus kita diskusikan bersama tim sebelum menentukan keputusan akhir.

1. Ukuran dan Latar Belakang Pengalaman Tim #

Pustaka terbaik adalah pustaka yang dipahami dengan baik oleh tim kita. Mengadopsi teknologi canggih yang tidak dikuasai oleh tim hanya akan memperlambat pengembangan dan memicu banyak bug baru.

• Latar Belakang Java / C# / Native Mobile (Android & iOS): Tim dengan latar belakang ini biasanya menyukai struktur kode yang formal, berbasis kelas, dan menggunakan pola desain seperti Command, Observer, atau dependency injection tradisional. Bagi tim seperti ini, Bloc / Cubit akan terasa sangat alami karena strukturnya mirip dengan pola pemrograman berorientasi objek (OOP) klasik.
• Latar Belakang React / Vue / Web Frontend: Jika tim kita terbiasa dengan ekosistem JavaScript, React Hooks, atau Vue Composition API, mereka akan merasa sangat familier dengan MobX (karena konsep observable/action-nya identik) atau Riverpod (karena cara kerja provider global mirip dengan React Context dan hooks).
• Pengembang Pemula Flutter: Jika tim baru pertama kali menyentuh Flutter, mulailah dengan Provider atau Cubit. Mengharuskan mereka langsung mempelajari Bloc dengan aliran event-stream yang rumit dapat menurunkan produktivitas dan moral tim secara drastis.

2. Kemudahan Pengujian (Testability) #

Aplikasi produksi yang sukses harus didukung oleh pengujian otomatis yang solid. Struktur penulisan state management sangat mempengaruhi seberapa mudah kita membuat test untuknya.

• Bloc: Sangat unggul di sektor pengujian berkat pustaka bloc_test. Kita dapat menguji emisi state secara deklaratif:

  blocTest<ProdukBloc, StateProduk>(
    'Memancarkan [ProdukLoading, ProdukLoaded] saat data berhasil diambil',
    build: () => ProdukBloc(mockRepository),
    act: (bloc) => bloc.ambilData(),
    expect: () => [
      isA<ProdukLoading>(),
      isA<ProdukLoaded>(),
    ],
  );
  

• Riverpod: Menawarkan pengujian yang sangat modular menggunakan objek ProviderContainer. Kita dapat menguji seluruh alur logika tanpa perlu menginisialisasi framework Flutter widget tree:

  final container = ProviderContainer(
    overrides: [
      produkRepositoryProvider.overrideWith((ref) => MockProdukRepository()),
    ],
  );
  addTearDown(container.dispose);
  
  // Membaca state asinkron secara langsung
  final hasil = await container.read(produkNotifierProvider.future);
  expect(hasil, isNotEmpty);
  

• setState: Hampir tidak mungkin diuji menggunakan unit test murni. Kita harus menulis widget test atau integration test yang memakan waktu eksekusi jauh lebih lama dan membutuhkan resource komputasi lebih besar.

3. Penanganan State Asinkron (Async State Management) #

Sebagian besar bug di aplikasi Flutter terjadi karena kesalahan penanganan data asinkron, seperti menampilkan layar kosong saat terjadi error, tombol yang dapat ditekan berulang kali saat loading sedang berlangsung, atau data yang tidak sinkron setelah mutasi.

• Riverpod mengatasinya paling elegan dengan tipe data AsyncValue. Tipe ini memaksa kita di level kompilasi kode untuk menangani tiga kondisi utama: data, loading, dan error. Kita tidak bisa melewatkan penanganan error tanpa memicu peringatan dari compiler.
• Bloc memaksa kita membuat kelas state yang berbeda untuk setiap kondisi. Walaupun aman, kita harus rajin menulis kelas-kelas tersebut secara manual untuk setiap fitur baru.
• MobX dan Provider menyerahkan penanganan status asinkron ini kepada kreativitas kita sendiri (misal dengan membuat variabel boolean isLoading secara manual). Ini memberikan fleksibilitas tinggi, tetapi rawan melahirkan inkonsistensi jika standar kode tidak ditegakkan secara disiplin di tim.

4. Boilerplate vs Stabilitas Kode #

Ada korelasi langsung antara jumlah boilerplate yang kita tulis dengan tingkat keamanan aplikasi kita.

• Bloc meminta kita menulis banyak kode deklaratif di awal (Event, State, Cubit/Bloc). Imbalannya adalah kestabilan kode jangka panjang yang sangat tinggi. Sangat sulit bagi pengembang lain untuk merusak alur data karena modifikasi state dibatasi secara ketat hanya melalui pengiriman Event.
• MobX menggunakan reaktivitas transparan yang sangat minim boilerplate. Namun, karena reaktivitasnya bersifat “ajaib” (terjadi otomatis di belakang layar), menelusuri bug reaktivitas yang rumit di MobX terkadang bisa membingungkan bagi pengembang yang belum berpengalaman.

Rekomendasi Skenario Berdasarkan Konteks Nyata #

Mari kita lihat rekomendasi konkret untuk beberapa jenis skenario proyek nyata yang sering kita temui di industri:

Skenario A: Proyek Personal, Hobi, atau MVP (Minimum Viable Product) #

• Tujuan: Meluncurkan fitur secepat mungkin untuk divalidasi ke pengguna.
• Rekomendasi Utama: Riverpod atau Provider
• Alasan: Struktur kodenya fleksibel, tidak membutuhkan banyak file terpisah, dan memiliki dokumentasi komunitas yang sangat melimpah untuk menyelesaikan masalah sehari-hari.

Skenario B: Aplikasi Startup Bergerak Cepat (Fast-Growing Startup) #

• Tujuan: Kecepatan iterasi produk tinggi namun kode harus tetap aman untuk ditest dan dirawat oleh anggota tim baru.
• Rekomendasi Utama: Riverpod
• Alasan: Riverpod memberikan keseimbangan terbaik antara boilerplate yang minim dengan tingkat keamanan tipe data (type safety) dan pengujian yang sangat kuat. Fitur autoDispose bawaan Riverpod juga sangat membantu menghemat memori perangkat pengguna secara otomatis.

Skenario C: Aplikasi Enterprise / Korporasi Besar (Multi-Fitur & Tim Paralel) #

• Tujuan: Konsistensi penulisan kode mutlak, ketertelusuran bug yang transparan, kemudahan pembagian tugas antar tim paralel, dan audit log perubahan state aplikasi.
• Rekomendasi Utama: Bloc
• Alasan: Bloc membagi logika bisnis menjadi komponen-komponen yang sangat terisolasi. Pengembang dari Tim A tidak akan mengganggu logika Tim B meskipun mereka bekerja di modul yang berdekatan. Standardisasi Bloc yang ketat memastikan bahwa pengembang baru dapat langsung membaca kode pengembang lain tanpa memerlukan proses adaptasi yang lama.

Skenario D: Aplikasi dengan Visualisasi Data Real-Time yang Kompleks #

• Tujuan: Aplikasi yang membutuhkan pembaruan UI secara super-intensif dan granular setiap milidetik (misalnya aplikasi bursa saham, pelacak GPS real-time, atau dashboard sensor IoT).
• Rekomendasi Utama: MobX
• Alasan: Berkat arsitektur reaktif transparannya, MobX melakukan rebuild widget secara otomatis pada level komponen terkecil dengan performa yang sangat luar biasa. Kita tidak perlu menulis kode manual yang rumit untuk membandingkan perubahan state demi performa optimasi.

Pendekatan Hibrida: Menggabungkan Beberapa Solusi #

Satu kesalahpahaman yang umum adalah anggapan bahwa kita harus menggunakan satu pustaka manajemen state eksklusif untuk seluruh aplikasi kita. Pada kenyataannya, banyak proyek besar berskala industri yang menerapkan pendekatan hibrida (hybrid approach).

Aturan dasar yang aman untuk menerapkan pola hibrida adalah sebagai berikut:

flowchart TD
    Local["UI State Lokal (Form input, Tab, Animasi)"] -->|"Gunakan"| LocalUse["setState / ValueNotifier"]
    Shared["Shared Business Logic (Keranjang belanja, Auth)"] -->|"Gunakan"| SharedUse["Riverpod / Bloc"]
    Global["App Config Global (Tema gelap, Bahasa)"] -->|"Gunakan"| GlobalUse["Provider / Riverpod"]

    Local --> Shared
    Shared --> Global

    style Local stroke:#0288d1,stroke-width:2px
    style Shared stroke:#388e3c,stroke-width:2px
    style Global stroke:#f57c00,stroke-width:2px

Panduan Menggunakan Pola Hibrida: #

1. Gunakan setState untuk State UI Lokal: Jangan pernah memasukkan state form input sementara atau status expand/collapse sebuah accordion ke dalam Bloc global atau Riverpod provider. Biarkan hal tersebut dikelola secara lokal oleh StatefulWidget menggunakan setState. Ini menjaga state global kita tetap bersih dari informasi sampah.
2. Gunakan Pustaka Global untuk Business State: Gunakan Riverpod, Bloc, atau MobX untuk mengelola alur bisnis yang sesungguhnya (seperti proses autentikasi pengguna, sinkronisasi keranjang belanja, atau pengambilan data dari database).
3. Konsisten dalam Satu Fitur: Jangan mencampuradukkan dua pustaka global yang berbeda untuk satu fitur yang sama. Misalnya, jika halaman Checkout menggunakan Riverpod, jangan gunakan Bloc untuk sub-fitur metode pembayaran di halaman tersebut. Jaga agar satu alur fitur tetap menggunakan satu teknologi yang konsisten agar mudah dibaca dan ditest.

Ringkasan #

• Tidak Ada Solusi Universal: Setiap pustaka memiliki kelebihan dan kekurangannya masing-masing. Pilihlah berdasarkan skala proyek, latar belakang tim, dan kebutuhan maintainability jangka panjang.
• setState & ValueNotifier adalah solusi terbaik untuk mengelola state lokal yang tidak perlu dibagikan ke widget lain di luar layarnya.
• Provider sangat bersahabat bagi tim pemula karena memiliki kurva belajar yang landai dan basis komunitas pendukung yang sangat besar.
• Riverpod merupakan evolusi modern dari Provider yang menawarkan keamanan waktu-kompilasi, penanganan asinkron yang luar biasa melalui AsyncValue, dan kemudahan unit testing.
• Bloc / Cubit adalah standar emas aplikasi berskala enterprise yang mengutamakan ketertelusuran bug, arsitektur kode yang seragam, dan isolasi ketat antar-modul.
• MobX sangat cocok untuk tim dengan latar belakang web (React) yang menginginkan reaktivitas otomatis tingkat tinggi dengan performa rebuild yang sangat presisi tanpa boilerplate.
• Pendekatan Hibrida sangat disarankan: kelola UI state lokal dengan setState dan serahkan business state kompleks ke pustaka manajemen state global yang kita sepakati bersama tim.

← Sebelumnya: MobX   Berikutnya: Best Practice →