Nota kemas kini untuk versi utama baharu React sentiasa padat maklumat yang luar biasa, dan rangka kerja itu sendiri sangat luas sehingga saya sentiasa mendapati diri saya mengambil nota dan membandingkan berbanding dokumentasi rujukan untuk cuba bukan sekadar mengetahui perkara yang berubah dan cara menggunakannya, tetapi juga bagaimana pelbagai konsep utama yang dibincangkan oleh nota kemas kini sebenarnya berfungsi di bawah hud. Walaupun React didokumentasikan dengan sangat baik, nota kemas kini tidak selalunya "cukup" untuk memahami konsep - contohnya, dalam nota kemas kini React 19, saya mendapati contoh useOptimistic mengelirukan dan sebenarnya agak tidak tepat tentang cara cangkuk sebenarnya berfungsi.
Saya telah memutuskan untuk menulis nota yang saya ambil semasa meninjau perubahan React 19 menjadi teman bagi sesiapa sahaja yang takut menyisir nota dan memikirkan maksud semuanya - jadi mari mulakan.
Tindakan & Pengendalian Borang/useActionState
Peningkatan besar pertama ialah penambahbaikan besar pada pengendalian borang. React telah beransur-ansur bergerak untuk mengalih keluar boilerplate dan menyepadukan dengan lebih baik dengan borang HTML asli, dan useActionState baharunya adalah sebahagian daripada dorongan ini. Ia bertujuan untuk membantu meningkatkan pengendalian ralat (kerana ia kini terbina dalam), ia menjejaki keadaan pemuatan secara automatik supaya anda tidak perlu mengekod secara manual dalam keadaan belum selesai secara berterusan dan meningkatkan sokongan untuk peningkatan progresif.
Sekarang, saya dapati contoh kod yang disediakan untuk useActionState agak mengelirukan, dan sebenarnya contoh kod ini adalah keseluruhan sebab saya mula menulis artikel ini - sebenarnya, terdapat dua bahagian untuk useActionState, yang mereka gabungkan dalam contoh untuk menjimatkan ruang, tetapi akhirnya mengurangkan kejelasan. useActionState mengembalikan tuple yang menjejaki apabila tindakan async dalam penyerahan borang selesai, manakala versi diubah suai bagi tindakan yang anda hantar dihantar terus ke borang. useActionState sendiri mengambil dua input - async formAction (yang menerima kedua-dua keadaan sebelumnya dan data borang sebagai argumen apabila dipanggil) dan keadaan awal - yang boleh menjadi nol, sifar atau pembolehubah.
Jika borang anda masih belum diserahkan, keadaan sebelumnya ialah InitialState. Jika borang telah diserahkan sebelum ini, ia adalah apa sahaja yang telah diserahkan - dalam fungsi pelayan, anda sebenarnya boleh memaparkan respons pelayan sebelum penghidratan berlaku. useActionState akhirnya boleh menerima rentetan dengan url halaman unik yang bertujuan untuk diubah suai oleh borang. Dalam erti kata lain, ia juga boleh menerima parameter pautan kekal pilihan, yang amat berguna untuk peningkatan progresif - ia memberitahu penyemak imbas tempat untuk menavigasi jika pengguna menyerahkan borang sebelum JavaScript dimuatkan.
Akhir sekali, tuple yang useActionState kembalikan ialah tatasusunan yang terdiri daripada keadaan semasa (semasa pemaparan awal anda ialah nilai initialState anda), formAction yang diubah suai tindak balas yang anda boleh hantar ke borang sebagai tindakan atau butang sebagai prop, dan bendera isPending/pembolehubah stateful. Saya tidak sabar-sabar untuk melihat perkembangan baharu lain yang akan dihasilkan oleh pasukan React, kerana yang ini nampaknya amat berguna.
Kemas kini React-DOM
Tambahan react-dom ini akan biasa kepada sesiapa sahaja yang telah menggunakan NextJS dan tindakan borang, dan nampaknya pasukan Reac telah memutuskan tindakan borang sedia untuk masa perdana. Bagi sesiapa yang belum menggunakannya dalam NextJS atau rangka kerja lain selain daripada tindak balas, ia pada asasnya adalah cara untuk meningkatkan prestasi React dengan menggunakan penyerahan borang asli. Daripada onClick, anda boleh menghantar penyerahan borang asli melalui prop tindakan - sebarang fungsi yang dihantar kepada tindakan atau formAction akan mempunyai penyerahannya secara automatik. React juga akan menetapkan semula secara automatik mana-mana medan borang yang tidak terkawal. Anda juga mempunyai pilihan manual untuk menetapkan semula melalui API. Pasukan React juga telah menyepadukan pengendalian ralat dengan sempadan ralat. Saya tidak akan bercakap terlalu banyak mengenainya kerana saya mengandaikan kebanyakan orang mengingati mereka daripada NextJS, tetapi saya boleh menulis susulan jika sesiapa mempunyai soalan.
gunakan cangkukFormStatus
Ini adalah tambahan yang bagus untuk membantu anda melihat perkara yang berlaku dalam borang anda tanpa penggerudian prop atau menggunakan konteks - jika anda bertanya mengapa tidak gerudi prop, ia ada kaitan dengan memastikan kod boleh diselenggara dan mudah diubah suai. Bagi konteks, penggunaan konteks yang berlebihan akan menyebabkan masalah prestasi kerana setiap komponen yang melanggan konteks tertentu akan dipaparkan semula apabila sesuatu dalam konteks berubah. Jadi ia menyahkan kod, mengurangkan kemungkinan ralat dan menghalang anda daripada menyusun prestasi apl anda.
Cakuk mengembalikan objek dengan empat sifat: belum selesai - boolean yang menyatakan jika terdapat penyerahan yang belum selesai, data - objek formData dengan data yang diserahkan oleh borang induk (ini adalah batal jika tiada penyerahan aktif atau borang induk ), kaedah (dapatkan atau siarkan) dan tindakan - iaitu tindakan yang dilalui melalui prop tindakan.
gunakan cangkuk Optimis
Cara baharu yang lebih mudah untuk mengurus kemas kini yang optimistik. Jika anda tidak biasa dengan kemas kini optimistik, ini bermakna mengemas kini paparan sisi klien sebelum kemas kini bahagian pelayan berlaku. Jika anda pernah menyukai sesuatu, melihat animasi dimainkan dan memintanya mendaftar pada skrin anda sebagai disukai, kemudian menerima ralat roti bakar yang mengatakan "suka gagal", ini disebabkan oleh pemaparan yang optimistik.
Kait useOptimistic menerima pembolehubah stateful yang anda mahu berikan secara optimistik dan fungsi kemas kini, yang mestilah fungsi tulen - dengan kata lain, fungsi deterministik tanpa kesan sampingan. Pada asasnya, fungsi kemas kini mendapatkan semula sumber kemas kini untuk dinyatakan - jadi biasanya sesuatu seperti formData.get(‘name’). useOptimistic kemudian mengembalikan dua nilai: keadaan optimistik dan fungsi addOptimistic.
Saya dapati dokumentasi untuk ini agak lemah, terutamanya di sekitar aliran penggunaan - pada asasnya, anda memanggil useOptimistic dan memberikannya keadaan awal yang anda mahu memaparkan kemas kini optimistik dan fungsi kemas kini. Anda menerima dua fungsi - nilai stateful yang baru dipertingkatkan optimistik (optimisticState) dan fungsi untuk menukar keadaan secara optimistik. Apabila anda mempunyai nilai baharu yang diserahkan oleh pengguna, anda memanggil fungsi kedua, yang dirujuk sebagai addOptimistic dalam dokumen dan memberikannya nilai yang diserahkan pengguna. Dalam komponen anda, anda kemudian memberikannya nilai stateful yang dipertingkatkan optimistik apabila anda mahu menjadikan stateful var secara optimistik.
Secara keseluruhan, saya sangat menyukai cara yang lebih standard untuk melaksanakan kemas kini optimistik ini - Saya sebelum ini menghadapi masalah dengan caching dalam NextJS dan membuat kemas kini optimistik, jadi cara piawai untuk mencipta kemas kini optimistik adalah bagus, dan saya pasti ini akan gelembung sehingga NextJS, jika ia belum lagi.
API penggunaan
Ini ialah API yang sangat padat dan ini merupakan cara baharu untuk mengakses sumber semasa bertindak balas sedang memaparkan halaman - frasa tepat yang digunakan ialah "sumber membaca dalam pemaparan". Jadi untuk apa secara khusus? API baharu ini boleh digunakan untuk mengakses maklumat komponen di dalam syarat atau gelung. Jika anda tidak biasa dengan sebab ini berguna, ia ada kaitan dengan cara proses pemaparan React berfungsi. React/react-fiber bergantung pada pemaparan semuanya dalam susunan yang sama setiap kali, itulah sebabnya anda tidak boleh mengakses kebanyakan cangkuk semasa proses pemaparan. Untuk menyatakannya dengan lebih jelas, keadaan sebenarnya dijejaki berdasarkan pesanan cangkuk yang dipanggil, jadi jika cangkuk dipanggil dalam susunan yang tidak dapat diramalkan, anda akan mengalami pepijat rendering. Satu contoh yang bagus ialah mengakses konteks tema bergantung pada sama ada pengguna log masuk atau tidak.
Jadi mengapa ini merupakan perkembangan penting? Ini bermakna anda boleh memuatkan maklumat/data hanya apabila ia benar-benar perlu, mis. hanya jika pengguna benar-benar log masuk anda akan memuatkan css untuk tema khas. Data tersebut perlu bersiri, jadi ini bermakna anda boleh menghantar janji daripada komponen pelayan kepada komponen pelanggan semasa ia sebenarnya sudah dalam penerbangan - ini bermakna terdapat lebih sedikit permintaan air terjun dan ia secara automatik diletakkan selari. Perlu diingat bahawa apabila bekerja dalam Komponen Pelayan, anda sebenarnya lebih suka menggunakan async/menunggu daripada penggunaan untuk pengambilan data - ini kerana async/menunggu akan menyambung semula pemaparan dari tempat ia berhenti, manakala penggunaan akan mencetuskan pemaparan semula penuh komponen selepas data diselesaikan. Sudah tentu, saya juga ingin ambil perhatian bahawa perubahan ini sebenarnya juga bermakna anda mempunyai potensi sumber permintaan air terjun baru jika anda mengkonfigurasi penggunaan dengan salah.
Satu perkara yang sangat penting untuk diambil perhatian ialah anda tidak boleh menggunakan API "gunakan" dalam blok cuba/tangkap - ini kerana "penggunaan" secara automatik menggunakan sempadan penggantungan tindak balas apabila dipanggil dengan janji. Blok cuba/tangkap menghalang anda daripada mencapai tahap tindak balas kerana sebarang ralat sebenarnya akan menghentikan pelaksanaan pada tahap JS sebelum anda mencapai React, memecahkan fungsi. Seperti cangkuk lain, ia mesti berada dalam skop tahap teratas bagi komponen atau fungsi tertentu (sekali lagi, disebabkan tertib render).
Jadi, apakah tujuan sebenar "penggunaan" adalah untuk membantu anda mengakses konteks untuk menjadikan sesuatu secara bersyarat dan hanya mengambil data apabila ia benar-benar perlu. Ini adalah satu lagi langkah ke arah membuat tindak balas yang agak kurang misteri, memudahkan pengambilan data bersyarat, meningkatkan pengalaman pembangun dan meningkatkan prestasi semua dalam satu gerakan. Ia memerlukan pembangun React yang lebih berpengalaman untuk mempelajari semula cara melakukan perkara seperti tema, tetapi saya fikir ia menjadikan rangka kerja lebih mudah diakses oleh pengguna baharu, yang sentiasa hebat.
API Statik React Dom Baharu
Dua API statik baharu ini, prapemarahan dan prapemarahanToNodeStream kedua-duanya adalah penambahbaikan kepada renderToString, yang digunakan untuk Perenderan Sisi Pelayan (SSR). Penambahbaikan baharu ini adalah untuk melakukan Penjanaan Tapak Statik (SSG) menggunakan renderToString. Tidak seperti SSR penstriman tradisional yang boleh menghantar sebahagian kandungan apabila ia tersedia, API baharu ini secara khusus menunggu SEMUA data dimuatkan sebelum menjana HTML akhir. Mereka direka bentuk untuk berfungsi dengan lancar dengan persekitaran penstriman moden seperti Node.js Streams dan Web Streams, tetapi mereka sengaja tidak menyokong penstriman kandungan separa - sebaliknya, mereka memastikan anda mendapat halaman yang lengkap dan dimuatkan sepenuhnya pada masa binaan. Ia berbeza daripada kaedah SSR penstriman tradisional, yang menghantar tapak pra-diberikan apabila data tersedia.
Kami sudah mempunyai rangka kerja berkemampuan SSG yang dibina di atas React, seperti NextJS, tetapi ini bertujuan untuk menjadi fungsi asli React untuk SSG. Rangka kerja yang mempunyai SSG menggunakan renderToString, kemudian membina koordinasi pengambilan data kompleks mereka sendiri di sekelilingnya. Ini amat sukar untuk pengguna mencipta sendiri, dan rangka kerja ini menggunakan saluran paip yang sangat kompleks untuk berbuat demikian. Apa yang dilakukan oleh kaedah baharu ini pada asasnya membenarkan data dimuatkan semasa penjanaan HTML statik, Jika anda tidak biasa dengan SSG, ia pada asasnya memaparkan segala-galanya pada masa binaan, dan sudah pasti kaedah terpantas untuk memaparkan halaman, kerana ia tidak mempunyai untuk memaparkan halaman atas permintaan pengguna, jadi sangat bagus untuk mempunyai fungsi seperti ini untuk orang yang tidak mahu menggunakan sesuatu seperti Next, yang sama ada memerlukan penggunaan pada Vercel atau yang sangat kompleks proses penempatan.
Komponen Pelayan
Konsep Komponen Pelayan Bertindak balas bukan perkara baharu kepada sesiapa sahaja yang menggunakan versi terbaharu NextJS, tetapi bagi sesiapa yang belum menggunakannya, komponen pelayan ialah paradigma baharu mengenai pengambilan data. Secara terang-terangan, konsep Komponen Pelayan (dan Tindakan Pelayan) layak untuk keseluruhan artikel itu sendiri, tetapi untuk meringkaskan konsep secara ringkas, komponen pelayan sentiasa diberikan pada pelayan sebelum dihantar kepada klien, walaupun selepas javascript dimuatkan. Ini bermakna pemaparan berikutnya dilakukan di bahagian pelayan.
Kelebihan utama komponen ini ialah keselamatan dan pengambilan data: jika anda meminta data di dalam komponen pelayan, maklumat permintaan tidak pernah muncul di sisi klien, hanya respons, menjadikannya lebih selamat. API, titik akhir, dsb. semata-mata tidak boleh diakses oleh pihak pelanggan. Ia juga mengurangkan saiz berkas kerana javascript untuk tindakan tersebut tidak pernah dihantar kepada pelanggan. Ia juga membolehkan anda melaksanakan memori atau operasi intensif secara pengiraan pada pelayan untuk mengurangkan beban pemaparan pada mesin yang kurang berkuasa. Mereka juga mengurangkan air terjun sisi pelanggan kerana pengambilan data berurutan boleh dilakukan pada mesin yang lebih dekat dengan pangkalan data anda, tetapi sudah tentu ia juga membuka kemungkinan air terjun sisi pelayan yang serba baharu kerana pembangun anda kehilangan akses kepada maklumat permintaan mudah daripada pembangun penyemak imbas ujian alat dan perlu menggunakan sesuatu seperti pengumpul dan penonton OpenTelemetry untuk memeriksanya. Akhir sekali, komponen pelayan juga bagus untuk peningkatan progresif.
Komponen pelayan juga disertakan dengan senarai had: anda tidak boleh menggunakan API penyemak imbas setempat (storan tempatan, tetingkap, dll), cangkuk tindak balas akan berfungsi secara berbeza, anda tidak boleh bergantung atau menggunakan keadaan dan anda boleh' t menggunakan pengendali acara, jadi interaktiviti pengguna untuk komponen adalah jelas tipis. Pada asasnya, fikirkan paradigma ini sebagai pengambilan data dalam komponen pelayan, interaktiviti pada komponen klien.
Kaveat paling penting untuk sesiapa yang baru menggunakan komponen pelayan ialah anda tidak boleh mengimportnya ke dalam komponen klien - jika anda melakukannya, ini akan ralat (dengan mengandaikan anda telah menambah beberapa pengambilan data) kerana ia menyebabkan pengkompil merawat kata tersebut komponen pelayan sebagai komponen klien. Jika anda ingin menghantar komponen pelayan kepada komponen klien, anda perlu menghantarnya melalui prop {children}.
Tindakan Pelayan
Ini adalah satu lagi topik yang kompleks dengan banyak implikasi tentang cara anda membina produk dan ciri anda, dan ini juga telah hadir dalam NextJS selama setahun atau lebih. Tindakan pelayan diisytiharkan dengan menaip 'guna pelayan' di bahagian atas fail dan memberikan rujukan terus kepada fungsi pelayan tersebut yang kemudiannya boleh dipanggil dari dalam komponen klien.
Pada tahap tertentu, ini secara konsepnya serupa dengan Panggilan Prosedur Jauh (RPC) - kedua-duanya membenarkan anda memanggil fungsi sisi pelayan daripada klien, kedua-duanya mengabstrakkan kerumitan interaksi pelanggan-pelayan, dan kedua-duanya mengendalikan pensirilan dan penyahserilan, tetapi terdapat beberapa perbezaan utama yang perlu diketahui. Faedah utama tindakan pelayan ialah ia berfungsi dengan peningkatan progresif React, membantu menguatkuasakan keselamatan jenis merentasi sempadan pelanggan/pelayan, mempunyai pengoptimuman prestasi terbina dalam (berkaitan dengan peningkatan progresif), dan mempunyai penyepaduan yang lebih lancar dengan ekosistem React kerana ia menyediakan keadaan belum selesai terbina dalam dan disepadukan secara automatik dengan penyerahan borang asli.
Apabila anda bercakap tentang RPC moden, sesuatu seperti gRPC yang sudah mempunyai keselamatan jenis dan beberapa pengoptimuman prestasi, kelebihan utama tindakan pelayan biasanya berpunca daripada pengendalian borang terbina dalam dan peningkatan progresif, tetapi yang penting ia juga berfungsi dengan suspens tindak balas dan sempadan ralat. Paling penting, penggunaan adalah lebih mudah kerana anda tidak semestinya perlu menyediakan pelayan berasingan untuk gRPC, jadi ini benar-benar lebih sesuai untuk projek yang lebih kecil, walaupun apabila ia melibatkan projek yang lebih besar, saya dapat melihat gRPC menjadi lebih diingini sejak ia memberi anda lebih fleksibiliti dari segi bahasa hujung belakang, dsb.
Konteks sebagai Penyedia
Ini pada asasnya adalah penyederhanaan sintaks, membantu React secara umum mempunyai sintaks deklaratif yang lebih bersih. Sejujurnya saya tidak mempunyai banyak perkara untuk diperkatakan tentang perkara ini selain daripada "Saya sukakannya".
Rujuk sebagai Prop & Fungsi Pembersihan untuk Ruj
Sebelum ini, untuk membersihkan rujukan, anda perlu melakukan semakan nol di dalam komponen anda dan ref akan dibersihkan pada masa yang agak tidak tentu. React akan memanggil panggil balik ref anda dengan null apabila komponen dinyahlekap, memerlukan anda mengendalikan kedua-dua kes lampiran dan detasmen secara eksplisit. Kelebihan sintaks ref baharu ialah pembersihan deterministik - yang bermaksud kini lebih mudah untuk bekerja dengan sumber luaran dan pustaka pihak ketiga kerana anda akan mengetahui dengan tepat apabila pembersihan ref berlaku (pada dinyahlekap). Dengan pendekatan baharu, anda boleh mengembalikan fungsi pembersihan secara langsung. Penyepaduan TypeScript memerlukan pernyataan pulangan yang jelas untuk mengelakkan kekaburan tentang fungsi pembersihan.
Saya sangat menyukai cara ini dilaksanakan kerana ia adalah corak yang sama daripada useEffect - mengekalkan konsistensi merentas rangka kerja adalah bagus. Saya rasa pembersihan ref baharu ini secara khusus akan sangat berguna untuk konteks WebGL dan sumber berat lain, tetapi juga untuk mengendalikan pendengar acara DOM yang ditambahkan menggunakan kaedah JS asli. Ini kerana sebelum ini, react akan mengalih keluar ref kepada elemen dom semasa pembersihan…Tetapi jika anda telah melakukannya, ia menjadi lebih rumit untuk mengalih keluar pendengar acara kerana anda telah kehilangan rujukan kepada komponen yang dilampirkan padanya. . Akibatnya, anda terpaksa menyimpan rujukan anda di luar elemen, menambah lapisan kerumitan. Kini anda hanya boleh mengalih keluar pendengar acara dalam fungsi pemulangan komponen anda kerana anda mengekalkan akses kepada ref di dalam fungsi pemulangan tersebut. Ini juga bermakna kita tidak perlu lagi bimbang tentang kes null dalam kebanyakan situasi, kerana React tidak akan memanggil ref dengan null lagi apabila menggunakan fungsi pembersihan. Fungsi pembersihan itu sendiri menggantikan fungsi itu, menjadikan kod kami lebih bersih dan lebih mudah diramal.
gunakanDeferredValue
Tujuan cangkuk useDeferredValue adalah untuk mengurus operasi pengiraan yang mahal sambil mengekalkan antara muka pengguna yang responsif. Ia mencapai ini dengan membenarkan komponen menunjukkan nilai "lapuk" sebelumnya semasa mengira atau mengambil data baharu di latar belakang. Kes penggunaan biasa ialah kefungsian carian yang memaparkan hasil semasa menaip pengguna - tanpa menangguhkan, setiap ketukan kekunci boleh mencetuskan operasi carian mahal yang membuatkan input terasa lembap. Menggunakan useDeferredValue, antara muka boleh kekal responsif dengan menunjukkan hasil carian sebelumnya sambil mengira yang baharu.
Tambahan baharu ini merupakan peningkatan penting pada gelagat pemuatan awal cangkuk ini. Sebelum ini, pemaparan pertama akan serta-merta menggunakan apa-apa nilai yang dihantar untuk useDeferredValue, yang berpotensi mencetuskan pengiraan yang mahal pada mulanya. Versi baharu membolehkan anda memberikan nilai awal yang ringan (seperti rentetan kosong) yang dipaparkan serta-merta, sambil memproses nilai yang lebih mahal di latar belakang. Ini bermakna anda boleh menunjukkan maklum balas segera kepada pengguna dengan nilai lalai yang selamat, kemudian mengemas kininya dengan data sebenar setelah pengiraan mahal selesai. Pada asasnya, ini menjadikan useDeferredValue lebih baik untuk peningkatan prestasi.
Tambahan Metadata Dokumen
Perubahan baharu ini adalah untuk menambahkan pelbagai teg metadata di dalam komponen sebenar. Terdapat tiga pilihan yang mereka lalui:
Faedah utama daripada perubahan ini ialah ia membenarkan komponen benar-benar serba lengkap: mereka kini boleh mengurus metadata mereka sendiri bersama-sama dengan gaya dan skrip mereka. Anda tidak perlu memikirkan cara untuk meningkatkan metadata ke peringkat teratas atau menggunakan perpustakaan untuk melakukannya lagi, yang menjadikan SEO lebih mudah dilakukan. Halaman yang berbeza dalam SPA boleh mempunyai metadata yang berbeza dengan lebih mudah tanpa risiko metadata menjadi tidak segerak dengan kandungan yang dipaparkan pada halaman, yang sebelum ini merupakan risiko apabila mempunyai metadata yang berbeza untuk halaman yang berbeza.
Sokongan Lembaran Gaya
Orang ramai mungkin telah menggunakan tailwind sekian lama sehingga mereka terlupa, tetapi menjalankan CSS tidak berkapsul boleh menimbulkan isu disebabkan cara helaian gaya dimuatkan - iaitu memuatkan peraturan keutamaan tertib. Mula-mula, anda boleh berakhir dengan kilat kandungan tidak digayakan - bila-bila masa HTML dimuatkan dan dipaparkan sebelum CSS selesai dimuat turun, ia dipaparkan sebagai halaman putih sepenuhnya, biasanya dalam satu lajur dengan saiz fon besar dan saiz imej asli, yang selalunya menjadikannya tidak boleh dibaca.
Selain itu, peraturan pesanan memuatkan CSS boleh menimbulkan masalah lain: contohnya, jika anda mempunyai peraturan dengan kekhususan yang sama tetapi mengharapkan peraturan tersebut dimuatkan dalam susunan tertentu. Ini berkaitan, sebagai contoh, apabila anda mempunyai pilihan yang berbeza untuk tema (cth. mod gelap). Jika CSS mod gelap bertujuan untuk dimuatkan terakhir, tetapi fail CSS anda untuk mod gelap dimuatkan dahulu, anda boleh berakhir dengan mod gelap menjadi terang atau beberapa bahagian apl yang mematuhi peraturan dan bahagian lain di mana ia berada' t berpegang kepada.
Terdapat banyak penyelesaian untuk mengelakkan perkara ini, seperti CSS dalam JS, memuatkan semua CSS dalam
teg, membina masa gabungan CSS bersama-sama, dsb. Walau bagaimanapun, perubahan CSS baharu ini bertujuan untuk membantu mengurus isu ini dengan menetapkan keutamaan secara deklaratif - ia juga memastikan sebarang helaian gaya yang diletakkan dalam komponen dimuatkan sebelum komponen itu sendiri dipaparkan. Ia juga telah dibina dalam deduping, jadi anda tidak akan memuatkan helaian gaya yang sama beberapa kali apabila anda menggunakan semula komponen dengan pautan helaian gaya disertakan.Cara anda mengakses kefungsian baharu ini (menunggu css dimuatkan sebelum memaparkan komponen, menaikkan CSS secara automatik ke kepala, dll.) juga agak mudah - anda hanya perlu memasukkan keutamaan dalam Sokongan Skrip Async Ini menangani kes kelebihan, berbanding mencipta kefungsian teras baharu untuk orang ramai bimbang - menambah/mengurus skrip secara manual dengan Memandangkan skrip boleh dimuatkan secara tidak segerak, ini bermakna terdapat peluang yang jauh lebih rendah untuk bertindak balas memuatkan apl tanpa gaya yang betul. Perubahan itu juga berkaitan untuk pembangun yang mengurus sistem warisan yang memerlukan teg skrip langsung atau pembangun yang bertanggungjawab mengurus skrip pihak ketiga yang tidak boleh digabungkan (cth. analitis, widget, dll.), atau menghalang skrip yang sangat berat (cth. video pemain) memuatkan sebelum perlu untuk meningkatkan prestasi, tetapi kerana saya tidak mempunyai pengalaman dengan mereka, saya tidak boleh mengulas lebih daripada itu. Sokongan untuk Pramuat Sumber API baharu untuk mengurus pramuat sumber agak menarik, terutamanya untuk perusahaan yang lebih besar yang perlu memastikan pengalaman pemuatan yang lancar untuk khalayak global dengan keadaan rangkaian yang berbeza-beza, terutamanya apl berat kandungan yang bergantung pada sumber pihak ketiga yang berat daripada sumber yang berbeza , dan untuk mana-mana apl yang persepsi prestasi adalah penting untuk pengekalan pengguna (sejujurnya, hampir segala-galanya) Walau bagaimanapun, kebanyakan rangka kerja yang berada di atas tindak balas (cth. Seterusnya, Remix, dll.) cenderung untuk menguruskan perkara ini - Saya tidak pasti bagaimana API baharu ini akan berinteraksi dengan rangka kerja tersebut, tetapi nampaknya seperti itu' Ia akan menjadi sumber konflik baharu dan sesuatu yang penting untuk diingat apabila menggunakan rangka kerja ini dan cuba mengoptimumkan prestasi menggunakan API baharu ini. Walaupun pramuat pastinya API dengan kes penggunaan terluas (memuatkan lembaran gaya dll.), terima kasih kepada isu di atas, yang saya rasa paling relevan ialah preinit - ia adalah beban keras yang bermula serta-merta dan bertujuan untuk memuatkan dengan penuh semangat skrip. Penggunaan paling jelas yang boleh saya fikirkan ialah seperti memuatkan jalur pada semakan troli beli-belah dengan serta-merta - ini seharusnya mempercepatkan proses pembayaran dengan ketara, yang merupakan langkah e-dagang yang anda tidak mahu kehilangan pelanggan kerana isu prestasi. . Keserasian Skrip Pihak Ketiga Ini adalah perubahan yang sangat dialu-alukan memandangkan betapa bertambahnya alat tambah penyemak imbas - beberapa contoh yang boleh saya fikirkan tentang pengubahsuaian struktur DOM yang mungkin mendapat manfaat daripada perubahan ini ialah penyekat iklan, alat perbandingan harga, tambahan pembantu tatabahasa/AI dan sambungan terjemahan . Tidak banyak lagi yang boleh dikatakan tentang perkara ini tanpa benar-benar membaca cara penghidratan berfungsi sekarang, walaupun nampaknya perubahan utama ialah pengkompil melangkau teg yang tidak dijangka. Pelaporan Ralat yang Lebih Baik Saya dapati bahagian ini cukup jelas. Perubahan pengendalian ralat sentiasa dialu-alukan - spam ralat yang wujud sebelum ini sentiasa menyukarkan sedikit untuk mengesan ralat tertentu. Ini amat relevan jika anda menggunakan beberapa penyelesaian pihak ketiga yang kurang diselenggarakan dengan baik yang cenderung mencetuskan banyak ralat. Bahagian ini sangat menarik bagi saya kerana saya tidak pernah mendengar tentang Elemen Tersuai sebelum ini. Ikhtisarnya ialah Elemen Tersuai ialah standard web baharu untuk membolehkan pembangun mencipta elemen HTML mereka sendiri. Terima kasih kepada mengikut piawaian web tersebut, ia bertujuan untuk berfungsi pada mana-mana halaman dan menjadi rangka kerja agnostik - contohnya anda boleh menulis komponen yang biasa anda gunakan dalam semua projek peribadi anda, yang anda cenderung lakukan secara ringkas, kemudian gunakannya untuk lebih kecil kerja kontrak yang anda lakukan untuk syarikat pemula atau kontrak jangka pendek dalam vue, dsb. React digunakan untuk menganggap prop yang tidak dikenali sebagai atribut dan bukannya sifat sebenar - kemas kini baharu telah menambah sistem yang membolehkan prop digunakan dengan betul untuk mencipta elemen tersuai. Nampaknya dengan perubahan ini, kini terdapat sokongan penuh untuk menggunakan Elemen Tersuai sebagai tindak balas. Di samping itu, sebagai tambahan kepada isu prop, pernah juga terdapat ketidakserasian (kini diselesaikan) dengan sistem peristiwa sintetik reaksi - Elemen Tersuai tidak dapat disepadukan dengan sistem, jadi terdapat beberapa kes di mana anda sebenarnya terpaksa melakukannya secara manual tambahkan pendengar acara dengan ref, antara penyelesaian lain. Atas ialah kandungan terperinci React Update Notes Companion. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
Sokongan untuk Elemen Tersuai
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
