React zihinsel modelleri: Dan Abramov tarzı düşünme yolları

Doğru zihinsel modelleriniz yoksa React neden zor gelir

React ilk başta sinir bozucu gelebilir çünkü UI'nin değiştiğini görürsünüz ama neden değiştiğini her zaman açıklayamazsınız. Bir düğmeye tıklarsınız, bir şey güncellenir ve sonra sayfanın farklı bir kısmı sizi şaşırtır. Bu genellikle “React garip” demek değildir. Asıl sorun “React'in ne yaptığına dair kafamdaki resim bulanık.”

Zihinsel model, bir şeyin nasıl çalıştığıyla ilgili kendinize anlattığınız basit hikâyedir. Eğer hikâye yanlışsa, kafa karıştıran sonuçlara yol açan emin kararlar verirsiniz. Termostatı düşünün: kötü model “22°C ayarlıyorum, oda anında 22°C olur.” Daha iyi model ise “Bir hedef ayarlıyorum ve ısıtıcı zaman içinde açılıp kapanarak hedefe ulaşmaya çalışır.” Daha iyi hikâye ile davranış rastgele hissetmeyi bırakır.

React de aynı şekilde çalışır. Birkaç net fikri benimsediğinizde React öngörülebilir olur: mevcut verilere bakıp ekranda ne olacağını güvenilir şekilde tahmin edebilirsiniz.

Dan Abramov bu “tahmin edilebilir yap” zihniyetini popülerleştirmede yardımcı oldu. Amaç kuralları ezberlemek değil. Kafanızda küçük bir doğrunun setini tutup hata ayıklamayı deneme-yanılma ile değil mantıkla yapabilmektir.

Aklınızda tutun:

• UI, elle yapılan DOM düzenlemelerinin sonucu değil, durumun bir sonucudur.
• Bileşenler, UI'nin nasıl görünmesi gerektiğini tanımlayan fonksiyonlardır.
• Veri aşağı akar; değişiklikler olaylar aracılığıyla yukarı çıkar.
• Yan etkiler (effects) render'dan ayrıdır ve belirli bir amacı vardır.

Bunları tutarsanız React sihir gibi gelmeyi bırakır. Güvenebileceğiniz bir sistem gibi hissettirir.

Bileşenler, props ve state: temel resim

React, “ekranlar” yerine küçük parçalarda düşünmeyi öğrendiğinizde kolaylaşır. Bir bileşen yeniden kullanılabilir bir UI birimidir. Girdiler alır ve bu girdiler için UI'nin nasıl görünmesi gerektiğinin bir tanımını döndürür.

Bir bileşeni saf bir tanım olarak görmek yardımcı olur: “bu veri verildiğinde, bunu göster.” Bu tanım bulunduğu yere bağlı olmadığı için birçok yerde kullanılabilir.

Props girdilerdir. Bir üst bileşenden gelirler. Props bileşenin “sahibi” değildir ve bileşenin bunları sessizce değiştirmesi doğru değildir. Bir buton label="Save" alıyorsa, butonun işi o etiketi render etmek, farklı olmasına karar vermek değildir.

State sahip olunan veridir. Bir bileşenin zaman içinde hatırladığı şeydir. State, kullanıcı etkileşince, bir istek bitince veya bir şeyin farklı olması gerektiğine karar verince değişir. Props'tan farklı olarak state o bileşene (veya sahip olarak seçtiğiniz bileşene) aittir.

Temel fikir sade haliyle: UI durumun bir fonksiyonudur. State “loading” diyorsa bir spinner gösterin. State “error” diyorsa bir mesaj gösterin. State “items = 3” diyorsa üç satır render edin. İşiniz UI'nın state'ten okumasını sağlamak, gizli değişkenlere kaymasını önlemektir.

Kavramları ayırmanın hızlı yolu:

• Bileşen: UI parçası (SearchBox, ProfileCard, CheckoutForm)
• Props: gösterebilmek için ihtiyaç duyduğu şeyler (name, price, disabled)
• State: hatırladığı şeyler (isOpen, query, selectedId)

