React 19

 (github.com/facebook)
2 poin oleh GN⁺ 2024-12-06 | 1 komentar | Bagikan ke WhatsApp

19.0.0 (5 Desember 2024)

Fitur baru

React
  • Actions: startTransition kini dapat menerima fungsi asinkron. Fungsi-fungsi ini disebut "Actions" dan memperbarui state di latar belakang serta melakukan commit UI sekaligus. Actions dapat menjalankan efek samping seperti permintaan asinkron, dan menunggu pekerjaan selesai sebelum Transition berakhir.
  • useActionState: Hook baru untuk mengurutkan Actions dan mengakses state di dalam Transition. Menerima state awal dan reducer.
  • useOptimistic: Hook baru untuk memperbarui state saat Transition sedang berlangsung. Ketika Transition selesai, state diperbarui ke nilai baru.
  • use: API baru untuk membaca resource saat rendering. Menerima Promise atau Context, dan jika Promise diberikan, akan melakukan suspend hingga nilainya terselesaikan.
  • Menggunakan ref sebagai prop: ref kini dapat digunakan sebagai prop tanpa memerlukan forwardRef.
  • Prewarming sibling Suspense: Saat komponen melakukan suspend, React segera melakukan commit fallback dari boundary Suspense terdekat.
React DOM client
  • Prop action pada <form>: Form Actions secara otomatis mengelola form dan terintegrasi dengan useFormStatus. Form juga otomatis di-reset saat berhasil.
  • Dukungan metadata dokumen: Tag metadata dokumen kini bisa dirender secara native dari komponen.
  • Dukungan stylesheet: Menyisipkan stylesheet ke <head> klien sebelum menampilkan konten dari boundary Suspense.
  • Dukungan script asinkron: Dapat merender script asinkron dari mana saja di dalam tree komponen.
React DOM server
  • Penambahan API prerender dan prerenderToNodeStream: API untuk pembuatan situs statis, dirancang agar bekerja di lingkungan streaming seperti stream Node.js dan web stream.
React server components
  • Fitur RSC: directives, server components, dan server functions kini telah stabil. Library yang menyertakan server components sekarang dapat menargetkan React 19 sebagai peer dependency.

Akan dihentikan

  • Akses element.ref: Akses element.ref dihentikan dan disarankan menggunakan element.props.ref.
  • react-test-renderer: Di React 19, react-test-renderer akan mencatat peringatan penghentian dan beralih ke concurrent rendering untuk penggunaan web.

Perubahan utama

React
  • Transformasi JSX baru wajib: Transformasi JSX baru diperlukan untuk meningkatkan ukuran bundle dan memungkinkan penggunaan JSX tanpa mengimpor React.
  • Error rendering tidak dilempar ulang: Jika error tidak ditangkap oleh Error Boundary, error akan dilaporkan ke window.reportError.
  • Penghapusan propTypes: Penggunaan propTypes akan diabaikan secara diam-diam. Migrasi ke TypeScript direkomendasikan.
  • Penghapusan defaultProps pada fungsi: Dapat menggunakan parameter default ES6 sebagai gantinya.
  • Penghapusan string refs: Penggunaan string refs harus dimigrasikan ke callback ref.
React DOM
  • Penghapusan react-dom/test-utils: act dipindahkan dari react-dom/test-utils ke react. Utility lainnya dihapus.
  • Penghapusan ReactDOM.render, ReactDOM.hydrate: Digantikan oleh ReactDOM.createRoot dan ReactDOM.hydrateRoot untuk concurrent rendering.

Perubahan yang patut diperhatikan

React
  • Menggunakan <Context> sebagai provider: Kini dapat merender <Context> sebagai provider alih-alih <Context.Provider>.
  • Dukungan custom element: React 19 lulus semua pengujian custom element.
  • Perubahan StrictMode: useMemo dan useCallback menggunakan kembali hasil memoization dari rendering pertama.
React DOM
  • Perbedaan untuk error hydration: Jika terjadi ketidakcocokan, React 19 mencatat satu error yang mencakup perbedaan pada konten yang tidak cocok.

Perubahan TypeScript

  • Larangan implicit return: refs kini hanya menerima fungsi cleanup. Implicit return akan memicu error.
  • Argumen awal useRef wajib: Argumen awal sekarang wajib.
  • Pengetikan ReactElement lebih ketat: props pada elemen React kini menggunakan default unknown alih-alih any.

