Açısal Rönesans Bölüm 1: Sunucu Tarafı İşleme ve Hidrasyon

Saberie

Active member
Bu üç bölümlük makale serisinde sunulan Angular 17 serisinde (17.0, 17.1, 17.2 ve 17.3) bazı yeni özellikler tanıtıldı. İlk bölüm, sunucu tarafı işleme ve hidrasyon yeniliklerini kapsıyor. Hidrasyon, tarayıcıda JavaScript'in bir sonraki aktivasyonunu gösterir. İkinci bölüm, sinyaller ve halihazırda kullanımda olduklarında ne gibi faydalar sundukları ile ilgilidir. Son olarak, kontrol akışını iyileştiren ve ertelenmiş görünümlerle öncü çalışmalar yapan yeni model sözdizimi ile ilgilidir. Ertelenmiş görünümler, diğer çerçevelerdeki kodlarla gerçekleştirilen HTML kullanarak karmaşık görevleri bildirimsel olarak çözmenize olanak tanır.

Duyuru








Rainer Hahnekamp, AngularArchitects.io uzman ağının eğitmeni ve danışmanıdır ve Angular'ın tüm yönleriyle ilgili eğitimlerden sorumludur. Ayrıca YouTube'daki ng-news ile haftalık olarak Angular ortamındaki ilgili etkinliklere kısa bir genel bakış sağlar.







Açısal rönesansın zirvesinde


Angular 17, Kasım 2023'ün başlarından beri mevcuttur. Yakın zamanda yayınlanan 17.3 sürümü artık güncel. Büyük sürümden iki gün önce, sözde “Açısal Rönesans”ın resmi açılışını yapan ve aynı zamanda yeni bir logonun sunulduğu büyük bir etkinlik gerçekleşti.

“Rönesans”ın başlangıç noktası esasen sürüm 14'tü (Mayıs 2022'de yayınlandı). Halen devam ediyor ancak Angular 17 zaten bir dönüm noktası olarak kabul ediliyor. Kullanışlı yeni özelliklerle birlikte gelir ve sürüm 16 ile birlikte gelişmiş nemlendirme ve yüksek performanslı sinyal bileşenlerinin önünü açar.

Yeni özelliklerden herhangi birini kullanmaya gerek kalmadan güncelleme mümkündür. En yeni Angular 17.3 sürümü sinyaller olmadan NgModules ile de çalışır @Input/@Outputwebpack ve eski yapısal direktifler gibi *ngIf VEYA *ngFor. Radikal değişiklikler yapmadan yenilik yaratmak, çok az çerçevenin başarabildiği bir başarıdır.

Her zaman olduğu gibi Angular CLI, şu komutu kullanarak güncellemeler sunar: ng update Destek. Ayrıntılı hazırlık talimatları ve gerekli manuel adımlar Angular web sitesinde mevcuttur.

Açısal olarak esbuild


Uzun yıllardır webpack, Angular'ın CLI'sinde üretim yapısı ve geliştirme modu oluşturmak için kullandığı araç olmuştur. Şimdi bitti. Yıllardır araç sektöründe araçların yeni versiyonlarının artık JavaScript'te değil, Go veya Rust gibi native kod üreten dillerde geliştirildiği yönünde bir trend var. Bu onları belirgin şekilde daha hızlı hale getirir.

Vite.js, ön uç alanında webpack'in resmi olmayan halefi olarak kabul edilir. Derleme aracı, Go'da yazılan esbuild'i temel alır. esbuild, sürüm 17'den beri Angular'daki varsayılan oluşturucudur. Önceki sürümlerde, esbuild için deneysel destek zaten mevcuttu ve bu artık kararlıdır.

Angular 17 ile yeni bir proje oluşturursanız (ng new), yapacak başka bir şey yok. angular.json dosyasında zaten aşağıdadır builder giriş @angular-devkit/build-angular:application.

