Geçen ay, Mart 2026’da İstanbul’daki bir ürün toplantısında yine o tartışma açıldı: “Bu formu Redux’a mı koyalım?” Masadaki herkes başını salladı — kulağa düzenli geliyor çünkü. Ama işin aslına bakarsanız, formlar o kadar canlı bir şey ki onları merkezî bir depoda tutmaya çalışınca iş biraz tuhaf bir hal alıyor. Her tuşa basışta değişiyorlar, sonra gönderiliyorlar ve çoğu zaman da — puf — çöpe gidiyorlar. Tam bir geçici misafir yani.
Ben bu dersi ilk kez 2018’de bir e-ticaret panelinde, canım yanarak öğrendim. O dönemde her form alanını store’a bağlamıştık; gayet “mimarî” görünüyordu hani, şık bile sayılırdı. Sonra kullanıcı adres alanına iki harf yazınca bile sayfa ağırlaşmaya başladı. Açık konuşayım — o proje bana şunu öğretti: Her state aynı sepete atılmaz. Bazısı evde oturur, bazısı ise kapıdan girer girmez ölmelidir zaten.
Evet, doğru duydunuz.
Asıl mesele global mi local mi değil
Bak şimdi. Bu tartışmada herkesin kafası genelde yanlış yere gidiyor. Sanki seçenekler sadece “her şeyi global yap” ya da “hepsini component içinde sakla” gibiymiş gibi davranılıyor — halbuki daha iyi soru başka: Bu state ne kadar yaşamalı?
Form state’in garip tarafı tam da burada ortaya çıkıyor. Bir yandan uygulamanın geri kalanıyla uyumlu olmak istiyorsun; debug etmek kolay olsun, gerektiğinde başka yerden de erişilsin istiyorsun. Bir yandan da bu verinin ömrü zaten kısa, kullanıcı formu açtıysa yaşasın kapattıysa gitsin. İşte tam bu noktada “alive vs dead” ayrımı devreye giriyor (inanın bana)
Geçen sene Eylül 2025’te Ankara’da bir SaaS projesinde bunu birebir gördüm. Destek ekibi sürekli “Neden eski taslaklar geri geliyor?” diye soruyordu — meğer form state’i temizlenmeden tutuluyormuş, kullanıcı submit ediyor. Store unutamıyordu. Hani bilgisayar değil de hafızalı bir sekreter gibi davranıyordu sistem; ne söylesen aklında tutuyor, siz de “yeter artık unut” diyemiyorsunuz.
Form state’i global olabilir; ama sonsuza kadar yaşamak zorunda değil. Asıl sorun nerede tuttuğunuz değil, ne zaman öldürdüğünüz.
redux-form neden duvara tosladı?
Redux’un parlak günlerinde hepimiz biraz fazla hevesliydik (ben de ilk duyduğumda şaşırmıştım). Tek kaynak doğruluk fikri kulağa çok düzgün geliyordu; her şey merkezî olsun, her şey izlenebilir olsun. Kağıt üstünde süperdi yani. redux-form da tam bu mantığın üzerine kuruldu: alan değerleri, validation hataları, touched bilgisi, submission durumu derken tüm form hayatı store’a taşındı — ve bir süre sonra ortalık felç oldu.
Şunu söyleyeyim, Gel gelelim pratik başka konuştu. Form gönderildiğinde veriler store’da kalmaya devam etti, ortalık stale data ile doldu taştı. Kullanıcı aynı formu tekrar açınca eski değerler bazen kendiliğinden geri geliyordu; bazen de reset çağırmayı unuttuğunuz için hayalet veriyle saatlerce uğraşıyordunuz. Ben buna ilk baktığımda “çok akıllıca” demiştim… Sonra iki hafta içinde aynı projede kendime kızdım. Epey kızdım açıkçası.
Bir de performans kısmı var. Her keystroke bir action demekti; her action da bağlı bileşenlerde yeniden render baskısı yaratıyordu. Küçük formlarda idare ediyor, tamam — ama 25 alanlı uzun formlarda işler çirkinleşiyor. Yavaşlık çok dramatik olmuyor belki, kullanıcı fark etmeyebilir bile bilinçli olarak, ama bir şeyler hissediyor. İşte en tehlikelisi o.
Durun, bir saniye.
Formik ve React Final Form neyi doğru yaptı?
Aslında, Formik’in yaptığı şey aslında bayağı sadeydi. Formu lokal tut, Redux’u rahat bırak. useState. UseRef ile işi component içinde hallettiğinizde dünya dönmeye devam ediyor — özellikle küçük ve orta ölçekli ürünlerde bu yaklaşım ciddi rahatlık veriyor, kod daha okunur oluyor, debugging daha az baş ağrıtıyor. Basit ama işe yarıyor. Bu kadar.
React Final Form biraz daha rafine bir yol seçti. Erik Rasmussen burada önceki dersini ciddiye almış belli ki; subscription modeli ile sadece ilgili alanları yeniden çizdirerek performansı toparladı. Küçük bir fark gibi görünüyor ama büyük formlarda resmen nefes aldırıyor — bunu söylerken abartmıyorum. Bu konuyla ilgili Cursor’da “Make No Mistakes” Dönemi Başlıyor: Küçük Ama Kurnaz Bir Hamle yazımıza da göz atmanızı tavsiye ederim.
Bunu Haziran 2024’te İzmir’de test ettiğim bir CRM ekranında net gördüm. Eski yapı tüm formu tekrar tekrar boyarken, Final Form benzeri yaklaşımda yalnızca değişen alan kıpırdıyordu — odadaki tek lambayı açmak gibi bir şey bu, geri her şey karanlıkta kalıyor, sadece lazım olan yanıyor. Aradaki his farkı kullanıcıya direkt yansıyor zaten. Bu konuyla ilgili Otomatik Pentest Yetmez: Webinarın Anlattığı Asıl Ders yazımıza da göz atmanızı tavsiye ederim.
| Yaklaşım | Nerede iyi çalışır? | Zayıf yani |
|---|---|---|
| Redux-form tarzı merkezi yapı | Karmaşık workflow’lar, güçlü denetim ihtiyacı | Ağırlaşabilir, stale data bırakabilir |
| Formik / local state | Klasik CRUD formları, hızlı geliştirme | Büyük senaryolarda ek disiplin ister |
| React Final Form / subscription modeli | Büyük formlar, hassas performans gereksinimi | Öğrenme eğrisi biraz daha dik olabilir |
Peki hangi senaryoda hangisi mantıklı?
Küçük startup için
Beş kişilik bir ekipten söz ediyorsak ve ürününüzün ana derdi hızlı çıkmaksa — forma aşırı felsefe yüklemeyin derim. Local state çoğu zaman işinizi görür; hatta fazla düşünmeyince daha sağlıklı karar verirsiniz kimi zaman (buna dikkat edin). Gerçekten.
Kurumsal projede
Doğrusu, Büyük ekiplerde mesele biraz farklılaşıyor tabii. Standart önemli oluyor, audit önemli oluyor, hata ayıklama önemli oluyor. Ama yine de tüm form yaşamını sonsuza dek store’da tutmak şart değil — kurumsalda bile bazı formlar doğar doğmaz ölmelidir; yoksa store şişer (en azından benim deneyimim böyle). Kimse nedenini anlayamaz. Ciddi söylüyorum, anlayamaz. Daha fazla bilgi için Dijital Oyunlarda Yeni Vergi Dalgası: Türkiye’de Ne Değişiyor? yazımıza bakabilirsiniz.
Kritik veri girişlerinde
Söz konusu ödeme ekranıysa ya da regülasyon yoğun bir süreçse daha kontrollü davranmak gerekebilir —. Dikkat edin, kontrollü olmak ile gereksiz yere her şeyi merkezileştirmek aynı şey değil. Bazen server-side draft mantığı bile yeterli olur. Bazen daha azı gerçekten daha fazladır.
İnanın, Lafı gevelemeden söyleyeyim: En iyi çözüm çoğu zaman “state’i nereye koyacağım?” sorusu değil, “bu state ne zaman silinecek?” sorusudur (yanlış duymadınız). Bir dakika, şunu da ekleyeyim — iyi form mimarisi sadece input yönetmek değildir; hata mesajının ömrünü de yönetmektir.
// Basit düşünce modeli
if (form.isOpen) {
keepAlive(form.state);
} else {
destroy(form.state);
}Neden “öldürmek” bazen en temiz çözümdür?
Dürüst olayım. “Destroy” kelimesi biraz sert geliyor olabilir — ama teknik olarak çok yerinde bir metafor, bu yüzden seviyorum onu. Gerçek hayatta bazı nesneler kalıcı değildir: modal açılır kapanır, draft kaybolur, anket tamamlanır biter, checkout ilerler ve geçmişiyle ilgilenmez. Bunları sürekli saklamaya çalışmak hem zihinsel hem teknik yük oluşturuyor.
Biz bazen yazılımda unutmayı beceremiyoruz. Halbuki unutmak da tasarımın parçasıdır — hafızanın sınırı var ve bu kötü bir şey değil, tam tersine, iyi tasarlanmış sistemde faydalıdır. Kirli geçmişi arkada sürüklemezsiniz, yeni oturum temiz başlar, kullanıcı da “neden eski değer geldi?” diye irkilemez. Bunun adı sadeliktir. Tembellik değil, sadelik.
Neyse uzatmayayım. Benzer prensibi geçen yıl Kasım 2025’te Berlin’de çalışan bir fintech takımında gözlemledim — üretim hatalarının yarısı aslında yanlış zamanda yaşayan UI state yüzündendi. Form kapanmıştı ama validation flag hâlâ aktifti; ya da taslak resetlenmemişti. Ekip sonunda lifecycle disiplinine geçtiğinde hem bug sayısı düştü hem destek talepleri azaldı. Beklediğimden iyi çıktı doğrusu. Kimse mucize beklemiyordu zaten — sadece doğru şeyi doğru zamanda silmek yetmişti. Fazlası yoktu, eksik vardı tabii, ama işe yaradı.
- Açıkça tanımlanmış yaşam süresi olan state kullanın.
- Taslak gerekiyorsa süre koyun ya da manuel silme sağlayın. (bu kritik)
- Touched/error/dirty gibi UI durumlarını domain verisinden ayırın.
- Büyük formlarda alan bazlı subscription veya izolasyon düşünün.
Kendi notum: Redux’un suçu yoktu, alışkanlığımız vardı
Bence redux-form meselesinin en öğretici tarafı şu oldu: araç kötü değildi, kullanım şeklimiz ağırdı. Bakın, o dönemde her probleme merkezî çözüm arıyorduk çünkü düzen hissi veriyordu — bu his çok çekici, inkâr edemem. Sonra fark ettik ki bazı problemler doğal olarak geçici. Formlar tam da öyle. Bugünkü hali yarın yoktur, resmen yaşayan böcek gibi görünürler. Yapay Zekâ Ajanı Akıllı Değil: Asıl Güç Araçlarda yazımızda da bu konuya değinmiştik. 2029 Kapıda: Kuantum Güvenliğe Geçişte Neler Değişiyor? yazımızda da bu konuya değinmiştik.
Evet, doğru duydunuz.
Editör masasında bu konuyu yazarken içimdeki eski frontendçi hemen kaşındı diyebilirim — yıllarca ben de tekil doğruluk fikrine fazla güvendim. Şimdi ise şunu düşünüyorum dürüstçe: local olması gerekeni lokal tutmak insanı hafifletiyor. Enterprise dünyasında bile bunu yapmak mümkün, yeter ki sınırlar net olsun. Aksi halde store çöplüğe dönüşüyor — ve sistem çöp kutusuna döndüğünde, mimari diye alkışlayacak hal kalmıyor maalesef.
Sıkça Sorulan Sorular
Form state neden Redux’ta tutulmamalı?
Zorunlu olarak tutulmaması gerekmez ama çoğu durumda gereksiz yük getirir. Formlar kısa ömürlüdür. Sık değişir; bu yüzden store’u şişirebilirler. Ayrıca reset edilmediğinde eski veri sızıntıları çıkarabilirler.
Formik mi React Final Form mu daha iyi?
Kullanım senaryosuna göre değişir. Daha basit projelerde Formik yeterince rahattır. Büyük ve performans hassasiyetinin yüksek olduğu yapılarda React Final Form’un subscription yaklaşımı daha avantajlı olabilir.
Touched ve error state domain verisinden ayrı mı olmalı?
Evet, genelde ayrı olmalı. Çünkü bunlar iş mantığından çok arayüz davranışıyla ilgilidir. Domain verisini kirletmeden UI durumunu yönetmek bakım açısından çok daha temizdir.
Bir form submit olduktan sonra otomatik silinmeli mi?
Cevap senaryoya bağlıdır. Taslak gerekiyorsa saklayabilirsiniz; ama tek seferlik işlemlerde submit sonrası temizlemek çoğu zaman en sağlıklısıdır. Böylece kullanıcı tekrar geldiğinde eski gölge veriyle karşılaşmaz.
Kaynaklar ve İleri Okuma
Bak şimdi, React Final Form Resmî Sitesi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