Örnek: bir modal. Üst bileşen title ve onClose gibi props geçebilir. Modal isAnimating gibi bir state'e sahip olabilir.

Hatta sohbet aracılığıyla UI üretiyorsanız (örneğin Koder.ai üzerinde), bu ayrım en hızlı şekilde aklınızı başında tutar: önce neyin props, neyin state olacağını karar verin, sonra UI'ya bırakın.

Render ve yeniden render: gerçekte ne değişir

React'i kafanızda tutmanın faydalı bir yolu (Dan Abramov ruhuna uygun olarak): render bir hesaplamadır, bir boyama işi değil. React bileşen fonksiyonlarınızı çalıştırır ve mevcut props ile state için UI'nin nasıl görünmesi gerektiğini hesaplar. Çıktı piksel değil, bir UI tanımıdır.

Bir yeniden render demek React'in o hesaplamayı tekrar yapması demektir. Bu “tüm sayfa yeniden çiziliyor” demek değildir. React yeni sonucu öncekiyle karşılaştırır ve gerçek DOM'a en küçük değişiklik setini uygular. Birçok bileşen yeniden render olabilirken sadece birkaç DOM düğümü değişebilir.

Çoğu yeniden render birkaç basit sebepten olur: bir bileşenin state'i değişti, props'ları değişti veya bir üst bileşen yeniden render oldu ve React çocuktan tekrar render etmesini istedi. Bu sonuncusu insanları şaşırtır ama genelde sorun değildir. Render'ı “ucuz ve sıkıcı” olarak görürseniz uygulamanız daha kolay anlaşılır kalır.

Bu işi temiz tutacak kural: render'ı saf yapın. Aynı girdiler (props + state) verildiğinde bileşen aynı UI tanımını döndürmeli. Render içinde sürprizlere yer vermeyin.

Somut örnek: render içinde Math.random() ile bir ID üretiyorsanız, yeniden render ID'yi değiştirir ve aniden bir checkbox odağını kaybedebilir veya bir liste öğesi yeniden mount olur. ID'yi bir kez oluşturun (state, memo veya bileşen dışında) ve render stabil olur.

Hatırlamanız gereken bir cümle: bir yeniden render “UI'nin ne olması gerektiğini yeniden hesapla” demektir, “her şeyi yeniden kur” değil.

State güncellemeleri: değişiklikleri küçük ve öngörülebilir tutun

Başka faydalı bir model: state güncellemeleri isteklerdir, anlık atamalar değil. setCount(count + 1) gibi bir setter çağırdığınızda, React'e yeni bir değerle bir render planlamasını söylersiniz. Hemen sonra state'i okursanız eski değeri görebilirsiniz çünkü React henüz render etmemiştir.

Bu yüzden “küçük ve öngörülebilir” güncellemeler önemlidir. Mevcut değeri tahmin ederek almak yerine değişikliği tarif etmeyi tercih edin. Sonraki değer önceki değere bağlıysa updater formunu kullanın: setCount(c => c + 1). Bu, React'in çalışmasıyla uyuşur: birden fazla güncelleme sıraya alınabilir ve sonra sırayla uygulanır.

İmmütabilite (değişmezlik) resminin diğer yarısıdır. Nesneleri ve dizileri yerinde değiştirmeyin. Değişiklikle yeni bir tane oluşturun. React böylece “bu değer yeni” diyebilir ve beyniniz neyin değiştiğini izleyebilir.

Örnek: bir todo öğesini tersine çevirme. Güvenli yaklaşım yeni bir dizi ve değiştirdiğiniz öğe için yeni bir todo nesnesi oluşturmaktır. Riskli yaklaşım var olan dizinin içinde todo.done = !todo.done yapmaktır.

