Jordan Walke’in React’i nasıl bileşen tabanlı, deklaratif ve durum odaklı bir yaklaşımla modern ön yüz mimarisini yeniden şekillendirdiğini keşfedin.

Jordan Walke, Facebook’ta çalışırken React’i yaratan yazılım mühendisidir. React öncesinde ön yüzler genellikle sayfalar, şablonlar ve HTML, CSS ile JavaScript’i senkron tutmaya çalışan artan miktarda “yapıştırıcı kod” üzerine kuruluydu. Walke’in ana fikri modeli tersine çevirmekti: UI’yı zaman içinde yamalanan belgeler olarak görmek yerine, daha büyük özelliklere birleştirdiğiniz küçük, yeniden kullanılabilir bileşenlerden oluşan bir ağaç olarak ele alın.
Bu sadece yeni bir kütüphane değildi—UI ile ilgili çalışma biçimine dair yeni bir yoldu. Bir bileşen, arayüzün bir parçasını ihtiyacı olan mantık ve durumla paketler, sonra uygulamanın geri kalanına temiz bir arabirim (props) sunar. Bu, UI’yi tek ve kırılgan bir sayfayı düzenlemekten ziyade Lego tuğlalarıyla inşa etmeye benzetir.
React önemlidir çünkü ekiplerin:
Pratik fikirleri ele alacağız:
Uzman bir framework kullanıcısı olmanız gerekmez. Amaç zihinsel modeli netleştirmek—böylece iyi React kalıplarını tanıyabilir, yaygın yanlış anlamalardan kaçınabilir ve aynı ilkeleri React dışındaki ortamlarda da uygulayabilirsiniz.
React öncesinde birçok ekip zengin arayüzleri şablonları, jQuery tarzı DOM manipülasyonlarını ve “X olduğunda Y’yi güncelle” kurallarından oluşan büyüyen bir yığınla birleştirerek inşa ediyordu. Bu yöntem işe yarıyordu—ta ki UI karmaşıklaşana kadar.
Yaygın bir desen şuydu: veri al, HTML render et, sonra DOM’u doğrudan değiştiren event handler’lar ekle. Durum değiştiğinde (yeni bir öğe, doğrulama hatası, toggle), o duruma bağlı her yeri hatırlamak gerekiyordu.
Bunun yol açtığı hatalar örneğin:
Ekranlar geliştikçe aynı iş kuralları birçok handler’da kopyalanır: “alan boşsa düğmeyi devre dışı bırak”, “okunmamış öğeleri vurgula”, “sonuç yoksa boş durumu göster”. Gereksinimler değiştiğinde, her kopyayı güncellemek için ilgisiz dosyalarda arama yapmak zorunda kalırsınız.
Veri birkaç net yapı ile modellenebilir: gönderi listesi, kullanıcı nesnesi, filtreler kümesi. Ancak UI, durum kombinasyonlarını ekler: yükleniyor vs yüklendi, hata vs başarı, okunmuş vs okunmamış, düzenleme vs görüntüleme, filtrelenmiş vs filtrelenmemiş—genellikle bir arada.
Bir haber akışı hayal edin:
"UI durumun bir fonksiyonudur" gibi öngörülebilir bir kural yoksa, çakışabilecek birçok DOM düzenlemesini koordine etmek zorunda kalırsınız. React’in hedefi güncellemeleri güvenilir kılmaktı: veriyi/durumu değiştirin, UI her seferinde yeniden render olsun ve eşleşsin.
Bir bileşen, adlandırıp tek başına hakkında düşünebileceğiniz küçük bir kullanıcı arayüzü parçasıdır. Düz bir dille: bir bileşen girdiler alır ve bu girdiler için UI’nin nasıl görünmesi gerektiğini döndürür.
O “girdiler → çıktı” çerçevesi bileşen modelinin kalbidir. Ekranı tek bir büyük şablon olarak görmek yerine, amaçlı yapı taşlarına ayırırsınız—düğmeler, kartlar, menüler, formlar ve tüm bölümler—sonra bunları birleştirirsiniz.
React’ta en yaygın girdiler props (özellikler)dir. Props, bir bileşeni yapılandırmak için geçirdiğiniz değerlerdir: metin, sayılar, bayraklar, event handler’lar veya başka UI öğeleri.
Çıktı, bileşenin render ettiği UI’dir. Props değişirse, bileşen farklı bir çıktı üretebilir—DOM’u elle güncelleme arayışına girmeden.
Örneğin, bir Button bileşeni label, disabled ve onClick gibi props alabilir. Bir UserCard name, avatarUrl ve status alabilir. Bir bileşenin arabirimini (props) bir ürün şartnamesi gibi okuyabilirsiniz: “Bu UI’nin doğru render olması için neye ihtiyacı var?”
UI’yi bileşenlere ayırmak hızlıca karşılığını verir:
Modal, Input veya Dropdown birçok sayfada görünebilir.Bu, sayfa bazında markup kopyalayıp değiştirme alışkanlığından büyük bir kopuştur. Bileşenler kopyalamayı gereksiz (ve zamanla kabul edilemez) hâle getirir.
React, sizi UI’yi bir sistemi tasarlıyormuş gibi düşünmeye teşvik eder: bileşebilir parçalar olarak. Bir “Ödeme sayfası”, CheckoutPage içinde OrderSummary, ShippingForm ve PaymentMethod içeren bir bileşen ağacı olur. Her parça net girdilere ve net sorumluluğa sahiptir.
Bu bileşen odaklı düşünce, React’in ön yüz mimarisini değiştirmesinin ana sebeplerinden biridir. Ekipler için ortak bir tasarım ve geliştirme birimi sundu: bileşen.
React’in en büyük zihinsel değişimi deklaratif UI’dır: belirli bir durum için arayüzün nasıl görünmesi gerektiğini tarif edersiniz, ve React o durum değiştiğinde sayfayı güncelleme işini halleder.
Elemanları manuel bulup metin düzenlemek, sınıfları değiştirmek ve DOM’u senkron tutmak yerine, UI’nin “şeklini” tanımlamaya odaklanırsınız. Veri değiştiğinde UI yeniden tarif edilir ve React gereken en küçük değişiklik setini belirler.
JSX, JavaScript içinde HTML’e benzeyen bir sözdizimiyle bileşen yapısını yazmanın kullanışlı bir yoludur. Yeni bir şablon dilini baştan öğrenmek zorunda değilsiniz; JSX, “bu bileşen bu element ağacını render eder” için bir kısaltmadır.
Avantajı, markup ile onu gösteren mantığın birlikte yaşaması; bu da bileşenleri izole halde anlamayı kolaylaştırır.
İmperatif kod, UI’yi nasıl güncelleyeceğinize adım adım odaklanır:
// Imperative: manually keep the DOM in sync
function setLoggedIn(isLoggedIn) {
const el = document.querySelector('#status');
el.textContent = isLoggedIn ? 'Welcome back' : 'Please sign in';
el.classList.toggle('ok', isLoggedIn);
el.classList.toggle('warn', !isLoggedIn);
}
Deklaratif kod, mevcut durum için UI’nin ne olması gerektiğine odaklanır:
function Status({ isLoggedIn }) {
return (
\u003cp className={isLoggedIn ? 'ok' : 'warn'}\u003e
{isLoggedIn ? 'Welcome back' : 'Please sign in'}
\u003c/p\u003e
);
}
Render, saf bir açıklama olarak ifade edildiği için bileşenler genellikle daha okunur, incelemesi daha kolay ve yeniden düzenlemesi daha basittir. Tasarımcılar, ürün odaklı mühendisler ve yeni katılanlar sıkça JSX’i event handler’lar ve DOM mutasyonları arasında gezmek zorunda kalmadan takip edebilir.
Bu açıklık işbirliğini geliştirir: UI kararları tek bir yerde görünür ve değişiklikler arayüzde gizli yan etkilere yol açma olasılığı daha düşüktür.
"Durum" (state), kullanıcı UI ile etkileşirken değişebilen verilerdir. Bu, bir arama kutusundaki mevcut metin, bir menünün açık olup olmadığı, sepetteki öğeler veya bir ağ isteğinin sonucu olabilir. Değişebiliyorsa ve ekran bunu yansıtmalıysa, o veri durumdur.
React’in ana hamlesi, render’ı manuel DOM adımlarının sonucu olarak görmek yerine durumun bir sonucu olarak ele almaktır. Belirli bir durum için UI’nin nasıl olması gerektiğini tanımlarsınız. Durum güncellendiğinde React ilgili parçaları yeniden render eder.
Bu zihinsel model, "bir elementi bul, sonra metnini güncelle, ardından bu sınıfı değiştir" gibi yaklaşımdan farklıdır. Bunun yerine durumu güncellersiniz ve UI doğal olarak durumdan türetilir.
Tek yönlü veri akışı, verinin tek bir yönde hareket etmesi demektir:
Bu, nerede bir güncelleme olduğunu takip etmeyi kolaylaştırır: bir olay olur, state tek bir yerde değişir ve UI bu yeni durumdan yeniden oluşturulur.
function Counter() {
const [count, setCount] = React.useState(0);
return (
\u003cdiv\u003e
\u003cp\u003eCount: {count}\u003c/p\u003e
\u003cbutton onClick={() =\u003e setCount(count + 1)}\u003eAdd\u003c/button\u003e
\u003c/div\u003e
);
}
Burada count state’dir. Düğmeye tıklamak setCount ile durumu günceller. React sonra yeniden render eder ve paragraf yeni sayıyı gösterir. Hiçbir zaman doğrudan "DOM’u düzenlemiyorsunuz."
Aynı desen, liste filtreleme (state = filtre metni, UI = filtrelenmiş öğeler) veya form doğrulama (state = alan değerleri ve hatalar, UI = mesajlar) gibi durumlara ölçeklenir. Veri önce değişir; görünüm sadece sonucun yansımasıdır.
React’in ana fikri "sayfayı daha hızlı yeniden çizmek" değil. İdea şudur: UI’yi durumun sonucu olarak ele al, ve durum değiştiğinde şimdi ne istediğinizle önce neye sahip olduğunuzu karşılaştır—sonra yalnızca gerçekten değişenleri güncelle.
Bir bileşenin state’i veya props’ı değiştiğinde, React bileşenlerinizi tekrar çağırarak yeni bir UI betimlemesi üretir. Bunu iki anlık görüntü almak gibi düşünebilirsiniz:
React tüm DOM’u temizleyip yeniden inşa etmek yerine A’dan B’ye geçmek için gereken minimum DOM işlemlerini hesaplamaya çalışır.
"Sanal DOM", React’in UI’nin hafızadaki hafif temsilidir—ekranda ne olması gerektiğini tanımlayan elementlerin ve bileşen çıktılarının hafif bir ağacı. Bu ikinci bir tarayıcı veya daha hızlı bir DOM değildir. React’in veriyi verimli şekilde inceleyip karşılaştırabileceği bir veri yapısıdır.
Reconciliation, önceki sanal ağaç ile yeni olan arasındaki farkları hangi değişiklikler ile hesaplayacağını belirleme sürecidir. React bunu hızlı yapmak için bazı sezgilere dayanır, örneğin:
<div> bir <span> değildir)React neyin değiştiğini öğrendikten sonra gerçek DOM’a hedefli güncellemeler uygular.
Bu sihir değildir. Performans kullanılan desenlere bağlıdır: stabil key’ler, gereksiz yeniden render’lardan kaçınma, bileşen işinin küçük tutulması ve render sırasında pahalı hesaplamalardan kaçınma. React DOM değişimini azaltabilir, ama uygulamanın akıcılığını belirleyen sizin bileşen yapınız ve veri akışınızdır.
React’in en büyük ölçeklenme taktiği bir özellik veya eklenti değil—kompozisyondur: bileşenleri iç içe koyarak, props ile veri aktararak ve children kullanarak bir bileşenin diğer UI’yi "sarmasına" izin vererek ekranları inşa etmek.
Takımlar kompozisyona sarıldıkça, tek seferlik sayfalar yerine yeniden düzenlenebilir küçük, güvenilir parçalardan düşünmeyi öğrenirler.
childrenİç içe geçirme, UI yapısının görsel karşılığıdır: bir sayfa bölümler içerir, bölümler kartlar içerir, kartlar düğmeler içerir. Props yapılandırma düğmeleridir (metin, durum, callbacks). children, yapıyı sağlayan ama içeriği çağıranın belirlemesine izin veren bileşenler oluşturur.
İyi bir zihinsel model: props özelleştirir, children doldurur, iç içe geçirme birleştirir.
Yerleşim (layout) bileşenleri yapı ve boşluk tanımlar; iş mantığını sahiplenmezler: Page, SidebarLayout, Stack, Modal. Genellikle children kullanırlar, böylece aynı layout birçok farklı ekranı sarmalayabilir.
Yeniden kullanılabilir inputlar form davranışı ve stilini standartlaştırır: TextField, Select, DatePicker. Etiketleri, hata durumlarını ve doğrulama mesajlarını ekranlarda kopyalamak yerine merkezi hale getirirsiniz.
Liste ve öğe bileşenleri tekrarlanan UI’yi öngörülebilir kılar. Yaygın bir ayrım ItemList (getirme, sayfalandırma, boş durumlar) ve ItemRow (tek bir öğenin nasıl göründüğü) şeklindedir.
Hooks, durumlu davranışı (toggle’lar, form state, veri çekme) bileşenler arasında UI şeklini zorlamadan yeniden kullanmanın modern yoludur. Bu ayrım, tasarım evrilirken mantığın tutarlı kalmasına yardımcı olur.
Kompozisyon, tasarım sistemlerinin tutarlı kalmasını sağlar: bileşenler "onaylanmış" yapı taşları olur ve layout’lar boşluk ile hiyerarşi kurallarını belirler. Sistem güncellendiğinde—renkler, tipografi, etkileşim durumları—ürünler daha az manuel düzenleme ile iyileşmelerden faydalanır.
Durum sadece "değişebilen veri"dir. React’ta bu state’in nerede tutulduğu, verinin kendisi kadar önemlidir.
Yerel state tek bir bileşene (veya küçük bir bileşene) ait olmalı ve başkası tarafından okunmasına gerek yoksa dışarı verilmemelidir. Örnek: bir dropdown açık mı, bir input’un mevcut değeri, hangi sekmenin seçili olduğu.
Bu durumu yerelde tutmak koordinasyonu azaltır ve bileşenleri yeniden kullanılabilir kılar. Kural: sadece bir bileşen ilgileniyorsa, durumu uygulamanın geri kalanına çıkarmayın.
Paylaşılan uygulama durumu, UI’nin birden fazla kısmının aynı veriye katılmasının gerektiği durumlarda gerekir. Örnekler:
Birden fazla bileşen aynı doğruluk kaynağına ihtiyaç duyduğunda, durumu kopyalamak uyumsuzluklara yol açar ("üstbilgi 3 öğe diyor, sepet sayfası 2 diyor").
State’i yukarı taşıma: durumu en yakın ortak ebeveyne alın ve props ile aşağı verin. Bu genellikle en basit seçenektir.
Context: birçok bileşenin aynı değere prop zinciri olmadan ihtiyaç duyduğu durumlar için kullanışlıdır (tema, auth gibi). Context, nispeten stabil, uygulama-genel konular içindir.
Harici store’lar: durum karmaşıklaştığında (sık güncellemeler, türetilmiş veri, sayfalar arası iş akışları), özel bir store mantığı ve güncellemeleri merkezileştirebilir.
React’in tek yönlü veri akışı, her durum parçasının net bir sahibi olduğunda en iyi sonucu verir. Pratikte tek bir doğruluk kaynağı hedefleyin ve geri kalanları ondan türetin.
React’in günlük kullanımda en büyük faydası render hilesi değil—bileşen sınırlarının UI işini küçük, daha güvenli değişikliklere bölmesidir. Bir bileşen net bir sorumluluğa ve stabil bir “kamu yüzüne” (props) sahipse, ekipler iç detayları refactor edebilir, uygulama genelinde yeniden yazma zorunluluğu olmadan. Bu stabilite kod incelemelerini kolaylaştırır, kazara kırılmaları azaltır ve yeni ekip üyelerinin nerede değişiklik yapacağını anlamasını hızlandırır.
Faydalı bir zihinsel model: props ve state verildiğinde, bir bileşen öngörülebilir şekilde UI’yi tarif etmelidir. Efektler ve tarayıcı API’leri olsa da, bileşen mantığının çoğu deterministik kalabilir. Bu yüzden sürdürülebilir testler genellikle davranışa ve çıktıya odaklanır:
Erişilebilirlik kontrolleri buraya doğal olarak sığar: roller ve erişilebilir isimler kullanarak test ederseniz, eksik etiketleri, bozuk odak durumlarını ve anlamsız semantikleri erken yakalarsınız. Tutarlılık kontrolleri (linting, formatlama, tasarım-sistem kullanımı) aynı fikri güçlendirir: öngörülebilir bileşenler daha kolay sürdürülebilir.
Bileşenler küçük bir prop API’si sunup uygulama detaylarını sakladığında, birden fazla kişi paralel çalışabilir—biri stili ayarlar, diğeri veri çekmeyi değiştirir, bir başkası testleri günceller—ve birbirlerinin işine fazla müdahale etmezler.
React performansı genelde "React yavaş" söyleminden ziyade uygulamanın tarayıcıya ne kadar iş yükü yüklediğiyle ilgilidir. En hızlı UI en az iş yapan UI’dır: daha az DOM düğümü, daha az layout/reflow, daha az pahalı hesaplama ve daha az ağ turu.
Sık rastlanan sorun gereksiz yeniden render’lardır: küçük bir state değişikliği, durum çok üstte tutulduğu veya props kimliği her seferinde değiştiği için büyük bir alt ağaçta yeniden render’a yol açar.
Bir diğer klasik sorun uzun listelerdir—yüzlerce veya binlerce satırda resimler, formatlama ve event handler’lar. Her satır “ucuz” olsa da toplam iş birikir ve kaydırma takılgan olur.
Yapıyı gözden geçirin:
Ayrıca kullanıcıların hissettiği şeyi önemseyin: giriş gecikmesini azaltın, ilk anlamlı boyamayı hızlandırın ve etkileşimleri akıcı tutun. Sık kullanılan bir etkileşimde 20ms’lik bir iyileşme, nadir görülen bir ekranın 200ms’lik hızlanmasından daha önemli olabilir.
Türetilmiş durum, diğer state/props’dan hesaplanabilen (örn. fullName = firstName + lastName, veya filtrelenmiş öğeler bir liste + sorgudan) veridir. Bunu saklamak genellikle hatalara yol açar çünkü artık iki doğruluk kaynağınız olur ve senkronizasyon kayması oluşabilir.
Hesaplanan değerleri render sırasında (veya pahalıysa memoize ederek) elde edin. Sadece türetilemeyenleri saklayın—genellikle kullanıcı girişi, sunucu yanıtları ve UI niyeti gibi değerleri.
React sadece UI yazmanın daha güzel bir yolunu sunmadı; ekiplerin ön yüzleri nasıl inşa ettiği, paylaştığı ve sürdürdüğü konusunda yeniden düzenlenmeye itti. Bileşen varsayılan zihinsel model haline gelmeden önce birçok proje UI’yi dağınık script’ler ve şablonlar olarak ele alıyordu. React ile mimarinin birimi giderek bileşen oldu: props ile net bir API’ye ve öngörülebilir davranışa sahip bir UI parçası.
React, tek sayfa uygulamaları (SPA) yükselişine iyi uydu. Render durum tarafından yönlendirildiğinde, "sayfa" artık sunucudan gelen bir şablon olmaktan çıkıp bileşen kompozisyonu ve istemci tarafı yönlendirmesi haline geldi. Bu kaydırma, kodu ayrı HTML dosyaları etrafında değil, özellik alanları ve yeniden kullanılabilir UI parçaları etrafında yapılandırmayı yaygınlaştırdı.
UI yeniden kullanılabilir parçalardan inşa edildiğinde bu parçaları standartlaştırmak doğal hale gelir. Birçok organizasyon markup kopyalamaktan komponent kütüphanelerine geçti: düğmeler, form kontrolleri, modallar, layout primitifleri ve boş durum gibi kalıplar. Zamanla bu kütüphaneler tasarım sistemlerine dönüşür—paylaşılan bileşenler ve rehberler—takımların her ekran için UI’yi yeniden icat etmeden tutarlı deneyimler sunmasını sağlar.
Bileşenler ekiplerin aynı adlandırmayı kullanmasını teşvik etti. Herkes \u003cButton\u003e, \u003cTooltip\u003e veya \u003cCheckoutSummary\u003e diye konuştuğunda, tartışmalar daha somut hale gelir: insanlar davranış ve sınırlar hakkında konuşur, sadece görsel değil. Bu ortak sözlük yeni katılanların koda daha hızlı adapte olmasını sağlar.
React’in başarısı diğer framework’leri de etkiledi: bileşen-öncelikli geliştirme, deklaratif render ve öngörülebilir veri akışı daha geniş beklentiler haline geldi. Uygulama detayları farklı olsa da, bu uygulamalar ekiplerde daha ölçeklenebilir bulunduğu için benimsendi.
React, karmaşık UI’leri evriltmeyi kolaylaştırarak ün kazandı; ama bu ücretsiz değil. Karşılaşılacak ödünleri bilmek, takımları doğru sebeplerle benimsemeye ve kutuplaşmış kararlar almamaya yardımcı olur.
React’in öğrenme eğrisi vardır: bileşenler, hook’lar ve state güncelleme/etki modelleri zaman alır. Modern React genellikle derleme aracıları (bundler, linting, TypeScript opsiyonel ama yaygın) varsayar; bu da kurulum ve bakım ek yükü getirir. Son olarak, React soyutlama katmanları (bileşen kütüphaneleri, routing, veri çekme kalıpları) sunar—bunlar yardımcı olur ama bir şey bozulduğunda karmaşıklığı da saklayabilir.
"React yalnızca görünüm katmanıdır." Teoride evet; pratikte React mimarinizi güçlü biçimde şekillendirir. Bileşen sınırları, state sahipliği ve kompozisyon deseni veri akışını ve kodun organizasyonunu etkiler.
"Sanal DOM her zaman daha hızlıdır." Sanal DOM öngörülebilir güncellemeler ve geliştirici ergonomisiyle ilgilidir. React hızlı olabilir, ama performans render desenlerine, memoizasyona, liste boyutlarına ve gereksiz yeniden render’lardaki kaçınmaya bağlıdır.
React, çok sayıda etkileşim durumuna sahip, uzun ömürlü kod tabanları ve paralel çalışan birçok geliştiricinin olduğu uygulamalar için uygundur. Genellikle statik bir pazarlama sitesi veya birkaç küçük widget için sunucu tarafı render, hafif JS veya basit framework’ler daha kolay ve daha az maliyetli olabilir.
Eğer bir React uygulaması prototiplemek ve bu fikirleri hızlıca doğrulamak istiyorsanız (bileşen sınırları, state sahipliği, kompozisyon desenleri), "vibe-coding" iş akışı yardımcı olabilir. Örneğin, Koder.ai ile sohbet halinde özellik tanımlayarak çalışan bir React ön yüz, Go/PostgreSQL arka uç oluşturabilir, sonra anlık görüntüler/geri alma ile yineleyip kaynak kodunu dışa aktarabilirsiniz. Bu, tam bir projeye başlamadan önce gerçek bir özellik üzerinde mimari kararları test etmenin pratik bir yoludur.
Sonraki adım: gerçek bir özelliği prototipleyin, karmaşıklığı ve ekip hızını ölçün, sonra desenleri kasıtlı olarak ölçeklendirin—varsayılan olarak değil.
Jordan Walke, Facebook’ta çalışırken React’i yaratan yazılım mühendisi olarak bilinir. React önemlidir çünkü kırılgan, elle yönetilen DOM “yapıştırıcı kodunu” bileşen tabanlı, durum odaklı bir yaklaşımla değiştirdi—karmaşık arayüzleri ölçeklendirmeyi, hata ayıklamayı ve sürdürmeyi kolaylaştırdı.
Şablonlar ve dağıtık event handler’lar genellikle UI kurallarını markup ile birlikte birçok farklı yere yayar ("X olduğunda, Y’yi güncelle"). Bileşenler UI + mantığı küçük bir arayüzün (props) arkasına paketler; böylece özellikleri zaman içinde sayfaları yamalamak yerine öngörülebilir parçalardan oluşturursunuz.
Bir bileşen, girdiler (genellikle props) alıp bu girdilere karşılık UI’nin neye benzeyeceğini döndüren yeniden kullanılabilir bir birimdir.
Uygulamada hedef:
Props, bir bileşeni yapılandırmak için geçirilen girdilerdir (metin, bayraklar, geri çağırmalar veya diğer UI). Props’a sözleşme gibi bakın:
disabled, onSubmit gibi net isimleri tercih edinDeklaratif UI, mevcut durum için arayüzün ne olması gerektiğini tarif etmek anlamına gelir; DOM’u adım adım nasıl güncelleyeceğinize odaklanmazsınız.
Pratikte:
JSX, JavaScript içinde HTML’e benzeyen bir sözdizimiyle bileşen yapısını yazmanıza olanak verir. Yarar: render mantığı ile onu kontrol eden markup bir arada durur; bu da bileşeni tek bir birim olarak okumayı ve incelemeyi kolaylaştırır.
Durum (state), kullanıcı etkileşimi sırasında değişebilen ve ekranda yansıtılması gereken veridir (arama kutusu içeriği, menü açık/kapalı, sepet öğeleri, ağ isteği sonucu vb.).
Pratik kural: kaynağı olan veriyi saklayın (kullanıcı girişi, sunucu yanıtları, UI niyeti) ve geri kalanları bu veriden türetin (sayım, filtrelenmiş listeler).
Tek yönlü veri akışı şunu ifade eder:
Bu, hata ayıklamayı kolaylaştırır çünkü güncellemeyi tek bir çizgide izleyebilirsiniz: olay → state değişimi → yeniden render.
Sanal DOM, React’in UI’nin bellek içi temsili olan veri yapısıdır. State/props değiştiğinde React önceki UI betimlemesiyle yenisini karşılaştırır ve yalnızca gereken gerçek DOM güncellemelerini uygular.
Kaçınmak için:
key değerleri kullanınBasit başlatın ve gerektiğinde genişletin:
Mümkünse tek bir doğruluk kaynağı tercih edin ve diğer değerleri ondan türetin.