Üç State Management Paradigmasının Temel Farkları

Flutter state management, 2026’da hala ekip içi tartışmaların en sıcak konularından biri. Flutter ekibinin resmi olarak “tek doğru” bir çözüm önermemesi, ekosistemde onlarca state management library’sinin oluşmasına yol açtı. Stack Overflow Developer Survey 2025’e göre Flutter geliştiricilerinin %42’si Riverpod, %28’i Bloc, %14’ü MobX, %10’u Provider, %6’sı GetX kullanıyor. Bu üç ana yaklaşım — MobX, Riverpod ve Bloc — fundamental olarak farklı paradigmalar üzerine kuruldu ve her birinin spesifik kullanım alanları var.

Bu yazıda, Türkiye’de Trendyol, Hepsiburada ve Akbank Mobil gibi büyük Flutter ekiplerinin state management seçimlerini, production trade-off’larını ve “hangi senaryoda hangisi” sorularını derinlemesine inceliyoruz.

Üç State Management Paradigmasının Temel Farkları

Flutter state management’ın üç ana paradigması temel olarak şu sorulara farklı cevap veriyor: “State nasıl tanımlanır?”, “State değişikliği nasıl tetiklenir?”, “UI state değişikliğini nasıl observe eder?”.

MobX, “reactive observables” paradigmasını izliyor. State, observable variable’lar olarak tanımlanır; bu variable’lar değiştiğinde, onları kullanan UI otomatik olarak rebuild olur. Mimari olarak basit ve sezgisel; ama compile-time safety eksik, runtime hataları olabilir.

Riverpod, “dependency injection + reactive providers” paradigması. Provider, state’i hold eden bir compile-time-safe container. UI, provider’a “subscribe” olur ve state değiştiğinde rebuild olur. En modern ve type-safe yaklaşım; öğrenme eğrisi orta.

Bloc, “event-driven business logic component” paradigması. UI, Bloc’a event gönderir; Bloc, business logic’i işler ve state emit eder; UI yeni state’e göre rebuild olur. En disciplined ve enterprise-friendly yaklaşım; öğrenme eğrisi yüksek, boilerplate fazla.

MobX: Reactive Observables Pattern

MobX, JavaScript dünyasından gelen ve Flutter’a port edilen reactive programming kütüphanesi. mobx.dart paketi 2018’den beri production’da kullanılıyor. Felsefesi şu: “developer state’i normal değişken gibi yazsın, framework reactive magic’i halletsin”.

import 'package:mobx/mobx.dart';
part 'cart_store.g.dart';

class CartStore = _CartStore with _$CartStore;

abstract class _CartStore with Store {
  @observable
  ObservableList items = ObservableList();

  @observable
  bool isLoading = false;

  @computed
  double get totalPrice => items.fold(0, (sum, item) => sum + item.price);

  @action
  Future addItem(CartItem item) async {
    isLoading = true;
    await Future.delayed(Duration(milliseconds: 300));
    items.add(item);
    isLoading = false;
  }
}

// UI tarafı
Observer(
  builder: (_) => Text('Toplam: ${cartStore.totalPrice} TL'),
)

MobX’in en büyük avantajı, “magical” deneyim. Observer widget’ı, hangi observable’ları kullandığını otomatik track eder ve sadece o observable’lar değiştiğinde rebuild olur. State management ile uğraşmadan UI yazılabiliyor. Dezavantajı, code generation gerektirmesi (build_runner) ve runtime’da observe edilmeyen değişikliklerin sessizce ignore edilmesi.

Riverpod: Compile-Time Safe Reactive State

Riverpod, Flutter community’sinin en sevdiği state management library’si haline geldi. Remi Rousselet (Flutter community’de saygın bir mühendis) tarafından geliştirildi. Provider library’sinin “next generation” versiyonu; aynı yazar, daha olgun mimari.

Riverpod 2.5 (2024 sonu) ile birlikte code generation desteği geldi (riverpod_generator). Bu, “type-safe + DI + reactive” üçlüsünü compile-time’da garanti ediyor. 2026’da yeni Flutter projeleri için Flutter ekibinin resmi olmayan ama de facto önerisi Riverpod.

@riverpod
class CartNotifier extends _$CartNotifier {
  @override
  CartState build() => CartState.initial();

  Future addItem(CartItem item) async {
    state = state.copyWith(isLoading: true);
    await Future.delayed(Duration(milliseconds: 300));
    state = state.copyWith(
      items: [...state.items, item],
      isLoading: false,
    );
  }
}

@riverpod
double cartTotal(CartTotalRef ref) {
  final cart = ref.watch(cartNotifierProvider);
  return cart.items.fold(0, (sum, item) => sum + item.price);
}

// UI tarafı
Consumer(
  builder: (context, ref, _) {
    final total = ref.watch(cartTotalProvider);
    return Text('Toplam: $total TL');
  },
)