Ayrıca state'i minimal tutun. Yaygın bir tuzak, hesaplayabileceğiniz değerleri saklamaktır. Eğer zaten items ve filter varsa filteredItems'ı state'te saklamayın. Render sırasında hesaplayın. Daha az state değişkeni, değerlerin senkron dışına çıkmasının daha az yolu demektir.

State'e neyin ait olduğunun basit testi:

• Zaman içinde değişebilir ve UI tepki vermesi gerekiyorsa saklayın.
• Diğer state veya props'tan türetilebiliyorsa saklamayın.
• Aynı gerçeğin iki yerde kopyasını saklamayın.

Eğer sohbetle UI inşa ediyorsanız (Koder.ai dahil), değişiklikleri küçük yamalar olarak isteyin: “Bir boolean bayrak ekle” veya “Bu listeyi immutably güncelle”. Küçük, açık değişiklikler üreticiyi ve React kodunuzu uyumlu tutar.

Effect'ler senkronizasyon içindir, temel UI mantığı için değil

Rendering UI'yi tanımlar. Effect'ler dış dünya ile senkronize eder. “Dış dünya” dediğimiz React'in kontrol etmediği şeyler: ağ istekleri, zamanlayıcılar, tarayıcı API'leri ve bazen imperatif DOM işleri.

Bir şey props ve state'ten hesaplanabiliyorsa, genelde effect içinde olmamalıdır. Effect'e koymak ekstra bir adım ekler (render, effect çalışır, state ayarlanır, tekrar render). Bu ekstra adım titremelere, döngülere ve “neden bu eski?” tarzı hatalara yol açar.

Yaygın bir karışıklık: firstName ve lastName var ve fullName'i state'e koyup effect ile ayarlıyorsunuz. Ama fullName bir yan etki (side effect) değildir. Bu türetilmiş veridir. Render sırasında hesaplayın, her zaman eşleşir.

Alışkanlık olarak: UI değerlerini render sırasında (ve bir şey gerçekten pahalıysa useMemo ile) türetin; effect'leri “bir şey yap” işleri için kullanın, “bir şeyi çöz” işleri için değil.

Bağımlılık dizisi bir tetikçi listesidir

Bağımlılık dizisini şu şekilde düşünün: “Bu değerler değiştiğinde dış dünya ile yeniden senkronize ol.” Bu bir performans hilesi değildir ve uyarıları susturmak için kullanılmaz.

Örnek: userId değiştiğinde kullanıcı detayları çekiyorsanız, userId effect bağımlılık dizisine dahil olmalıdır çünkü bu senkronizasyonu tetiklemesi gerekir. Eğer effect token da kullanıyorsa onu da ekleyin, yoksa eski token ile fetch edebilirsiniz.

İyi bir içgüdü kontrolü: bir effect'i kaldırmak sadece UI'yı yanlış yapacaksa, muhtemelen gerçek bir effect değildi. Eğer kaldırmak bir zamanlayıcıyı durdurmayı, bir aboneliği iptal etmeyi veya bir fetch'i atlamayı engelliyorsa, muhtemelen gerçek bir effect'ti.

Veri akışı: dağınık state yerine tek gerçek kaynak daha iyi

En faydalı zihinsel modellerden biri basit: veri ağaç boyunca aşağı akar ve kullanıcı eylemleri yukarı çıkar.

Bir üst bileşen değerleri çocuklara geçirir. Çocuklar aynı değerin iki kopyasına gizlice “sahip” olmamalıdır. Değişiklikleri bir fonksiyon çağırarak isterler ve üst bileşen yeni değere karar verir.

UI'nın iki kısmı aynı konuda anlaşmak zorundaysa, değeri tek bir yerde saklayın ve aşağı verin. Buna “state lifting” denir. Başta ekstra boru döşüyormuş gibi gelse de daha kötü bir problemi önler: birbirinden uzaklaşan iki state ve bunları senkron tutmak için ek hack'ler eklemek.

