React 19

 (github.com/facebook)
2 puan yazan GN⁺ 2024-12-06 | 1 yorum | WhatsApp'ta paylaş

19.0.0 (5 Aralık 2024)

Yeni özellikler

React
  • Actions: startTransition artık asenkron fonksiyonları kabul edebiliyor. Bu fonksiyonlar "Actions" olarak adlandırılır; durumu arka planda günceller ve UI'ı tek seferde commit eder. Actions, asenkron istekler gibi yan etkiler gerçekleştirebilir ve Transition tamamlanmadan önce işlemin bitmesini bekler.
  • useActionState: Transition içinde Actions'ları sıralamaya ve duruma erişmeye olanak tanıyan yeni bir hook. Başlangıç durumu ve reducer kabul eder.
  • useOptimistic: Transition sürerken durumu güncelleyen yeni bir hook. Transition tamamlandığında durum yeni değerle güncellenir.
  • use: Render sırasında kaynakların okunmasını sağlayan yeni bir API. Promise veya Context kabul eder; bir Promise verilirse değer çözülene kadar askıya alınır.
  • ref'in prop olarak kullanımı: forwardRef gerekmeden ref, prop olarak kullanılabilir.
  • Suspense kardeşlerini önceden ısıtma: Bir bileşen askıya alındığında React, en yakın Suspense sınırının fallback'ini hemen commit eder.
React DOM istemcisi
  • <form> action prop'u: Form Actions, formları otomatik olarak yönetir ve useFormStatus ile entegre olur. Başarı durumunda formu otomatik olarak sıfırlar.
  • Belge meta verisi desteği: Belge meta verisi etiketleri bileşenlerden yerel olarak render edilebilir.
  • Stil sayfası desteği: Suspense sınırındaki içeriği göstermeden önce istemcinin <head> bölümüne stil sayfaları ekler.
  • Asenkron script desteği: Bileşen ağacının herhangi bir yerinde asenkron script'ler render edilebilir.
React DOM sunucusu
  • prerender ve prerenderToNodeStream API'leri eklendi: Statik site üretimi için API'lerdir; Node.js stream'leri ve web stream'leri gibi akış ortamlarında çalışacak şekilde tasarlanmıştır.
React Server Components
  • RSC özellikleri: Direktifler, server component'ler ve server function'lar kararlı hale geldi. Server component içeren kütüphaneler artık React 19'u peer dependency olarak hedefleyebilir.

Kullanımdan kaldırılacaklar

  • element.ref erişimi: element.props.ref tercih edilerek element.ref erişimi kullanımdan kaldırılıyor.
  • react-test-renderer: React 19'da react-test-renderer, kullanımdan kaldırma uyarısı kaydeder ve web kullanımı için concurrent rendering'e geçer.

Önemli değişiklikler

React
  • Yeni JSX dönüşümü zorunlu: Bundle boyutunu iyileştiren ve React'i import etmeden JSX kullanımını sağlayan yeni JSX dönüşümü artık gerekli.
  • Render hataları yeniden fırlatılmıyor: Hata bir Error Boundary tarafından yakalanmazsa window.reportError aracılığıyla raporlanır.
  • propTypes kaldırıldı: propTypes kullanımı sessizce yok sayılır. TypeScript'e geçiş önerilir.
  • Fonksiyonlarda defaultProps kaldırıldı: Bunun yerine ES6 varsayılan parametreleri kullanılabilir.
  • String ref'ler kaldırıldı: String ref kullanımı, ref callback'lerine taşınmalıdır.
React DOM
  • react-dom/test-utils kaldırıldı: act, react-dom/test-utils içinden react'a taşındı. Diğer yardımcılar kaldırıldı.
  • ReactDOM.render, ReactDOM.hydrate kaldırıldı: Concurrent rendering için ReactDOM.createRoot ve ReactDOM.hydrateRoot ile değiştirildi.

Dikkat çeken değişiklikler

React
  • Sağlayıcı olarak <Context> kullanımı: <Context.Provider> yerine sağlayıcı olarak <Context> render edilebilir.
  • Custom element desteği: React 19, tüm custom element testlerini geçer.
  • StrictMode değişiklikleri: useMemo ve useCallback, ilk render'ın memoization sonucunu yeniden kullanır.
React DOM
  • Hydration hatalarında fark gösterimi: Uyumsuzluk oluştuğunda React 19, uyumsuz içeriğin farklarını içeren tek bir hata kaydeder.

