Bölüm 6 — Konu 26: BLoC/Cubit Pattern (`flutter_bloc`)

#BLoC Nedir? — Felsefi Farkı Anlama

Şimdiye kadar gördüğümüz Provider ve Riverpod, "state'i tut ve değişince haber ver" felsefesiyle çalışıyordu. BLoC (Business Logic Component), biraz daha katı ve yapılandırılmış bir felsefeye sahiptir: "her state değişikliği, açıkça tanımlanmış bir 'olay' (event) sonucunda gerçekleşmelidir."

Bu, Dart Bölüm 13 Konu 61'de öğrendiğimiz event loop kavramına isim olarak benzese de, farklı bir şey — burada "event", kullanıcı eyleminin veya iş mantığı tetikleyicisinin açık bir temsilidir.

#Cubit — BLoC'un Basitleştirilmiş Hali

BLoC ekosisteminde, önce daha basit olan Cubit'i öğrenmek mantıklıdır — Cubit, tam BLoC pattern'inin event katmanı olmayan bir versiyonudur.

flutter pub add flutter_bloc

import 'package:flutter_bloc/flutter_bloc.dart';

class SepetCubit extends Cubit<int> { // Dart Bölüm 9'u hatırla - generic!
  SepetCubit() : super(0); // başlangıç state'i: 0

  void ekle() {
    emit(state + 1); // "yeni bir state yayınla" — Riverpod'daki 'state =' ile BENZER
  }

  void azalt() {
    if (state > 0) emit(state - 1);
  }
}

Cubit<int> — Bölüm 6 Konu 25'te öğrendiğimiz Riverpod'un Notifier<int>'ine kavramsal olarak çok benzer — ikisi de generic (Dart Bölüm 9), ikisi de bir state kavramına sahip. emit(...), Riverpod'daki state = ... atamasının biraz daha açık (explicit) halidir — "yeni bir state değerini dünyaya yayınla" anlamına geliyor.

#Widget İçinde Kullanım — BlocProvider ve BlocBuilder

void main() {
  runApp(
    BlocProvider(
      create: (context) => SepetCubit(),
      child: MyApp(),
    ),
  );
}