Örnek: arama kutusu ve sonuç listesi. Eğer input kendi query'sini saklarsa ve liste kendi query'sini saklarsa, sonunda “input X gösteriyor ama liste Y kullanıyor” görürsünüz. Çözüm query'yi bir ebeveynde tutmak, ikisine aşağı vermek ve input'a onChangeQuery(newValue) handler'ı vermektir.

Her zaman lift etmek çözüm değildir. Bir değer sadece bir bileşen içinde önemliyse, orada tutun. State'i kullanıldığı yere yakın tutmak genellikle kodu daha okunur yapar.

Pratik bir sınır:

• Lokal state: yalnızca UI ile ilgili detaylar (dropdown açık mı, hangi sekme seçili)
• Paylaşılan state: birden fazla bileşenin anlaşması gereken veriler (filtreler, seçili öğe, auth durumu)

Kararsızsanız, şu işaretlere bakın: iki bileşen aynı değeri farklı şekillerde gösteriyor; bir yerdeki eylem uzağı etkiliyor; props'ları “ya olur diye” state'e kopyalıyorsunuz; veya iki değeri uyumlu tutmak için effect'ler ekliyorsunuz. Böyle işaretler varsa state'i yukarı taşıyın.

Bu model sohbet tabanlı araçlarla çalışırken de yardımcı olur: her paylaşılan state parçası için tek bir sahibi isteyin, sonra handler'ları yukarı doğru akacak şekilde üretin.

Adım adım: önce durumu çizerek bir özellik tasarlayın

Kafanızda tutabileceğiniz kadar küçük bir özellik seçin. İyi bir örnek aranabilir bir liste ve bir öğeye tıklayınca detayları modal içinde gösterme.

Önce UI parçalarını ve olabilecek olayları çizin. Henüz koda bakmayın. Kullanıcının ne yapabileceğini ve ne görebileceğini düşünün: bir arama input'u, bir liste, seçili satır vurgusu ve bir modal var. Olaylar: arama yazma, öğeye tıklama, modal açma ve modal kapatma.

Şimdi “durumu çizin.” Saklanması gereken birkaç değeri yazın ve kimin sahip olacağını karar verin. Basit bir kural işe yarar: değere ihtiyaç duyan tüm yerlerin en yakın ortak ebeveyni onu sahiplenmelidir.

Bu özellik için saklanan state küçük olabilir: query (string), selectedId (id veya null) ve isModalOpen (boolean). Liste query okur ve öğeleri render eder. Modal detayları göstermek için selectedId okur. Hem liste hem modal selectedId'e ihtiyaç duyuyorsa, onu her ikisinde değil üstte tutun.

Sonra türetilmiş veriyi saklamakla saklanan veriyi ayırın. Filtrelenmiş liste türetilmiş veridir: filteredItems = items.filter(...). Bunu state'te saklamayın çünkü her zaman items ve query'den yeniden hesaplanabilir. Türemiş veri saklamak değerlerin kaymasına yol açar.

Sadece sonra sorun: effect'e ihtiyacımız var mı? Eğer öğeler zaten bellekteyse hayır. Eğer bir query yazınca sonuçlar fetch edilecekse evet. Modal kapandığında bir şey kaydedilecekse evet. Effect'ler senkronizasyon içindir (fetch, save, subscribe), temel UI wiring için değil.

Son olarak birkaç kenar durumu kağıt üzerinde test edin:

• Hızlı yazı yazın, sonra temizleyin: liste normale döner mi?
• Bir öğeye tıklayın, sonra liste arama nedeniyle değişti: selectedId hâlâ geçerli mi?
• Modal kapatıldığında seçim korunur mu yoksa sıfırlanır mı?
• Öğeler sunucudan yenileniyor: seçili öğe kaybolursa ne olur?

Bunları kağıt üzerinde cevaplayabiliyorsanız, React kodu genellikle doğrudan gelir.

Zihinsel modeli bozan yaygın hatalar

Çoğu React kafa karışıklığı sözdizimsel değildir. Kodunuz kafanızdaki basit hikâyeyle uyuşmayı bıraktığında olur.

