Tepki: On Yıllık “En İyi Uygulamaları Yeniden Düşünmek”

Saberie

Active member
React, Mayıs 2013’te açık kaynak dünyasında gün ışığını gördüğünde “Kullanıcı arabirimleri geliştirmek için bir JavaScript kitaplığı” basit slogandı. Bugün – on yıl sonra – birçok geliştiricinin günlük yaşamının ayrılmaz bir parçası. React, tek sayfa uygulama (SPA) geliştirme için en çok kullanılan kitaplıklardan biri olarak kabul edilir. Bu kütüphaneyi sadece Facebook ve React’i geliştiren ve açık kaynak olarak yayınlayan ana şirketi Meta değil, Jira, Figma, Microsoft Outlook ve Teams gibi birçok tanınmış ürün de onunla geliştirilmektedir.


En iyi uygulamaları yeniden düşünmeye devam edin


React, o zamanlar web ve masaüstü için yerleşik UI kitaplıklarından farklı birçok şey yaptı ve bugün hala yapıyor. Bu alternatif yaklaşım için, en başından beri React’in geliştiricisi olan Pete Hunt, JSConf 2013’teki bir sunumda hala geçerli olan sloganı ortaya attı: “En İyi Uygulamaları Yeniden Düşünmek” (videoya bakın). Bu itibarla, kütüphanenin tarihine en iyi uygulamalardaki bazı temel değişiklikler damgasını vurmuştur. ECMAScript 6 sırasında, sınıflar da React’e girdi, birkaç yıl sonra geliştirme ekibi, yalnızca JavaScript işlevleriyle React bileşenlerini geliştirmeyi mümkün kılan Hooks API ile devam etti. Yakın geçmişte, istemci tarafı tek sayfalık uygulamalardan (SPA’lar) çalışma zamanında bir JavaScript sunucusu gerektiren ve bu nedenle tercihen tam yığın çerçevelerle oluşturulması gereken tam özellikli React uygulamalarına doğru bir geçişin işaretleri olmuştur.


Önerilen editoryal içerik



İzninizle, buraya harici bir YouTube videosu (Google Ireland Limited) yüklenecek.



Her zaman YouTube videoları yükleyin

YouTube videosunu şimdi yükleyin



React geliştiricisi Pete Hunt, JSConf 2013’teki bir sunumda hala geçerli olan “En İyi Uygulamaları Yeniden Düşünmek” sloganını ortaya attı.




JavaScript ve başka hiçbir şey


Tarihsel olarak, React ekibi, farklı programlama dillerini ve şablonları karıştırırken meydana gelenler gibi, değişiklikleri kırmamak için her zaman dikkatli olmuştur: bu nedenle bileşenler, yalnızca JavaScript ile yazılmıştır. Birçok kullanıcı arabirimi kitaplığında olduğu gibi şablon dili yoktur. Bunun yerine React, JSX JavaScript dil uzantısıyla birlikte gelir. Bu uzantı, XML kodunu doğrudan JavaScript koduna yazmanıza olanak tanır. Derleme işlemi sırasında bir derleyici, tarayıcıların anlayabileceği geçerli JavaScript kodunun oluşturulmasını sağlar. Bunun arkasındaki fikir: geliştiriciler arabirim oluşturmak için bir JavaScript kitaplığı kullanıyorsa, yine de JavaScript dilini bilmeleri veya öğrenmeleri gerekir. İkinci bir dil (model) öğrenmek yerine, JavaScript uzantılarını kullanabilirler. React ekibinin anlayışına göre, JSX bu nedenle bir şablon dili değil, JavaScript için yalnızca “sözdizimsel şeker”dir. Mevcut React belgeleri, “React’i öğrenmek, kodlamayı öğrenmektir” diyor.


React’teki Model View Controller (MVC) modeli gibi popüler mimari kalıpları da boşuna arayacaksınız. React, örneğin model, görünüm ve denetleyici gibi bireysel teknik parçalara (“endişelerin ayrılması”) ayrılmayı kasıtlı olarak önler ve bir bileşene ait olan her şeyi doğrudan bu bileşene yoğunlaştırır. Bu şekilde, teknik olarak birbirine ait olan kod bir arada kalmalı ve birden çok yere “yapay” olarak dağıtılmamalıdır. Bu, bileşenlerde yapılan değişikliklerin veya uzantıların yalnızca kullanıcı arayüzünde, modelde veya mantık katmanında ayarlamalarla sonuçlanmadığı, aynı zamanda tüm katmanların genellikle değişikliklerden etkilendiği, bu nedenle zahmetli bir şekilde bunlar arasında gidip gelmeniz gerektiği varsayımına dayanır. bir bileşenin parçaları. Ayrıca, bir bileşenin münferit teknik parçaları genellikle diğer bileşenlerde yeniden kullanılamaz, bu nedenle bir ayırma da bu nedenle anlamsız görünür. Sonuç olarak, React’te tüm bileşen yeniden kullanılabilir tek varlıktır.