TypeScript değişiklikleri

  • Örtük return yasaklandı: ref'ler artık yalnızca cleanup function kabul eder. Örtük return hata oluşturur.
  • useRef için başlangıç argümanı gerekli: Başlangıç argümanı artık zorunlu.
  • Daha sıkı ReactElement tiplemesi: React element'lerinin props'ları artık varsayılan olarak any yerine unknown olur.

İlgili okumalar

1 yorum

 
GN⁺ 2024-12-06
Hacker News yorumları

  • Burada neden bu kadar çok kişinin React’ten hoşlanmadığını pek anlamıyorum.
    Kariyerime Laravel ve saf JS ile başladım; React’i kullandıktan sonra ölçeklenebilir uygulamalar yapmak gerçekçi gelmeye başladı ve frontend de eğlenceli hale geldi.
    Şirket değişse bile React’i yeniden kavramak kolay; TypeScript desteği ve büyük ekosistemi sayesinde ne olursa olsun oldukça kolayca bir şeyler geliştirip büyütebildiğim hissini veriyor.
    Yeni özelliklerin insanları neden korkuttuğunu da anlamıyorum. Hâlâ SPA ya da eski yöntemlerle geliştirebilirsiniz; NoSQL DB, Spring Boot veya Kotlin çıktığında da kullanmak istemiyorsanız kullanmamanızla benzer bir durum.
    Jetpack Compose ve SwiftUI’nin de React’ten ilham aldığını biliyordum; sanırım eskiden Android dokümantasyonunda görmüştüm ama şimdi bulamıyorum.
    Yine de henüz onlarca yıllık deneyimim yok; eski dönemde büyük ekiplerin jQuery ya da saf JS ile Airbnb gibi büyük web uygulamaları yaparken ne kadar keyif aldığını bilmiyorum. Şimdi state yönetimini, DOM manipülasyonunu ve yan etkileri saf JS ile nasıl çözeceğimi hayal etmek bile zorlaştı.
    Belki bir gün ben de yeni bir framework’ten şikâyet edip React’in iyi olduğunu söylerim.

    • React’e yönelik tepkinin genelde onu gerçekten çok kullanmamış kişilerden geldiğini düşünüyorum; bu yüzden pek anlayamıyorum.
      Genellikle mantık “frontend hep yeni ve parlak şeylerin peşinden koşar, React de onlardan biri” şeklinde; oysa React 2013’ten beri var ve 2015 civarından itibaren oldukça ana akım oldu.
      Ayrıca framework ve kütüphanelerin karmaşıklık eklediği söyleniyor, ama somut olarak hangi karmaşıklık diye sorunca neredeyse hiç yanıt alınamıyor. Framework olmadan anlamlı bir uygulama yaparsanız sonunda yönetimi, testi ve dokümantasyonu eksik olan kendi framework’ünüzü icat etmiş olursunuz.
      Derleme ve bundle alma adımlarından da sıkça şikâyet ediliyor; ama artık Expo, Next.js, Meteor gibi kendini kanıtlamış framework’ler var, bu yüzden webpack yapılandırmasını ya da build pipeline’ını elle yazmak için neredeyse hiç neden yok.
    • Çoğu web sitesinin en başta uygulama olmasına gerek yok. Bazılarının var, ama o durumlarda da genelde özel geliştirme gerekir.
      Her yere web framework’ü sokma eğilimi son 10 yılda yavaş ve kolay bozulan siteler üretti; çoğu zaman aşırı tasarlanmış olmalarına rağmen 2008’in kullanıcı deneyiminden çok da ileri gitmediler.
      Bazı frontend geliştiriciler için soru ne olursa olsun cevap React / Node / Vite / Angular / Vue / Nuxt / Next / Bun / Deno / Svelte / SvelteKit kombinasyonlarından biridir; mümkünse Kubernetes’in hükmettiği onlarca Docker swarm’ü üzerinde çalışmalıdır. “Özgeçmişini internete koymak mı istiyorsun? O zaman önümüzdeki 3 hafta boyunca uygulamanın state akış diyagramını çizelim” gibi.
      React’in özellikle daha çok eleştirilmesinin nedeni, framework modasını takip edenlerin çoktan bir sonraki parlak şeye geçmiş olması; bu tür framework’lerden zaten hoşlanmayanların ise sevmemeye devam etmesi gibi görünüyor. Bu yüzden artık bu karmaşayı savunacak kimse kalmadı. Diğer framework’lerin de zamanla aynı kaderi paylaşacağını düşünüyorum.
    • Class dönemindeki React’in fena olmayan, sıradan ve sıkıcı ama kullanışlı bir UI framework’ü olduğunu düşünüyorum. Buna karşılık hook’ları kullanmak çok zor.
      Gerçekte nasıl çalıştığının çoğu gizli ve sezgisel değil; hata yapmak kolay, performansı düşük UI yazmak da kolay.
      Neyin kaç kez çalıştığını, dependency array’e ne koymak gerektiğini, useCallback ve useEffect içine ne koyulacağını sürekli düşünmek gerekiyor; bu da bilişsel yükü artırıyor.
      Topluluğun bir kısmı projede gerekli olmayan React bağımlılıklarını bile önererek yalnızca overhead’i ve karmaşıklığı artırabiliyor.
      İş mantığı ile UI mantığının karışması da kolay.
    • jQuery, büyük ve karmaşık uygulamalar yapılmaya başlandığında ciddi şekilde dağılıyordu. O dönemi gerçekten yaşamış birinin o günleri özleyeceğini sanmıyorum.
      Bir süre SPA’ların MPA’lara göre dezavantajları vardı, ancak modern web standartları ve SPA framework’lerinin sunucu tarafı rendering’i benimsemesiyle bu sorunlar bugün neredeyse tamamen çözüldü.
    • “NoSQL DB çıktığında kimse şikâyet etmedi” diye bir şey yok. Aramızdan pek çok kişi MongoDB’nin ne kadar kötü olduğundan epey yüksek sesle şikâyet etti.
      https://www.youtube.com/watch?v=b2F-DItXtZs

  • Harika bir sürüm ama şu anda frontend geliştirmeye başlayanlara biraz acıyorum
    “Transition içinde Action’ları sıraya koyan, action durumu ve pending durumuna erişen yeni bir hook; Action’ı çağırabilen bir reducer ile ilk render’da kullanılacak başlangıç durumunu alır, form action prop’una geçirildiğinde formun aşamalı iyileştirmesini desteklemek için isteğe bağlı bir string de alır” gibi açıklamalar, özellik iyi görünse de fazla uzun ve dolambaçlı
    Bugün web sitesi geliştirmeye başlasam nereden başlayacağımı bilemezdim gibi geliyor
    Yine de React hâlâ mükemmel bir framework ve bu sürüm de bir iyileştirme. Eleştirim yalnızca React’e değil, daha çok frontend geliştirmenin geneline yönelik

    • Tavsiye verecek olsam, mümkünse React’ten tamamen kaçınarak başlardım
      Eski usul sunucu tarafı render ve HTMX gibi bir şey kullanmak çok daha iyi
      4 yıl React frontend geliştirerek para kazandım ve ilk web sitemi 2005’te yaptım; şu anda bir müşteri projesini React’ten HTMX’e taşıyorum ve bunun çok daha iyi olduğunu hissediyorum
      Daha az bug var, hook’ları yanlış kullanmaktan doğan tuzaklar da daha az
      İstemci tarafı render gerekirse Solid ya da Vue kullanırdım ama React’ten kaçınırdım. Seçeneğin yoksa bol şans
    • React’in ilginç bir yaklaşım olduğunu ama en baştan beri görmezden gelinen uyarı işaretleri bulunduğunu düşünüyorum
      Tek yönlü binding, sanal DOM, yeniden render ve diff hesaplama gibi temel varsayımlar bana temelden ikna edici gelmedi. Tarayıcı belleğini iki kat kullanmak ve her etkileşimde her şeyi yeniden render edip diff hesaplamak demek bu
      O dönemde cevap “önce sağlam yapalım, sonra hızlı yaparız”dı; ama şimdi hızlı yapmak için hack’vari yapılarla dolu ve ne hızlı ne de sağlam
      Dürüst bir çift yönlü binding framework’ü en azından hızı garanti eder, sağlamlık da deneyimle gelir diye düşünüyorum. React ise sadece karmaşık. Frontend’e ilk React ile başlayan mühendisler için öğrendiklerini silip yeniden öğrenmenin, öğrenmekten çok daha zor olacağını düşünüp üzülüyorum
      VBScript, JS, jQuery, Mootools, Applets, ActionScript, YUI/Ext/Sencha, Backbone, Knockout, Angular 1, Angular 2, React, Vue 1’den geçmiş biri olarak Flutter’ı denemelerini söylemek isterim. Gerçekten ferahlatıcı
      Ancak sorun Dart. Flutter TypeScript olsaydı ideale biraz daha yakın olurdu; Dart ise frontend’in bitmek bilmeyen churn ruhunu yaşatmaya devam ediyor
    • Ben tam tersini hissediyorum. React kullanmaya başladığımda birkaç haftada bir değişiyordu; şimdi dokümantasyon ve API’ler çok daha kararlı ve tutarlı
      Web standartları da genel olarak her zamankinden daha kararlı. Genç geliştiricilerin sayfaların birden çok tarayıcıda düzgün görünmesi için yüzlerce layout hilesi öğrenmesine gerek yok; bazen yalnızca tek bir tarayıcıya uydurmak için yapılan hack’lere de daha az ihtiyaç var
      JavaScript yorgunluğunu anlıyorum ama bence şu an öğrenmek için en iyi dönemlerden biri
    • Çoğunlukla düşük seviye kodlama yaptım ve web frontend ile temasım genelde hoşuma gitmedi; birkaç yıl önce kişisel bir proje için React’i elime alınca çok şaşırdım
      Her şey gerçekten düzgün geliştirme gibi hissettirdi ve önceki durumla kıyaslayınca temiz hava gibiydi
    • Başlamanın kolay olduğunu düşünüyorum. O isteğe bağlı özelliği kullanmazsın, olur biter
      Geliştiricilerin %99’u için uygulama belli bir ölçüde büyüyene kadar bu tür özelliklere gerek yok; hatta sonuna kadar hiç gerek olmayabilir. React de bunu zorunlu kılmıyor

  • React gibi istemci tarafı framework’leri bir zamanlar severdim ama sonunda mümkün olan her yere karmaşıklık eklediklerini fark ettim
    Backend’e, frontend’e, DevOps stack’ine, her yere karmaşıklık girdi; bu dağınık karmaşıklığı senkronize etmek için de sürekli daha fazla katman eklenecek

    • Küçük uygulamaların ötesine geçince frontend framework’leri gerçekten daha basit hâle getiriyor
      Veri ya da model değiştiğinde UI’ın otomatik yeniden render edilmesi doğru yön
      Ayrıntılardaki yöntem tartışılabilir ama veri her değiştiğinde UI’ı imperative şekilde elle değiştirmek, kod tabanı ya da ekip ölçeği açısından uzun süre dayanabilecek bir yaklaşım değil
    • React, web frontend’den uzaklaşmama neden olan şeydi
      Web tarayıcısına aslında tasarlanmadığı şekilde kutular render ettirmek için muazzam bir karmaşıklık bindirdi; kodlama paradigmasını değiştirme adına üretkenlikten ve araç ekosisteminden de büyük ölçüde kaybettik
      Harika fikirler ve uygulamalar vardı ama buna değip değmediğinden emin değilim. Bir tür iş güvencesi mekanizması mıydı diye de düşünüyorum
      Bu yalnızca ReactJS’in sorunu değil; tüm JavaScript ekosistemi kütüphane ve araçlarla çılgına döndü. Ama React’e başlamak özellikle sinir bozucuydu; sonunda makul sürede hello world uygulaması yapılabilsin diye create react app çıktı
    • Girişim sermayesiyle finanse edilen yazılım geliştirme, zeki ve aynı zamanda eğlenmek isteyen insanlar için bir sosyal yardım programı olduğu için böyle bence. Sorun değil
    • React’i seviyorum ama hooks çıkan v16.8’den sonra React’teki değişimler teknik gösteriş gibi geliyor
      Class component API’ını hook’lara çevirme nedenini anlamaya çalışma beklentisini bıraktım
    • Karmaşıklığı bizzat kendimizin ekleyip eklemediğini de düşünmek gerek
      Daha basit bir framework seçilebilir, sunucu orkestrasyonundan kaçınılabilir
      Seçeneğin yoksa, basit bir stack ile verimlilik avantajı yakalayabileceğine inandığın bir projeyi kendin başlatabilirsin

  • Bu sürümün en iyi yanlarından biri ref’in prop olarak kullanılabilmesi. Artık forwardRef gerekmiyor

  • Blog yazısı daha okunaklı: https://react.dev/blog/2024/12/05/react-19

    • const error = await updateName(newName); satırında updateNamein neden hata döndürdüğünü anlamıyorum
      JS/TS’ye uygun şekilde sadece Error fırlatsa olmaz mı?

  • Şu ana kadarki 45 yorum içinde “redux” 7 kez geçtiyse, burada Recoil ailesini temsilen Jotai’den söz etmek isterim. Muhtemelen React 19’da da ayrı bir değişiklik gerektirmeden zaten çalışacaktır
    Frontend karmaşıklığı yeterince büyüdüğünde diğer durum yönetimi araçları gereğinden fazla ayak bağı olabiliyor
    React’ten nefret etmeye başladıysanız ama aslında bitmek bilmeyen action sabitleri duvarından, prop tesisatından, iç içe provider/context’lerle boğuşmaktan ve pub-sub’a kaçmaktan yorulduysanız, Jotai gibi bir şeyi denemeye değer

    • Jotai’yi yapan ekip Zustand ve Valtio’yu da yaptı
      https://github.com/pmndrs/zustand
      https://github.com/pmndrs/valtio
      Jotai’de manuel boilerplate fazla gibi geliyor; Valtio’da ise proxy “sihri” çok, kişisel olarak sevsem de ekip için iyi bir seçim olduğundan emin değilim
      Zustand boilerplate ile sihir arasında bir yerde duruyor; bu yüzden şu anda yürüttüğümüz büyük projede onu seçtik
    • Durum yönetiminde neden bu kadar tuhaf terim var bilmiyorum
      Birkaç yıl önce React uygulaması üzerinde çalışmaya başladığımda gördüğüm tüm durum yönetimi paketleri bu tür terimlerle doluydu, şimdi de hâlâ öyle
      Sonunda bunlardan uzaklaşıp işe odaklanmak için kendi çözümümü yaptım [1] ve prodüksiyonda iyi çalışıyor. Benzer şekilde çalışan popüler bir seçenek olmaması üzücü
      [1] https://github.com/facepunch/react-class-model
    • Jotai’nin npm dokümantasyon sayfasına (https://www.npmjs.com/package/jotai) baksam da, birden çok context provider ya da Redux kullanımından nasıl kurtardığı pek anlaşılmıyor
      context hook’un iyi yanı birleştirilebilir olması; önbelleğe alınmış sorgularla birleştirildiğinde oldukça sürdürülebilir bir desen oluşturabiliyor
      Jotai’nin burada nasıl bir somut iyileştirme sunduğunu merak ediyorum
    • Büyük sayılabilecek bir projede Jotai kullandım ve epey beğendim
      Bir daha asla redux ya da sagas ile uğraşmamayı gerçekten umuyorum
    • Herkesin https://starfx.bower.sh’ı denemesini isterim. Durum yönetimine ve daha da önemlisi yan etki yönetimine yeni bir yaklaşım

  • Yeni eklenen özelliklerin çoğunu beğenmedim
    Actions ve useActionState / useOptimistic hook’ları büyük bir karmaşıklık tuzağı gibi görünüyor. use hook’unun adı fazla bilgisiz; ayrıca bileşen içinde oluşturulan promise’ları işlemiyor
    Elbette iyi bir nedeni vardır, ama promise’ı prop olarak geçirip use hook’u ile işleme yaklaşımı mevcut geçici çözümlerden daha fazla karmaşıklık yaratacak gibi
    Server Components da oldukça karmaşık görünüyor; henüz uğraşmam gerekmediği için memnunum
    hydration hata mesajlarının iyileştirilmesi sevindirici; provider olarak kullanma değişikliği ve ref’i prop olarak kullanma değişikliği de iyi kalite iyileştirmeleri
    Genel olarak SPA yapmak için React/Preact’i seviyorum. MUI gibi zengin özellikli bir bileşen kütüphanesi ve Preact Signals gibi basit bir durum yönetimi çözümüyle SPA geliştirmek oldukça sezgisel
    Yine de karmaşıklığın yavaş yavaş içeri sızmasından endişeliyim. Sürüm notlarındaki yeni hook açıklamalarını okumak bile ciddi bir bilişsel yük gibi geliyor
    Buna karşılık React Compiler gerçekten gerekli bir araç. Programcıların tipik optimizasyonları bileşen içine elle yazmasına gerek kalmayacağı için bileşenler daha az karmaşık olacak
    Sürümü ve Vite gibi araçlarla entegrasyonunu bekliyorum; duyduğuma göre Preact’i de destekleyecek

  • use API’sinin, hook’ların ortak ön ekinden farklı bir adla değiştirilmesi iyi olur
    React hook’larına yeni başlayan birinin use’un koşullu çağrılabildiğini ama normal hooks’ların çağrılamadığını görürse kafasının karışacağını düşünüyorum

  • Paralel Suspense sorununu çözmek için sürümü geciktirmeleri gerçekten sevindirici
    Henüz denemedim ama beklentim yüksek; genel olarak harika bir sürüm

  • Son dakika: custom elements için tam destek var. Yani Web Components