Bölüm 6 — Konu 25: Riverpod (Modern Yaklaşım, Provider'ın Halefi)

#Riverpod Neden Var? — Provider'ın Sınırlamaları

Bir önceki derste Provider'ı öğrendik — güçlü bir araç, ama BuildContext'e bağımlı olmasından kaynaklanan bazı sınırlamaları var:

// Provider ile — context olmadan state'e erişemezsin
context.read<SepetModeli>().ekle('Ürün');

Bu, widget ağacının dışında (örneğin bir initState() dışı yardımcı fonksiyonda, ya da tamamen widget olmayan bir test kodunda) state'e erişmeyi zorlaştırır. Ayrıca, Provider'da aynı tipte birden fazla provider tanımlamak (örneğin iki farklı SepetModeli — belki bir "geçici sepet", bir "onaylı sepet") karmaşıklaşır.

Riverpod, aynı ekip (Provider'ın da yaratıcısı) tarafından geliştirilen, bu sınırlamaları çözen bir sonraki nesil state management çözümüdür. Önemli: "Riverpod", Provider'ın harflerinin anagramıdır (P-R-O-V-I-D-E-R → R-I-V-E-R-P-O-D) — bu, paketin Provider'ın ruhani halefi olduğunu isim düzeyinde bile gösteriyor.

Bir uyarı: Riverpod, zaman içinde API'sini bir kez büyük ölçüde değiştirdi. İnternette veya eski kaynaklarda göreceğin StateNotifier + StateNotifierProvider kalıbı artık eski (legacy) kabul ediliyor — hâlâ çalışıyor ama Riverpod ekibi yeni projelerde bunun yerine Notifier + NotifierProvider kullanılmasını öneriyor. Bu derste doğrudan güncel kalıbı öğreneceğiz.

#Paketi Ekleme

flutter pub add flutter_riverpod

#ProviderScope — Uygulamayı Sarmalamak

void main() {
  runApp(
    ProviderScope( // tüm provider'ları barındıran kök widget
      child: MyApp(),
    ),
  );
}

ProviderScope, tüm provider'ları (Riverpod'da "provider" terimi biraz farklı kullanılır — birazdan göreceğiz) barındıran, context'e bağımlı olmayan bir depoyu (store) temsil eder. runApp()'ın en dışına, bir kere, uygulamanın kökünde konur.

#Provider (Riverpod'un Kendi Terimi) — Basit, Değişmeyen Değerler

final versiyonProvider = Provider<String>((ref) => '1.0.0');

Dart Bölüm 5 Konu 21'de öğrendiğimiz fonksiyonları değişkene atama kavramını hatırlarsan — burada Provider<String>(...), bir fonksiyon alıyor ((ref) => '1.0.0', bir anonim fonksiyon), ve bu, global bir değişken gibi tanımlanıyor. Ama dikkat: bu gerçek bir global değişken değil — Riverpod'un kendi izole edilmiş deposunda yaşıyor (Dart Bölüm 12'de öğrendiğimiz kütüphane/scope kavramına benzer bir izolasyon).

#Notifier — Değişebilir State'i Tanımlamanın Güncel Yolu

Provider dersinde ChangeNotifier ile notifyListeners() çağırarak state güncellemesi yapmıştık. Riverpod'un güncel karşılığı Notifier sınıfıdır:

import 'package:flutter_riverpod/flutter_riverpod.dart';

class SepetNotifier extends Notifier<int> {
  @override
  int build() => 0; // başlangıç state — StatefulWidget'taki initState gibi düşünebilirsin

  void ekle() {
    state = state + 1; // 'state' özel bir alan — atama otomatik olarak dinleyicileri günceller
  }
}

final sepetProvider = NotifierProvider<SepetNotifier, int>(SepetNotifier.new);

Notifier<int> — Dart Bölüm 9'da öğrendiğimiz generic sınıf kullanımı burada net görülüyor: <int>, bu notifier'ın hangi tipte state tuttuğunu belirtiyor.

build() metodu — eski yaklaşımdan temel fark: Eski StateNotifier API'sinde başlangıç değeri constructor'da (super(0)) veriliyordu. Güncel Notifier API'sinde, tıpkı bir widget'ın build() metodu gibi, build() metodu çağrılır ve döndürdüğü değer başlangıç state'i olur. Bu tasarım, Riverpod'un widget yaşam döngüsüyle tutarlı bir mantık kurmasını sağlıyor — provider'lar da widget'lar gibi "yeniden inşa edilebilir" (örneğin ref.invalidate() ile).

SepetNotifier.new — bu, Dart'ın constructor tear-off sözdizimi: (ref) => SepetNotifier() yazmak yerine, doğrudan constructor'a bir referans veriyoruz (fonksiyonu değişkene atama kavramının constructor'lara uygulanmış hali). İkisi de aynı işi yapar, .new biraz daha kısa ve idiomatik.

Kritik fark — notifyListeners() yerine state =: Provider'da notifyListeners()'ı elle çağırıyorduk (Bölüm 6 Konu 24'ü hatırla). Riverpod'da, state alanına atama yapmak, otomatik olarak dinleyicilere haber verir — bu, Dart Bölüm 6'da öğrendiğimiz setter kavramına benzer bir "gizli mekanizma" (Riverpod'un kendi Notifier sınıfı, arka planda bir setter/getter kullanır).

NotifierProvider<SepetNotifier, int> — burada iki generic tip parametresi var: SepetNotifier (notifier class'ının kendisi) ve int (tuttuğu state'in tipi). Dart Bölüm 9'da öğrendiğimiz "birden fazla tip parametresi" kavramının (Map<K, V> gibi) burada tekrar kullanıldığını görüyorsun.

#Widget İçinde Kullanım — ConsumerWidget

class SepetIkonu extends ConsumerWidget { // StatelessWidget YERİNE ConsumerWidget!
  const SepetIkonu({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) { // EK bir parametre: WidgetRef!
    final sepetSayisi = ref.watch(sepetProvider);
    return Badge(
      label: Text('$sepetSayisi'),
      child: Icon(Icons.shopping_cart),
    );
  }
}

ConsumerWidget — Bölüm 2 Konu 5'te öğrendiğimiz StatelessWidget'ın Riverpod'a özel bir versiyonudur (Dart Bölüm 7'de öğrendiğimiz kalıtım hiyerarşisini hatırla — ConsumerWidget, aslında StatelessWidget'a çok benzer bir işlev görür ama Riverpod'un ref mekanizmasını build()'e ekler).

WidgetRef ref — bu, Provider'daki context.watch<T>() çağrısının yerini alan bir mekanizma. ref.watch(sepetProvider), tıpkı context.watch<SepetModeli>() gibi çalışır — ama context'e bağımlı değildir, ref üzerinden çalışır.

#ref.read() — Callback'lerde Kullanım

ElevatedButton(
  onPressed: () {
    ref.read(sepetProvider.notifier).ekle(); // .notifier ile NOTIFIER'a erişim
  },
  child: Text('Sepete Ekle'),
)

sepetProvider.notifier — Riverpod'da, ref.watch(sepetProvider) sadece state değerini (int) verir; metodları çağırmak için, .notifier ile notifier nesnesinin kendisine erişmen gerekir. Bu, Bölüm 6 Konu 24'te öğrendiğimiz Provider'daki context.read<SepetModeli>().ekle()'nin, biraz daha açık (explicit) bir versiyonu.

#ConsumerStatefulWidget — StatefulWidget + Riverpod

class SepetEkrani extends ConsumerStatefulWidget {
  const SepetEkrani({super.key});

  @override
  ConsumerState<SepetEkrani> createState() => _SepetEkraniState();
}

class _SepetEkraniState extends ConsumerState<SepetEkrani> {
  @override
  void initState() {
    super.initState();
    // burada ref, this.ref üzerinden erişilebilir
  }

  @override
  Widget build(BuildContext context) {
    final sepetSayisi = ref.watch(sepetProvider); // ConsumerState içinde 'ref' otomatik mevcut
    return Text('$sepetSayisi');
  }
}

Bu, Bölüm 2 Konu 6'da öğrendiğimiz iki-sınıflı StatefulWidget yapısının, Riverpod'a özel versiyonudur (ConsumerStatefulWidget + ConsumerState) — initState() gibi yaşam döngüsü metodlarına ek olarak, ref'e de erişim sağlar.

#Bir Adım İleri — Code Generation (@riverpod)

Riverpod ekibinin resmi olarak önerdiği en güncel yaklaşım, provider'ları elle yazmak yerine riverpod_generator paketiyle otomatik ürettirmektir (Dart Bölüm 13 Konu 66'da öğrendiğimiz build_runner mekanizmasını hatırla):

import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'sepet_provider.g.dart';

@riverpod
class SepetNotifier extends _$SepetNotifier {
  @override
  int build() => 0;

  void ekle() {
    state = state + 1;
  }
}

Bu kod, dart run build_runner build çalıştırıldığında, yukarıda elle yazdığımız NotifierProvider tanımını senin için otomatik üretir (üstelik daha az kod ve daha güçlü tip çıkarımıyla). Bu tutorial'da öğrenmeye devam ettiğimiz elle yazılan Notifier/NotifierProvider kalıbı, arka planda tam olarak neyin üretildiğini anlaman için gerekli temel — code generation'ı, bu temeli kavradıktan sonra kullanmak çok daha mantıklı olur. Şimdilik elle yazma kalıbına odaklanmamız yeterli.

#Provider vs Riverpod — Karşılaştırma

#Pratik Tavsiye

Yeni başlayan biri için, Provider ile başlamak (kavramları öğrenmek için) makul bir yoldur — az önce gördüğün gibi, Riverpod'daki kavramlar (watch, read, notifier pattern) Provider'ınkilere çok benziyor. Ama büyük, uzun soluklu bir proje için, Riverpod'un sunduğu daha güçlü tip güvenliği ve context bağımsızlığı, uzun vadede daha sürdürülebilir bir seçimdir. Bu tutorial'ın ilerleyen kısımlarında (özellikle Bölüm 8'de, ileri state management pattern'lerinde), her ikisini de göreceğiz.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Riverpod, Provider'ın BuildContext bağımlılığını ortadan kaldıran, daha güçlü tip güvenliğine sahip bir sonraki nesil state management çözümüdür.
• ProviderScope, uygulamanın kökünde bir kere sarmalayıcı olarak kullanılır; NotifierProvider + Notifier<T>, güncel state yönetim kalıbıdır (eski kaynaklarda göreceğin StateNotifierProvider/StateNotifier artık legacy).
• build() metodu, başlangıç state'ini döndürür (eski API'deki super(0) çağrısının yerini aldı); state = ... ataması, Provider'daki notifyListeners() çağrısının otomatikleştirilmiş halidir.
• ConsumerWidget/ConsumerStatefulWidget, ref parametresi aracılığıyla, context.watch/context.read'in Riverpod karşılığı olan ref.watch/ref.read'i kullanır.
• .notifier, sadece state değerine değil, notifier'ın metodlarına erişmek için kullanılır.
• Riverpod ekibinin resmi önerisi artık @riverpod code generation'dır — bu tutorial'da elle yazma kalıbını öğrenmek, arkasındaki mekanizmayı anlaman için tercih edildi.

#📝 Ödevler

• [ ] Notifier<int> ile basit bir sayaç yaz, NotifierProvider ile tanımla, ConsumerWidget ile ekrana bağla.
• [ ] ref.watch ile değeri gösteren, ref.read(...).notifier ile bir metodu çağıran bir buton yaz.
• [ ] ConsumerStatefulWidget kullanarak, initState() içinde bir işlem yapan (örn. bir başlangıç değeri ayarlayan) bir widget yaz.
• [ ] Aynı basit sepet uygulamasını (Bölüm 6 Konu 24'teki), bu sefer Provider yerine Riverpod ile yeniden yaz, iki yaklaşımı karşılaştır.
• [ ] Kendi cümlelerinle, "Riverpod'un BuildContext'e bağımlı olmaması neden değerli" sorusunu açıkla.

Sıradaki konu: Bölüm 6 — Konu 26: BLoC/Cubit Pattern (flutter_bloc)