Riverpod’un en güçlü yanı, dependency injection ile state management’ı birleştirmesi. ref.watch ile bağımlılıklar declarative tanımlanır; ref.read ile imperative invocation yapılır. Provider’lar otomatik dispose olur, memory leak riski minimum. Code generation ile boilerplate %70 azalır.

Bloc: Event-Driven Business Logic

Bloc (Business Logic Component), Felix Angelov tarafından geliştirilen ve enterprise Flutter projelerinin de facto standardı haline gelen pattern. Architecture-driven design’ı zorlar; UI ile business logic arasında net sınır çizer.

Bloc’un temel idea’sı şu: UI, kullanıcı interaction’larını “event” olarak Bloc’a gönderir. Bloc, event’leri işleyip “state” emit eder. UI, BlocBuilder ile state stream’ini dinler ve yeni state’e göre rebuild olur. Bu pattern, business logic’i tamamen UI’dan izole eder; testability yüksek olur.

// Event tanımı
sealed class CartEvent {}
class AddItem extends CartEvent {
  final CartItem item;
  AddItem(this.item);
}

// State tanımı
class CartState {
  final List items;
  final bool isLoading;
  CartState({required this.items, this.isLoading = false});
}

// Bloc tanımı
class CartBloc extends Bloc {
  CartBloc() : super(CartState(items: [])) {
    on((event, emit) async {
      emit(CartState(items: state.items, isLoading: true));
      await Future.delayed(Duration(milliseconds: 300));
      emit(CartState(items: [...state.items, event.item], isLoading: false));
    });
  }
}

// UI tarafı
BlocBuilder(
  builder: (context, state) {
    final total = state.items.fold(0.0, (sum, item) => sum + item.price);
    return Text('Toplam: $total TL');
  },
)

Bloc’un avantajları: net mimari ayrımı, test edilebilirlik (Bloc’lar pure Dart class’ı, widget test’siz birim test’lenebilir), öngörülebilir state transitions, hot reload’da state preservation. Dezavantajları: boilerplate çok (event + state + bloc dosyaları), öğrenme eğrisi yüksek, küçük uygulamalarda overkill.

Performance Karşılaştırması

Üç framework’ün performance profilleri farklı. Pure Flutter benchmark’larda fark minimal (her biri 60 FPS sabit), ancak büyük production uygulamalarında subtle farklar var.

Rebuild granularity en kritik metrik. MobX, observable seviyesinde rebuild yapar; bu en granüler. Riverpod, provider seviyesinde; provider içindeki herhangi bir değişiklik o provider’ı dinleyen tüm widget’ları rebuild eder. Bloc, state objesi seviyesinde; herhangi bir field değiştiğinde tüm BlocBuilder’lar rebuild olur (Equatable ile bu optimize edilebilir).

Testing Strategy ve Test Edilebilirlik

State management seçiminin en önemli kriteri test edilebilirlik. Üç framework’ün testing pattern’leri ve test yazma maliyetleri farklı.

• MobX Testing: Store’lar pure Dart class’ı, doğrudan unit test’lenebilir. Observer reactivity’sini test etmek için widget test gerekir.
• Riverpod Testing: ProviderContainer ile isolated test environment kurulur. ref.read ile state’e erişim, override ile mock injection yapılır.
• Bloc Testing: bloc_test paketi ile çok güçlü. Event gönderip beklenen state sequence’ı assert etmek kolay.

Production’da Bloc’un test edilebilirliği en yüksek. bloc_test paketi, “given an initial state, when event A is added, expect states X, Y, Z” pattern’ini deklaratif yazmayı sağlar. Türkiye’de Trendyol’un Flutter ekibi, Bloc tercih etme sebeplerinin başında bu testing kolaylığını gösteriyor.

Dependency Injection ve Modülarite

State management seçimi, dependency injection (DI) yaklaşımıyla yakından ilişkili. MobX kendi başına DI sağlamaz; get_it ya da injectable gibi ayrı bir DI library gerektirir. Riverpod hem state management hem DI sağlar; “tek araç, çift fayda”. Bloc, ya provider package ile (Flutter ekibinin resmi DI), ya get_it ile, ya da BlocProvider widget’ı ile kullanılır.

Bloc’un yaratıcısı Felix Angelov, 2025 Flutter Forward konferansında şu vurguyu yapmıştı: “State management seçimi, ekip büyüklüğü ve uygulama ömrü ile yakından ilgilidir. 2-3 kişilik bir startup için Riverpod muhteşem; 30 kişilik bir kurumsal ekipte Bloc’un net mimari ayrımı kritik. Yanlış araç seçimi ‘cool teknoloji’ tartışması değil, organizasyonel verimlilik problemi.”

Code Organization ve Folder Structure

Her state management framework, kendi folder structure pattern’ini önerir. MobX: feature-based, her feature kendi store’unu içerir. Riverpod: feature-based ya da type-based; provider’lar ayrı dosyalarda. Bloc: strict feature-based, her feature event/state/bloc dosyalarını ayrı içerir.