Mevcut bir uygulama için esbuild'den faydalanmak için seçim yapmakta zorlanacaksınız. SSR'siz hafif versiyon için bu yeterlidir @angular-devkit/build-angular:browser-esbuild. İsmin değiştirilmesi dışında başka bir değişikliğe gerek yoktur.

SSR destekli programın tamamı biraz daha çalışma gerektiriyor. İlk adım kurulumdur @angular-devkit/build-angular:application bir inşaatçı olarak. Entegre SSR, resmi belgelerde açıklanan ek parametreler gerektirir.




Resimde, ApplicationBuilder'ın etkin olduğu angular.json dosyası gösterilmektedir.



Resimde, ApplicationBuilder'ın etkin olduğu angular.json dosyası gösterilmektedir.


(Fotoğraf: Rainer Hahnekamp)



Büyük projeleri dönüştürürken, yeni bir alanda paralel bir Angular uygulaması kullanmak mantıklıdır npm init @angular@17 ve ardından yeni angular.json'u mevcut olanla karşılaştırın.

Modül federasyonu tabanlı mikro ön uçlar için esbuild'e geçiş biraz daha fazla çaba gerektirir. Modül federasyonu webpack'in özel bir özelliği olduğundan esbuild'de eşdeğeri yoktur. Ancak modern tarayıcılar artık içe aktarma haritaları ve “Native Federasyon for Angular” eklentisi yardımıyla mikro ön uçları kendileri yönetebiliyor. Arka planda yalnızca teknoloji değiştirildi. Operasyon ve yaklaşım aynı kaldı.

Peki esbuild'e geçmeye gerçekten değer mi? Rakamlar kendileri için konuşuyor. Esbuild kıyaslaması çoklu performans artışı gösteriyor.




Farklı paketleyicilerle JavaScript karşılaştırması



Farklı paketleyicilerle JavaScript karşılaştırması


(Resim: esbuild)



Elbette bu tür verilere her zaman dikkatle yaklaşılmalıdır. Ancak er ya da geç esbuild'i kullanmayı bırakamayacaksınız. Açısal ölçümlere göre SSR ön işlemesi olmayan bir inşaat sürecinde %67'ye kadar hız artışı bekleyebilirsiniz.






Enterprise JavaScript enterJS konferansı 7 ve 8 Mayıs'ta Mainz'da gerçekleşecek. Organizatörler dpunkt.verlag VE iX genel olarak JavaScript, özel olarak çerçeveler ve ayrıca programlama diliyle ilgili araçlar ve teknikler gibi konularda 35'in üzerinde konuşma ve üç atölye çalışması sunacak.

Programdan alıntı:





Sunucu tarafı oluşturma


Ön uç alanında nereye bakarsanız bakın, tüm çerçeveler sunucu tarafı oluşturma (SSR) veya nemlendirme üzerinde çalışmakla meşguldür. SSR olmadan son kullanıcıların uygulamayla ilgili herhangi bir şeyi görmesi biraz zor olabilir.

Sunucu genellikle JavaScript dosya referanslarıyla birlikte boş HTML gönderir. Tarayıcının bunları ayrı ayrı indirmesi, ayrıştırması ve yürütmesi gerekir. Yalnızca ön uç çerçevesi çalıştığında çalışır ve uygulamayı gerçekten işler. SSR ile sunucu zaten tam işleme gerçekleştiriyor. Sunucu, oluşturulan HTML ve CSS'yi tarayıcıya gönderir ve ardından JavaScript dosyalarını teslim eder.

Avantajı açıktır: Sayfa sunucuda önceden oluşturulmuşsa, tarayıcıya teslimat çok daha hızlı olur. Kullanıcılar daha sonra uygulamayı hemen görürler. Ancak JavaScript hâlâ yeniden yüklenmekte olduğundan bu henüz dinamik değil. JavaScript kodunun tarayıcıya yeniden yüklenmesine ve entegre edilmesine hidrasyon adı verilir.




Hidrasyonun grafiksel gösterimi



Hidrasyonun grafiksel gösterimi


(Fotoğraf: Rainer Hahnekamp)




Haberin Sonu
 
Üst