BlocProvider, Bölüm 6 Konu 24'te öğrendiğimiz ChangeNotifierProvider'a yapısal olarak çok benziyor — create: ile (Dart Bölüm 3 Konu 11'deki builder pattern) bir Cubit/Bloc oluşturup widget ağacına "enjekte ediyor."

class SepetIkonu extends StatelessWidget {
  const SepetIkonu({super.key});

  @override
  Widget build(BuildContext context) {
    return BlocBuilder<SepetCubit, int>(
      builder: (context, sepetSayisi) {
        return Badge(
          label: Text('$sepetSayisi'),
          child: Icon(Icons.shopping_cart),
        );
      },
    );
  }
}

BlocBuilder<SepetCubit, int> — burada da Dart Bölüm 9'da öğrendiğimiz birden fazla generic tip parametresi kullanılıyor: SepetCubit (hangi Cubit'i dinleyeceği), int (state'in tipi). builder: fonksiyonu, Bölüm 5 Konu 18-19'da öğrendiğimiz FutureBuilder/StreamBuilder'ın builder pattern'ine çok benzer — context ve o anki state değeri parametre olarak veriliyor, state her emit() edildiğinde bu fonksiyon otomatik olarak yeniden çağrılıyor.

#Cubit'in Metoduna Erişim — context.read

ElevatedButton(
  onPressed: () {
    context.read<SepetCubit>().ekle(); // Provider'daki context.read ile AYNI sözdizimi!
  },
  child: Text('Sepete Ekle'),
)

flutter_bloc, Provider ile aynı context.read<T>()/context.watch<T>() sözdizimini kullanır (çünkü flutter_bloc, aslında arka planda provider paketini kullanır — bu, Dart Bölüm 12'de öğrendiğimiz paket bağımlılıklarının gerçek bir örneği). Bu, üç state management aracının (Provider, Riverpod, BLoC) birbirinden tamamen kopuk olmadığını, aksine ortak temellere (InheritedWidget) dayandığını gösteriyor.

#Tam BLoC Pattern — Events ile

Cubit'ten bir adım öteye geçersek, tam BLoC pattern, state değişikliklerini event class'ları aracılığıyla tetikler — bu, Dart Bölüm 13 Konu 59'da öğrendiğimiz sealed class + pattern matching kavramının mükemmel bir kullanım alanıdır.

sealed class SepetEvent {}
class UrunEklendi extends SepetEvent {
  final String urunAdi;
  UrunEklendi(this.urunAdi);
}
class SepetTemizlendi extends SepetEvent {}

class SepetBloc extends Bloc<SepetEvent, List<String>> {
  SepetBloc() : super([]) {
    on<UrunEklendi>((event, emit) {
      emit([...state, event.urunAdi]); // Dart Bölüm 4'ü hatırla — spread operatörü!
    });
    on<SepetTemizlendi>((event, emit) {
      emit([]);
    });
  }
}

Bloc<SepetEvent, List<String>> — iki generic parametre: gelen event tipi (SepetEvent, sealed class) ve state tipi (List<String>). on<UrunEklendi>((event, emit) { ... }), "bu tür bir event geldiğinde, şu işlemi yap" demenin yolu — Dart Bölüm 13 Konu 59'da öğrendiğimiz sealed class ile exhaustive kontrolün, bir event-driven mimaride nasıl doğal bir şekilde kullanılabileceğini gösteriyor.

emit([...state, event.urunAdi]) — Dart Bölüm 4 Konu 20'de öğrendiğimiz spread operatörü! Var olan state listesini kopyalayıp (immutability korunuyor — yeni bir liste oluşturuluyor, var olan liste değiştirilmiyor), yeni ürünü ekliyoruz.

Kullanım:

context.read<SepetBloc>().add(UrunEklendi('Kalem'));

#Cubit mi, Tam BLoC mi?

Pratik tavsiye: flutter_bloc paketini kullanan projelerin çoğu, aslında Cubit ile başlar — tam BLoC pattern'in event-driven karmaşıklığı, genelde büyük, kurumsal projelerde (birden fazla geliştiricinin, "bu state neden değişti" sorusunu kod okumadan anlaması gerektiğinde) değerli hale gelir.

#Üç Aracı Karşılaştıralım — Bölüm 6'nın Özeti

#🎯 Bu Dersten Çıkarılması Gerekenler

• Cubit<T>, BLoC ekosisteminin basitleştirilmiş hali — emit(...) ile yeni state yayınlanır.
• BlocProvider/BlocBuilder, Provider'ın ChangeNotifierProvider/context.watch'ına yapısal olarak benzer; flutter_bloc arka planda provider paketini kullanır.
• Tam BLoC pattern, state değişikliklerini event class'ları (genelde sealed class ile) aracılığıyla tetikler — her değişikliğin "nedenini" açıkça izlenebilir kılar.
• Cubit, hızlı geliştirme için; tam BLoC, büyük takımlarda denetlenebilirlik gerektiğinde tercih edilir.
• Provider, Riverpod ve BLoC, hepsi temelde InheritedWidget mekanizmasına dayanır — farklı "arayüzler" sunan, ortak bir temele sahip araçlardır.

#📝 Ödevler

• [ ] Cubit<int> ile basit bir sayaç yaz, BlocProvider/BlocBuilder ile ekrana bağla.
• [ ] Sealed class ile event'ler tanımlayan tam bir Bloc yaz (en az 2 farklı event tipiyle), on<EventTipi> ile her birini işle.
• [ ] context.read<T>().add(Event()) ile bir event tetikle, state'in doğru güncellendiğini gözlemle.
• [ ] Aynı basit sepet uygulamasını (önceki derslerdeki), bu sefer Cubit ile yeniden yaz.
• [ ] Kendi cümlelerinle, Provider/Riverpod/Cubit arasındaki temel felsefe farkını (basit bildirim vs event-driven) özetleyen bir tablo/not hazırla.

Sıradaki konu: Bölüm 6 — Konu 27: GetX (Tartışmalı Ama Yaygın)