Production’da en yaygın Bloc folder structure’ı şöyle: features/cart/bloc/cart_bloc.dart, cart_event.dart, cart_state.dart, view/cart_page.dart, widgets/cart_item_widget.dart. Bu pattern, her feature’ı self-contained yapar; mikro-feature’lar bağımsız geliştirilebilir.

Hangi Framework’ü Hangi Senaryoda Seçmeli?

Üç framework için “doğru seçim” senaryolar:

• MobX: Reactive programming background’i olan ekipler (özellikle React/Vue/MobX-JS deneyimi). Hızlı prototyping. Küçük-orta uygulamalar. Compile-time safety çok kritik değilse.
• Riverpod: Modern Flutter projeleri. Type-safety ve DI önemli. Solo ya da 2-5 kişilik ekipler. Code generation ile boilerplate’i kabul ediyorsanız.
• Bloc: Kurumsal uygulamalar (10+ developer). Strict architecture önemli. Test coverage hedefi yüksek. Long-term maintenance düşünüyorsanız.

Pratikte 2026’da yeni başlayan Flutter projelerinin çoğu Riverpod tercih ediyor; kurumsal Flutter projelerinin çoğunluğu Bloc kullanıyor; legacy projeleri ya MobX ya da Provider ile devam ediyor. GetX kullanımı, “magic too much” eleştirileri sonrası 2026’da düşüyor.

Migration: Provider’dan Riverpod’a, MobX’ten Bloc’a

State management migration’ı, Flutter ekiplerinin en sık karşılaştığı refactor’lerden biri. Tipik migration paths:

• Provider → Riverpod: En yumuşak migration. Provider’ın yazarı Remi Rousselet Riverpod’u tasarladığı için, API benzerliği yüksek. Tipik 2-4 hafta süre.
• MobX → Riverpod: Orta zorlukta. Reactive observables’ı provider’a çevirmek mantıksal olarak benzer; ama runtime’dan compile-time safety’ye geçiş ek effort gerektirir.
• Bloc → Riverpod: Nadir görülür ama mümkün. Genelde “boilerplate çok” şikayetiyle yapılır. Migration süresi 4-8 hafta.
• Provider → Bloc: Kurumsal ekiplerin yaygın yolu. Scale-up sürecinde mimari netlik için yapılır. 6-12 hafta.

Sıkça Sorulan Sorular

Kurumsal Flutter State Management Dönüşümünde Tipik Sorunlar

Türkiye’de Flutter ekipleriyle çalışırken üç tipik state management problemi gözlemliyorum. Birincisi, “hype-driven selection”. Ekip ilk önce “en cool” framework’ü seçiyor (genelde Riverpod), sonra gerçek ihtiyaçlara göre acı çekiyor. Doğrusu: önce uygulama büyüklüğü, ekip boyutu ve mimari hedefleri netleştir; sonra framework seç.

İkincisi, over-engineering. Küçük bir uygulama için Bloc kullanmak, her feature için 4-5 dosya yaratıyor. Boilerplate maintenance’a dönüyor. Çözüm: <500 row state, Cubit; <50 ekran uygulama, Riverpod; 50+ ekran ve büyük ekip, Bloc.

Üçüncüsü, mixed state management. Ekip bir kısım feature’larını Riverpod, diğerlerini Bloc, başka bir kısmı Provider ile yazıyor. Bu, code review’ı imkansız hale getiriyor ve onboarding’i 3 katına çıkarıyor. Çözüm: organization-wide tek bir state management standardı, ve “exception”‘ların architectural review’dan geçmesi.

Bir bankacılık Flutter projesinde state management migration danışmanlığında yaşadığımız ders şuydu: “Framework seçimi, takım kararıdır, lider kararı değil.” Tech lead tek başına Riverpod seçti, ekip 6 ay sonra Bloc’u tercih etmesi gerektiğini hissetti, migration 4 ay sürdü. Doğru yaklaşım: 1 hafta süren proof-of-concept dönemi, her ekip üyesinin aynı feature’ı 2 framework’le yazması, sonra kolektif karar. — Ömer Önal

Sonuç

Flutter state management seçimi, 2026’da hala “tek doğru” cevabı olmayan bir karar. MobX, reactive programming background’i için doğal; Riverpod, modern Flutter projelerinin de facto standardı; Bloc, kurumsal ekipler için disiplin sağlayan mimari. Production’da başarı için üç temel kural geçerli: framework seçimini ekip boyutu ve uygulama ömrüyle dengele, tek bir state management standardı belirle, ve testing stratejisini framework seçiminden önce tasarla. Bu üç kuralı uygulayan ekipler, state management’ı bir kaynak harcayan tartışma değil, üretkenliği artıran araç olarak kullanıyor.

Flutter projenizin state management seçimini, mimari kararlarını ve ekip eğitim planını birlikte tasarlayalım. İletişim sayfasından bana ulaşın, 30 dakikalık ücretsiz keşif görüşmesinde projenizin ihtiyaçlarına uygun state management stratejisini birlikte belirleyelim.