Bugüne kadar değişmeyen şey, React uygulama geliştirmenin bileşen durumunu en iyi şekilde kullanmak etrafında dönmesidir. Bu, bir giriş alanının geçerli içeriği gibi düzenlenebilir dahili bileşen verileridir. Bu veriler değiştiğinde, React, tüm temel bileşenler dahil olmak üzere durumu değişen bileşenin yeniden oluşturulmasını tetikler. React’te iki yönlü veri bağlama yoktur, yani arayüz değişikliklerini (örneğin, bir metin alanına girdikten sonra) bir bileşenin modeline veya durumuna otomatik olarak aktarma yeteneği. Genellikle olaylar tarafından tetiklenen (metin alanı değiştirildi, onay kutusu seçildi, sunucudan veri geldi…) bu tür değişikliklere istenen tepki, React’teki bileşene açıkça programlanmalıdır. React’te bir bileşenin yaşam döngüsü bu nedenle çok basittir: ilk oluşturmadan sonra bileşen istenen kullanıcı arayüzünü döndürür. Olay dinleyicileri, döndürülen UI öğelerinde ayarlanabilir. Bir olay meydana gelirse, bileşen olayı işleyebilir (metin alanı değişti) ve dahili durumu güncelleyebilir. Sonuç olarak React, bileşeni yeniden oluşturur ve döngü yeniden başlar.

Tek Doğruluk Noktası: Bir bileşenin durumu


React’te, veriler her zaman bileşenler arasında yukarıdan aşağıya, yani en üstteki bileşenlerden en alttakilere doğru iletilir. React’in tek yönlü veri akışından da bahsetmesinin nedeni budur: veriler sistem boyunca yalnızca tek yönde akar. Diğer UI mimarilerinde, bileşenlerin birbirini tanıması, örneğin bir denetleyici tarafından ayrılması ve değişiklikler hakkında birbirini bilgilendirmesi veya dinleyiciler aracılığıyla bilgilendirmesi yaygın bir durumdur. Bu mimarideki sorun, hangi verinin ne zaman ve nasıl değişeceğinin her zaman net olmaması olabilir: hangi dinleyiciler hangi değişikliğe ve ne zaman tepki verir? Hangi değişiklik olay işleyicilerini yeniden tetikler? En kötü durumda, bu, arayüzü gereksiz yere yavaşlatan olay basamaklarına veya “olay fırtınalarına” yol açar.

React, bu sorunu tek yönlü bir veri akışıyla karşılar: gerçeğin tek bir kaynağı vardır ve bu, bir bileşenin durumudur. Ancak bu yaklaşım, birçok bileşenin kullanması gereken bir durumun, bileşen hiyerarşisinde giderek daha yukarılara taşınması anlamına gelir. React’te “durum kaldırma” ilkesinden bahsedilir.

Bu model, uygulamaları anlamak için çok yararlı olsa ve tipik tutarsızlık sorunlarını önleyebilse de, aynı zamanda bir dezavantajı vardır: durumu daha üst düzey bileşenlere “yukarı itmek”, durumu ve mantığı aşırı yüklenmiş olan çok karmaşık bileşenleri hızlı bir şekilde oluşturabilir. Daha derinde bulunan bileşenler daha sonra saf ekran bileşenlerine indirgenir. İkincisi, kolayca test edilebildikleri ve muhtemelen kolayca yeniden kullanılabildikleri için sorun çıkarmazlar, ancak hiyerarşinin tepesindeki karmaşık “Tanrı bileşenleri” bir zorluk teşkil eder ve birkaç nedenden dolayı bir darboğaz oluşturabilir: ilk olarak, test edilmeleri zordur diğer yandan, geliştirme yaklaşımının ölçeklenebilirliğini sınırlarlar. Çünkü en kötü durumda, birkaç özellik tek bir bileşende toplanır, böylece birkaç ekip onu geliştirmek zorunda kalabilir.



Haberin Sonu
 
Üst