Ugrás a tartalomhozReact Query cache invalidation — production kodundan 6 kalıp
“invalidateQueries'i çağırın, yeter” tavsiyesi vakaların %20'sini karşılar. Kalan %80 için bu 6 kalıba ihtiyacınız var.
Cache invalidation zordur. Bu yüzden iyi kütüphaneler onu gizlemez — size sadece daha keskin bıçaklar verir.
React Query, 2026 frontend yığınının en faydalı parçalarından biri. Nortinia'daki her Next.js projesi onu kullanıyor. Dokümantasyonu iyi, ancak pratik cache invalidation kalıpları yazılı değil. Aşağıdaki altı kalıp gerçek production kodundan geliyor — ve bizi haftada bir kez hatalı istemci tarafı durum senkronizasyonundan kurtarıyor.
1. Basit invalidate
Klasik yöntem: başarılı bir mutation'dan sonra queryClient.invalidateQueries({ queryKey: ["projects"] }). Projelere ait tüm cache'ler geçersiz olur ve yeniden çekilir. Vakaların %80'inde doğru. Kalan %20'de yanlış — gereğinden fazlasını geçersiz kılarız; 50 paralel sorguda bu hem yavaş hem pahalıdır.
2. İyimser güncelleme (optimistic update)
Kullanıcı tıklar, sonucu anında görür, ağ çağrısı arka planda çalışır. Cache'i mutation'ın onMutate aşamasında önceden güncelleriz, hata olursa geri alırız. Bu kalıp toggle'lar, sürükle-bırak ve hızlı düzenlemeler için ideal — Nortinia yönetim uygulamalarında 30'dan fazla yerde kullanıyoruz.
3-6. İleri düzey kalıplar
- 3. setQueryData ile hassas yama: queryClient.setQueryData cache'i doğrudan değiştirir — tek bir projenin tek bir alanını güncelleyin, yeniden çekmeye gerek yok
- 4. Kısmi anahtar invalidation: queryKey: ["projects", "list"] liste sorgularını geçersiz kılar, detay sorgularına dokunmaz
- 5. Predicate tabanlı invalidation: queryClient.invalidateQueries({ predicate }) — örneğin filter.status değeri "active" olan her sorgu
- 6. Zincirleme invalidation event'leri: backend websocket → istemci tarafı invalidate → UI yenilemesi. Birden fazla kullanıcının aynı fatura üzerinde çalıştığı Finance Suite'te kullanıyoruz
En büyük ders şu: cache invalidation tek bir kalıp değil, altı kalıptır. Her özellik için hangisinin doğru olduğuna siz karar verirsiniz. Yalnızca 1. kalıbı kullanırsanız arayüzünüz gerektiğinden daha taze olur ve performans düşer. Her yerde setQueryData'ya yaslanırsanız hız kazanırsınız ama hata ayıklama zorlaşır, çünkü cache ile backend birbirinden kopabilir.