Hata kalıpları (ve fark ettiğiniz semptom)

Türemiş state saklamak. fullName'i firstName + lastName olduğu halde state'te saklıyorsunuz. Bir alan değişince diğer değişmeyebilir ve UI eski değer gösterir.

Effect döngüleri. Bir effect veri çekiyor, state ayarlıyor ve bağımlılık listesi bunun tekrar çalışmasına sebep oluyor. Semptom tekrarlanan istekler, titreyen UI veya hiç stabil olmayan state'tir.

Stale closure'lar. Bir click handler eski bir değeri okur (eski bir sayaç veya filtre gibi). Semptom “tıkladım ama dünün değerini kullandı.”

Her yerde global state. Her UI detayını global store'a koymak neyin sahibi olduğunu anlamayı zorlaştırır. Semptom bir şeyi değiştirdiğinizde üç ekranın beklenmedik şekilde tepki vermesi.

İç içe nesneleri değiştirmek. Bir nesne veya diziyi yerinde güncellersiniz ve neden UI güncellemediğini sorgularsınız. Semptom “veri değişti ama yeniden render olmadı.”

Somut bir örnek: bir liste için “arama ve sıralama” paneli. Eğer filteredItems'ı state'te saklarsanız, yeni veri geldiğinde items'tan sapma olabilir. Bunun yerine girdileri saklayın (search text, sort choice) ve render sırasında filtrelenmiş listeyi hesaplayın.

Effect'lerde, bunları dış dünyayla senkronize etmek için tutun (fetching, subscription, timer). Eğer bir effect temel UI işi yapıyorsa, genelde onun yerine render veya bir event handler içinde olmalıdır.

Sohbet yoluyla kod üretirken bu hatalar daha hızlı ortaya çıkar çünkü değişiklikler büyük parçalar halinde gelebilir. İyi bir alışkanlık, istekleri sahiplik açısından çerçevelemektir: “Bu değerin gerçek kaynağı neresi?” ve “Bunu saklayabilir miyiz yoksa hesaplayabilir miyiz?”

State karışık hissettirmeye başladığında hızlı kontrol listesi

UI'nız öngörülemez hissetmeye başladığında, nadiren “çok fazla React” sorunudur. Genelde yanlış yerlerde, gereksiz şeyler için çok fazla state vardır.

Başka bir useState eklemeden önce durun ve sorun:

• Kullanıcının şu an gördüklerini tam olarak tanımlayan en küçük değer kümesi nedir?
• Her değer nerede yaşamalı ki ona ihtiyaç duyanlar okuyabilsin ve ihtiyaç duymayanlar etkilenmesin?
• Bu değer gerçekten yeni bir bilgi mi, yoksa props, URL parametreleri veya diğer state'ten hesaplanabilir mi?
• UI hesaplamak için bir effect mi kullanıyorsunuz yoksa React'in kontrol etmediği bir şeyle mi senkronize oluyorsunuz (ağ, zamanlayıcı, tarayıcı API)?
• Bir değer değiştiğinde hangi bileşenlerin tekrar render olması gerekir, hangileri olmamalı?

Küçük örnek: arama kutusu, filtre dropdown, liste. Hem query hem filteredItems'ı state'te saklarsanız artık iki gerçek kaynağınız olur. Bunun yerine query ve filter'ı state'te tutun, sonra filteredItems'ı tam listeden render sırasında türetin.

Bu, sohbet araçlarıyla hızlı inşa ederken de önemlidir. Hız iyidir ama sürekli sorun sorun: “State ekledik mi yoksa yanlışlıkla türetilmiş bir değer mi ekledik?” Eğer türetilmişse o state'i silin ve hesaplayın.

Örnek: öngörülebilirliği kaybetmeden hızlı şekilde UI üzerinde yineleme yapmak

