State Management Seçerken Yaptığım 5 Büyük Hata

İlk projem Redux'la başladı. Herkes Redux diyordu, ben de Redux yaptım. Üç ay sonra 200 satırlık reducer dosyalarıyla boğuşurken anladım: ben bu projeye Redux'ın gücünü vermedim, Redux bana gereksiz kompleksiteyi verdi.

O günden bu güne beş kütüphane daha denedim. Hata yaptım, öğrendim. Bunları paylaşmak istiyorum.

1. Proje Boyutu Yerine Trend Seçmek

Redux, MobX, Zustand, Jotai, Recoil... Her biri farklı bir ihtiyaca cevap veriyor. Ben Redux seçtim çünkü "büyük uygulamalar için" diye okudum. Ama benim uygulama 15 sayfa, 3-4 global state'ten ibaretti. Redux Toolkit bile fazla geldi.

Gerçek: Zustand'ın 2KB boyutu ve 5 satırlık setup'ı benim için yeterliydi. Proje başında "bu büyüyebilir" diye düşünmek, genellikle hiç büyümüyor.

2. DevTools'u Göz Ardı Etmek

State kütüphanesi seçerken debugging araçlarını önemsememiştim. Redux DevTools harika ama React Query ile çalışırken Redux'a ihtiyacım olmadığını fark ettim. Zustand'da DevTools desteği var ama kurulumu daha basit. Jotai'de ise hata ayıklama biraz daha zor.

Gerçek: Üretim ortamında state değişikliklerini izlemek, bazen feature'dan daha önemli. Kütüphane seçmeden önce DevTools ekosistemini kontrol et.

3. Async İşlemleri Kütüphaneye Yüklemek

Redux-Thunk ve Redux-Saga'ya takılıp kaldım. Aslında React Query veya SWR, veri fetching için çok daha iyi. State management ile data fetching'i karıştırdığım için gereksiz middleware yüklü bir yapı oluşturdum.

Gerçek: Global state, UI state için. API çağrıları, veri kütüphanelerine bırak.

4. Boilerplate Seviyesini Yanlış Hesaplamak

Zustand'ın minimal syntax'ı çok hoşuma gitti; Redux'ın action-reducer-dispatch döngüsünü unutmaya başladım. Sonra Jotai'ye geçtim. Her kütüphane farklı bir mental model istiyor. Proje ortasında model değiştirmek, refactor acısı.

Gerçek: Boilerplate az = öğrenme eğrisi az. Ama takım büyükse, convention'lar önemli hale geliyor.

5. Performans Optimizasyonunu Sonraya Bırakmak

State güncellendiğinde tüm consumer'lar re-render oluyordu. Zustand'da atom-based kütüphanelere (Jotai, Recoil) geçince fark ettim: granular subscriptions, çok daha verimli.

Gerçek: Başlangıçta performans sorun değilse, ama milyonlarca state update'i olacaksa, atom-based mimariye bakılması lazım.

Sonuç

Herhangi bir kütüphane "en iyisi" değil. Proje ihtiyacını, takım bilgisini ve debugging workflow'unu birlikte değerlendir. Redux'tan Zustand'a geçen bir proje, Redux'tan React Query + Jotai'ye geçenden çok daha az acı çeker.