Rumah >hujung hadapan web >tutorial js >Kesalahan Kebanyakan Orang Mengenai Istilah SSR

Kesalahan Kebanyakan Orang Mengenai Istilah SSR

Susan Sarandon
Susan Sarandonasal
2024-12-02 08:07:11774semak imbas

Istilah Perenderan Sebelah Pelayan (SSR) sering disalahfahamkan, dengan ramai yang menggunakannya untuk menerangkan amalan yang mendahului penciptaannya atau tidak layak secara teknikal. Daripada templat PHP kepada apl isomorfik React, takrifan SSR telah berkembang—dan begitu juga kekeliruan di sekelilingnya.

Artikel ini menyelami asal usul SSR, maksudnya sebenarnya dan sebab memahami perbezaan itu penting dalam pembangunan web moden.

Jadi Inilah Tawarannya

Kami tidak mempunyai SSR pada zaman PHP. Istilah itu tidak wujud. Ia dicipta pada tahun 2010-an. Tiada siapa yang memanggil perkara ini sebagai SSR sebelum itu.

Apa yang mereka panggil? Jika anda percaya Wikipedia, ia dipanggil skrip sisi pelayan (berbanding dengan skrip sisi klien).

Fakta menggembirakan: jika anda menyemak Wikipedia, mereka tidak pun menambah "SSR" pada artikel skrip sebelah pelayan sehingga 2021. Inilah perbezaannya. Dan secara jujur? Saya rasa ini salah.


Sebelum SSR, Ada...

Sehingga React memperkenalkan istilah "rendering", kami tidak menggunakan perkataan itu. Perkara paling dekat yang kami ada ialah templat sisi pelayan. Berikut adalah petikan lama.

Ideanya mudah: anda akan menggunakan penjana tapak statik atau skrip pelayan untuk membina halaman web dinamik anda.

Sesetengah orang berpendapat: "Nah, jika saya menggunakan templat pelayan, saya akan memaparkannya pada pelayan."


Masalah Dengan Itu

Perenderan dalam React tidak selalu bermakna menghasilkan HTML atau DOM. Ia menghasilkan VDOM (DOM maya). Garisan kabur apabila anda memanggil renderToString kerana komponen itu sebenarnya diberikan kepada HTML.

Inilah sebabnya orang mula mendakwa apl PHP mereka melakukan SSR. Tetapi inilah isunya: ini kehilangan perbezaan antara SSR sebenar dan skrip dinamik biasa.


Perbezaan Utama

Anda hanya boleh melakukan SSR pada bahagian yang juga boleh dipaparkan pada pelanggan.

Contohnya:

const App = () => <div onClick={handleClick}>Hello</div>;

Anda boleh menjalankan aplikasi ini dua kali: sekali pada pelayan dan sekali pada klien.

Tetapi:

<div><?php echo "Hello"; ?></div>

Ini tidak boleh dijalankan pada pelanggan. Tiada pemaparan di sini—tiada perbezaan "sebelah pelanggan" atau "sebelah pelayan". Ini hanyalah skrip dinamik lama.


SR lwn SSR

What Most People Get Wrong About the Term SSR

Memandangkan tiada siapa yang menggunakan istilah lama itu lagi (kecuali mungkin dalam ASP), saya rasa saya berputus asa dan hanya memanggilnya Rendering Pelayan (SR) lwn. Rendering Sebelah Pelayan ( SSR).

Satu perbezaan besar ialah penghidratan.

Dalam dunia PHP, tiada penghidratan, tetapi mereka masih pasti mereka mempunyai SSR. Itu tidak masuk akal. Anda hanya boleh mempunyai SSR jika anda mempunyai penghidratan.


Penghidratan: Kunci

React mempunyai dua kaedah utama:

  • renderToStaticMarkup: Menghasilkan HTML yang anda tidak dijangka menghidrat. Ini lebih dekat dengan templat pelayan.
  • renderToString: Menghasilkan HTML yang terhidrat pada klien. Ini adalah SSR.

Angular Universal tidak mempunyai SSR sehingga 2023. Apa yang mereka ada ialah SR: menghasilkan HTML pada pelayan, kemudian menjatuhkannya sebaik sahaja skrip dimuatkan dan menjadikan apl sebagai SPA menjadi tag.

Itu tidak sama dengan PHP, tetapi ia juga tidak sama dengan SSR sebenar.


Zaman Awal

Awalnya, apl React telah "diprapaparkan" menggunakan Chrome tanpa kepala untuk menyimpannya sebagai rentetan HTML. Gambar itu masuk ke dalam CDN. Secara teknikalnya, pelayan tidak diperlukan untuk membuat ini berfungsi. ?

Ia adalah satu usaha yang sia-sia, tetapi Google mengesyorkannya untuk SEO pada satu ketika. Saya menjejaki artikel itu sekali, tetapi saya tidak pasti sama ada saya boleh menemuinya lagi.


Mengapa Peduli Tentang Ini?

Komponen Pelayan Bertindak balas (RSC) memaksa kami untuk melawat semula topik ini.

Secara teknikal, RSC tidak melakukan SSR. Ini mengejutkan ramai orang.

Pasukan React cuba menerangkannya tetapi berputus asa. Intinya ialah komponen pelayan hanyalah templat—ia menghasilkan HTML statik. Komponen pelanggan melalui SSR untuk menghasilkan kedua-dua HTML dan DOM.


Inertia.js dan SSR

Inertia.js membuat perbezaan yang serupa. PHP berjalan pada pelayan, tetapi apl JavaScript anda mendapat SSR dengan berjalan pada pelayan untuk menghasilkan HTML dan kemudian menghidratkan pada klien.


Jadi, Bolehkah PHP Melakukan SSR?

Tidak. Seperti RSC, PHP sedang melakukan skrip dinamik (SR) dengan langkah yang melakukan SSR.

Jika anda menjalankan apl React dengan perisian tengah seperti Hono, menyuntik beberapa kod dinamik ke dalam HTML dan kemudian memanggil renderToString, rasanya serupa. Dalam kedua-dua kes, ia adalah SR dengan langkah SSR.

Itulah sebabnya menjadi gila apabila orang mendakwa, "Kami melakukan SSR dalam PHP pada tahun 90-an."


Bagaimana dengan SSG?

Setiap kali saya mengutarakan perkara ini, ada yang bertanya tentang SSG. saya tak kisah.

Istilah Penjanaan Tapak Statik (SSG) sebenarnya mendahului React. SSG bermaksud menghasilkan HTML—tiada pemaparan atau penghidratan diperlukan. Adakah anda menghasilkan HTML? Tahniah, anda sedang membuat SSG.


Inovasi React

Rangka kerja React diperkenalkan apl isomorfik, menggunakan penghidratan untuk menggunakan HTML pada klien tanpa menciptanya semula.

HTML itu terpaksa dihasilkan oleh SSR.


Qwik dan “Kebolehsambungan semula”

Adakah Qwik melakukan penghidratan? Itulah soalan besar.

Pembangun Qwik mengatakan tidak, tetapi saya cenderung kepada ya. Jika anda suka Qwik, anda perlu memotong satu lagi SSR dan memanggilnya Kebolehsambungan semula.


Jika anda lebih suka mendengar perbincangan daripada membaca, anda boleh mendengar lebih banyak hujah ini dalam bentuk audio daripada episod podcast ini tentang Komponen Pelayan React dalam Go

Atas ialah kandungan terperinci Kesalahan Kebanyakan Orang Mengenai Istilah SSR. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn
Artikel sebelumnya:Kod bersih mudah #1Artikel seterusnya:Kod bersih mudah #1