Küçük bir ekip bir admin UI inşa ediyor: sipariş tablosu, birkaç filtre ve bir siparişi düzenlemek için dialog. İlk istek belirsiz olabilir: “Filtreler ve bir düzenleme popup'ı ekle.” Bu basit görünse de genelde rastgele state her yere dağılır.

İsteği somutlaştırın: onu state ve olaylara çevirin. “Filtreler” yerine state adlandırın: query, status, dateRange. “Düzenle popup'ı” yerine olayı adlandırın: “kullanıcı bir satırda Düzenle'ye tıklıyor.” Sonra her state parçasının sahibi kim olacak (page, table veya dialog) ve hangi şeylerin türetilmiş olduğu kararını verin.

Koruyucu örnek istemler (bunlar Koder.ai gibi sohbet tabanlı üreticilerde de iyi çalışır):

• “OrdersPage oluşturun; filters ve selectedOrderId ona ait. OrdersTable filters ile kontrol edilsin ve onEdit(orderId) çağırsın.”
• “visibleOrders'ı orders ve filters'tan türetin. visibleOrders'ı state'e kaydetmeyin.”
• “EditOrderDialog ekleyin; order ve open props olarak alsın. Kaydettiğinde onSave(updatedOrder) çağırıp kapansın.”
• “Eğer veri çekiliyorsa, tek bir yerde tutun. Effect'i yalnızca filters'ı URL'e senkronize etmek için kullanın, satırları hesaplamak için değil.”

UI üretildikten veya güncellendikten sonra hızlı bir kontrol yapın: her state değerinin bir sahibi var mı, türetilmiş değerler saklanmamış mı, effect'ler sadece dış dünya ile senkronize ediyor mu (URL, ağ, depolama), ve olaylar props olarak aşağı akıp callback'lerle yukarı mı geliyor?

State öngörülebilir olduğunda yineleme güvenli hale gelir. Tablo düzenini değiştirebilir, yeni bir filtre ekleyebilir veya dialog alanlarını kırpabilirsiniz; hangi gizli state'in kırılacağını tahmin etmek zorunda kalmazsınız.

Sonraki adımlar: sohbetle daha hızlı inşa edin, ama React modelini koruyun

Hız yalnızca uygulama hâlâ anlaşılır kalıyorsa değerlidir. En basit koruma, bu zihinsel modelleri bir kontrol listesi gibi alıp her özelliğe uygulamaktır.

Her özelliğe aynı şekilde başlayın: ihtiyaç duyduğunuz state'i, onu değiştirebilecek olayları ve kimin sahip olacağını yazın. Eğer “Bu bileşen bu state'e sahip ve bu olaylar onu güncelliyor” diyemiyorsanız, muhtemelen state dağılacak ve yeniden render'lar sürpriz yapacaktır.

Eğer sohbet üzerinden inşa ediyorsanız önce planlama moduyla başlayın. Bileşenleri, state şekillerini ve geçişleri sade dilde tarif edin, sonra kod isteyin. Örnek: “Bir filtre paneli query state'ini güncelliyor; sonuç listesi query'den türetiliyor; bir öğe seçmek selectedId ayarlıyor; kapatmak onu temizliyor.” Bu temiz okunuyorsa, UI üretimi mekanik bir adıma dönüşür.

Eğer Koder.ai (koder.ai) ile React kodu üretiyorsanız, küçük bir sağduyu kontrolü yapmak faydalıdır: her state değeri için bir net sahip, UI state'ten türetilmiş, effect'ler sadece senkronize ediyor ve gerçek kaynağın iki kopyası yok.

Sonra küçük adımlarla yineleyin. State yapısını değiştirmek istiyorsanız (mesela birkaç boolean'dan tek bir status alanına geçmek), önce bir snapshot alın, denemeyi yapın ve eğer zihinsel model bozulduysa geri alın. Daha derin bir inceleme veya devralma gerektiğinde, kaynak kodunu dışa aktarmak durum yapısının hâlâ UI hikâyesini anlatıp anlatmadığını görmeyi kolaylaştırır.