Bacaan terkait

1 komentar

 
GN⁺ 2024-12-06
Pendapat di Hacker News

  • Saya tidak begitu paham kenapa begitu banyak orang di sini membenci React
    Saya memulai karier dengan Laravel dan JS murni, tetapi setelah mencoba React, membuat aplikasi yang skalabel terasa realistis dan frontend juga jadi menyenangkan
    Meski pindah perusahaan, React mudah dipelajari lagi, dan berkat dukungan TypeScript serta ekosistem yang besar, rasanya cukup mudah untuk membuat dan mengembangkan apa pun
    Saya juga tidak mengerti kenapa fitur baru membuat orang takut. Kita masih bisa membuat SPA atau memakai cara lama, mirip seperti saat NoSQL DB, Spring Boot, atau Kotlin muncul: kalau tidak mau pakai, ya tidak usah dipakai
    Seingat saya Jetpack Compose dan SwiftUI juga terinspirasi dari React; rasanya dulu pernah melihatnya di dokumentasi Android, tetapi sekarang tidak bisa menemukannya
    Namun saya belum punya pengalaman puluhan tahun, jadi saya tidak tahu seberapa menyenangkannya dulu tim besar membangun web app besar seperti Airbnb dengan jQuery atau JS murni. Sekarang bahkan sulit membayangkan bagaimana menyelesaikan state management, manipulasi DOM, dan side effect dengan JS murni
    Suatu hari mungkin saya juga akan mengeluhkan framework baru dan berkata React dulu lebih baik

    • Antipati terhadap React biasanya tampaknya datang dari orang yang belum banyak benar-benar memakainya, jadi saya kurang memahaminya
      Biasanya logikanya seperti “frontend selalu mengejar hal baru yang mengilap, dan React salah satunya”, tetapi React sudah ada sejak 2013 dan kira-kira sejak 2015 sudah cukup mainstream
      Ada juga yang bilang framework dan library menambah kompleksitas, tetapi ketika ditanya kompleksitas seperti apa secara spesifik, hampir tidak ada jawaban. Kalau membuat aplikasi yang bermakna tanpa framework, pada akhirnya kita akan menciptakan framework sendiri yang kurang terkelola, kurang teruji, dan kurang terdokumentasi
      Tahap kompilasi dan bundling juga sering dikeluhkan, tetapi sekarang sudah ada framework yang teruji seperti Expo, Next.js, dan Meteor, sehingga hampir tidak ada alasan untuk menyusun konfigurasi webpack atau build pipeline sendiri
    • Sebagian besar situs web sejak awal memang tidak perlu menjadi aplikasi. Sebagian memang perlu, tetapi dalam kasus seperti itu pun biasanya butuh pengembangan khusus
      Tren memasukkan web framework ke semua tempat selama 10 tahun terakhir telah menghasilkan situs yang lambat dan mudah rusak, dan dalam banyak kasus, meski over-engineered, pengalaman penggunanya tidak jauh lebih baik daripada tahun 2008
      Bagi sebagian frontend developer, apa pun pertanyaannya, jawabannya adalah kombinasi React / Node / Vite / Angular / Vue / Nuxt / Next / Bun / Deno / Svelte / SvelteKit, dan kalau bisa harus berjalan di atas puluhan swarm Docker yang dikuasai Kubernetes. Gayanya seperti, “Mau menaruh CV secara online? Kalau begitu selama 3 minggu ke depan mari kita gambar diagram alur state aplikasinya”
      React tampaknya mendapat lebih banyak celaan karena orang-orang yang mengejar tren framework sudah pindah ke hal mengilap berikutnya, sementara orang-orang yang dari awal membenci framework semacam ini tetap membencinya, sehingga kini tidak ada lagi yang tersisa untuk membela kekacauan ini. Framework lainnya sepertinya akan mengalami nasib yang sama seiring waktu
    • Menurut saya React di era class adalah UI framework yang baik-baik saja, biasa, membosankan, tetapi berguna. Sebaliknya, hook sangat sulit digunakan
      Cara kerja sebenarnya banyak disembunyikan dan tidak intuitif, mudah salah, dan UI berkinerja buruk pun mudah ditulis
      Kita harus terus memikirkan apa yang dijalankan berapa kali, apa yang harus dimasukkan ke dependency array, serta apa yang harus dimasukkan ke useCallback dan useEffect, sehingga beban kognitifnya besar
      Sebagian komunitas juga menganjurkan dependency React yang tidak diperlukan proyek, sehingga hanya menambah overhead dan kompleksitas
      Logika bisnis dan logika UI juga mudah tercampur
    • jQuery ambruk parah begitu orang mulai membuat aplikasi besar dan kompleks. Saya rasa orang yang benar-benar mengalami masa itu tidak akan merindukannya
      Untuk sementara SPA memang punya kekurangan dibanding MPA, tetapi dengan standar web modern dan adopsi server-side rendering oleh framework SPA, masalah-masalah itu kini hampir terselesaikan
    • Bukan berarti “tidak ada yang mengeluh saat NoSQL DB muncul”. Banyak dari kami cukup lantang mengeluhkan betapa buruknya MongoDB
      https://www.youtube.com/watch?v=b2F-DItXtZs

  • Rilis yang keren, tetapi saya juga merasa agak kasihan pada orang yang baru mulai masuk ke pengembangan frontend sekarang
    Penjelasan seperti “hook baru untuk mengurutkan Action di dalam Transition dan mengakses status action serta status pending; menerima reducer yang bisa memanggil Action dan state awal yang digunakan pada render pertama; serta juga menerima string opsional untuk mendukung progressive enhancement pada form jika diteruskan ke prop form action” terdengar fiturnya bagus, tetapi terlalu bertele-tele
    Kalau mulai mengembangkan situs web hari ini, rasanya akan bingung harus mulai dari mana
    Meski begitu, React tetap framework yang luar biasa dan rilis ini juga merupakan peningkatan. Kritiknya bukan hanya untuk React, melainkan lebih ke pengembangan frontend secara umum

    • Kalau harus memberi kiat, saya akan mulai dengan menghindari React sama sekali jika memungkinkan
      Menggunakan sesuatu seperti HTMX dengan server-side rendering gaya lama jauh lebih baik
      Saya mencari nafkah dari pengembangan frontend React selama 4 tahun dan membuat situs web pertama saya pada 2005; sekarang saya sedang memindahkan satu proyek klien dari React ke HTMX dan merasa hasilnya jauh lebih baik
      Bug lebih sedikit, dan jebakan akibat salah memakai hook juga lebih sedikit
      Jika butuh client-side rendering, saya akan memakai Solid atau Vue, tetapi akan menghindari React. Kalau tidak punya pilihan, semoga beruntung
    • React memang pendekatan yang menarik, tetapi menurut saya sejak awal ada sinyal bahaya yang diabaikan
      Premis dasarnya—one-way binding, virtual DOM, re-rendering, dan diffing—secara fundamental tidak meyakinkan bagi saya. Itu berarti memakai memori browser dua kali lipat, lalu melakukan re-render penuh dan diffing pada setiap interaksi
      Jawaban waktu itu adalah “buat stabil dulu, lalu buat cepat”, tetapi sekarang isinya penuh struktur hacky untuk membuatnya cepat, dan hasilnya tidak cepat maupun stabil
      Menurut saya framework two-way binding yang jujur setidaknya menjamin kecepatan, sementara stabilitas datang dari pengalaman. React hanya terasa kacau. Saya kasihan pada engineer yang pengalaman frontend pertamanya adalah React, karena tampaknya jauh lebih sulit menghapus dan mempelajari ulang daripada sekadar belajar
      Dari sudut pandang seseorang yang telah melewati VBScript, JS, jQuery, Mootools, Applets, ActionScript, YUI/Ext/Sencha, Backbone, Knockout, Angular 1, Angular 2, React, hingga Vue 1, saya ingin menyarankan untuk mencoba Flutter. Benar-benar terasa segar
      Namun masalahnya ada pada Dart. Kalau Flutter memakai TypeScript, ia akan sedikit lebih dekat ke ideal, tetapi Dart terus menghidupkan semangat churn tanpa akhir di frontend
    • Saya justru merasa sebaliknya. Saat saya mulai memakai React, ia berubah setiap beberapa minggu, sedangkan sekarang dokumentasi dan API-nya jauh lebih stabil dan konsisten
      Standar web secara umum juga lebih stabil daripada sebelumnya. Developer muda tidak perlu mempelajari ratusan trik layout agar halaman tampil benar di berbagai browser, dan terkadang juga lebih sedikit hack yang hanya ditujukan untuk satu browser
      Saya paham rasa lelah terhadap JavaScript, tetapi menurut saya sekarang adalah salah satu waktu terbaik untuk belajar
    • Saya terutama mengerjakan coding level rendah dan umumnya tidak suka bersinggungan dengan frontend web, tetapi beberapa tahun lalu saya mencoba React untuk proyek pribadi dan sangat terkejut
      Semuanya terasa seperti pengembangan yang benar-benar layak, dan dibandingkan kondisi sebelumnya rasanya seperti menghirup udara segar
    • Menurut saya memulainya mudah. Cukup jangan gunakan fitur opsional itu
      Bagi 99% developer, fitur seperti itu tidak dibutuhkan sampai aplikasi tumbuh sampai tingkat tertentu, dan mungkin tidak akan pernah dibutuhkan. React juga tidak memaksakannya

  • Saya dulu menyukai framework sisi klien seperti React, tetapi akhirnya menyadari bahwa itu menambahkan kompleksitas di semua tempat yang memungkinkan
    Kompleksitas masuk ke backend, frontend, stack DevOps, di mana-mana, dan akan terus ada lebih banyak lapisan yang ditambahkan untuk menyinkronkan kompleksitas yang tersebar itu

    • Begitu melewati aplikasi kecil, framework frontend justru benar-benar membuatnya lebih sederhana
      UI yang otomatis di-render ulang saat data atau model berubah adalah arah yang benar
      Detail caranya bisa diperdebatkan, tetapi pendekatan imperatif yang mengubah UI secara langsung setiap kali data berubah sulit bertahan lama dari sisi codebase maupun ukuran tim
    • React adalah alasan saya menjauh dari frontend web
      Ia menambahkan kompleksitas besar untuk membuat browser web merender kotak dengan cara yang awalnya tidak dimaksudkan, dan atas nama mengubah paradigma coding, produktivitas serta ekosistem tooling juga banyak hilang
      Ada ide dan implementasi yang keren, tetapi saya tidak tahu apakah itu sepadan. Kadang saya bertanya-tanya apakah itu semacam alat pengaman pekerjaan
      Ini bukan hanya masalah ReactJS; seluruh ekosistem JavaScript memang menggila dengan library dan tooling, tetapi React khususnya menyebalkan untuk mulai digunakan, sampai akhirnya create react app muncul agar orang bisa membuat aplikasi hello world dalam waktu yang masuk akal
    • Menurut saya itu karena pengembangan software yang didanai modal ventura adalah program kesejahteraan bagi orang-orang pintar yang juga ingin bersenang-senang. Tidak apa-apa
    • Saya suka React, tetapi perubahan React setelah v16.8, saat hooks muncul, terasa seperti pamer teknologi
      Saya sudah berhenti berharap bisa memahami alasan mengganti API class component dengan hook
    • Perlu juga melihat kembali apakah kompleksitas itu ditambahkan sendiri
      Bisa saja memilih framework yang lebih sederhana, atau menghindari orkestrasi server
      Jika tidak punya pilihan, bisa juga memulai sendiri proyek yang Anda yakini bisa punya keunggulan efisiensi dengan stack yang sederhana

  • Salah satu bagian terbaik dari rilis ini adalah ref kini bisa dipakai sebagai prop. Sekarang forwardRef tidak lagi diperlukan

  • Tulisan blognya lebih mudah dibaca: https://react.dev/blog/2024/12/05/react-19

    • Saya tidak mengerti mengapa updateName mengembalikan error pada const error = await updateName(newName);
      Bukankah seharusnya, seperti gaya JS/TS, cukup melempar Error saja?

  • Jika dari 45 komentar sejauh ini ada 7 penyebutan “redux”, di sini saya ingin menyebut Jotai sebagai wakil dari keluarga Recoil. Kemungkinan besar di React 19 pun sudah bisa berjalan tanpa perubahan khusus
    Ketika kompleksitas frontend sudah cukup besar, alat manajemen state lain sering kali justru mengganggu lebih dari yang diperlukan
    Kalau Anda jadi tidak suka React, tetapi sebenarnya yang membuat lelah adalah dinding konstanta action yang tak ada habisnya, perpipaan prop, pertarungan dengan provider/context bertingkat, dan pelarian ke pub-sub, sesuatu seperti Jotai layak dicoba

    • Tim yang membuat Jotai juga membuat Zustand dan Valtio
      https://github.com/pmndrs/zustand
      https://github.com/pmndrs/valtio
      Jotai terasa punya terlalu banyak boilerplate manual, sedangkan Valtio punya terlalu banyak “sihir” proxy; secara pribadi saya menyukainya, tetapi tidak yakin apakah itu pilihan yang baik untuk tim
      Zustand berada di tengah antara boilerplate dan sihir, jadi saya memilihnya untuk proyek besar yang sedang berjalan
    • Saya tidak tahu kenapa manajemen state punya begitu banyak istilah aneh
      Saat mulai mengerjakan aplikasi React beberapa tahun lalu, semua paket manajemen state yang saya lihat penuh dengan istilah seperti itu, dan sampai sekarang masih begitu
      Pada akhirnya, untuk lepas dari hal-hal semacam itu dan fokus pada pekerjaan, saya membuat solusi sendiri [1], dan berjalan baik di lingkungan produksi. Sayang tidak ada pilihan populer yang bekerja dengan cara serupa
      [1] https://github.com/facepunch/react-class-model
    • Melihat halaman dokumentasi npm Jotai(https://www.npmjs.com/package/jotai), saya masih belum benar-benar paham bagaimana ia membantu keluar dari penggunaan banyak context provider atau Redux
      Hal bagus dari context hook adalah bisa dikomposisikan, dan jika digabungkan dengan kueri yang di-cache, bisa membentuk pola yang cukup mudah dipelihara
      Saya penasaran perbaikan praktis apa yang diberikan Jotai di sini
    • Saya pernah memakai Jotai di proyek yang cukup besar dan cukup menyukainya
      Saya benar-benar berharap tidak perlu berurusan lagi dengan redux atau sagas
    • Saya harap semua orang mencoba https://starfx.bower.sh. Ini pendekatan baru untuk manajemen state dan, yang lebih penting, manajemen efek samping

  • Sebagian besar fitur baru yang diperkenalkan tidak saya sukai
    Actions dan hook useActionState / useOptimistic terlihat seperti jebakan kompleksitas besar. Nama hook use terlalu tidak informatif, dan tidak menangani promise yang dibuat di dalam komponen
    Pasti ada alasan yang baik, tetapi cara meneruskan promise sebagai prop lalu menanganinya dengan hook use tampaknya akan menciptakan lebih banyak kompleksitas daripada workaround saat ini
    Server Components juga tampak cukup rumit, dan untungnya saya belum perlu menanganinya
    Perbaikan pesan error hydration patut disambut, dan perubahan penggunaan provider serta penggunaan ref sebagai prop adalah peningkatan kualitas yang bagus
    Secara keseluruhan, untuk membuat SPA saya menyukai React/Preact. Dengan library komponen kaya fitur seperti MUI dan solusi manajemen state sederhana seperti Preact Signals, pembuatan SPA terasa cukup intuitif
    Namun saya khawatir kompleksitasnya perlahan-lahan merayap masuk. Membaca penjelasan hook baru di catatan rilis saja sudah terasa memberi beban kognitif yang besar
    Sebaliknya, React Compiler adalah alat yang memang sangat dibutuhkan. Programmer tidak perlu menulis optimisasi tipikal langsung di dalam komponen, sehingga komponen akan menjadi lebih tidak kompleks
    Saya menantikan rilis dan integrasinya dengan Vite dan lainnya, dan dari yang saya dengar Preact juga akan didukung

  • Akan lebih baik jika API use diganti namanya menjadi sesuatu yang berbeda dari prefiks umum hook
    Orang yang baru mempelajari hook React kemungkinan akan bingung ketika melihat use boleh dipanggil secara kondisional, sedangkan hooks biasa tidak boleh

  • Senang sekali rilisnya ditunda untuk menyelesaikan masalah Suspense paralel
    Saya belum mencobanya, tetapi ekspektasi saya besar, dan secara keseluruhan ini rilis yang luar biasa

  • Kabar terbaru: custom elements didukung sepenuhnya. Artinya Web Components