Panduan Lengkap Pembangun Junior untuk SSR, SSG dan SPA-tutorial js-php.cn

The Junior Developer

Setiap syarikat alat pembangun dan -pasukan nampaknya menganggap bahawa Junior Devs sudah biasa dengan istilah ini.

Apabila saya mula membuat kod, saya melihatnya di mana-mana: Nuxt ialah rangka kerja SSR, anda boleh menggunakan Gatsby untuk SSG dan anda boleh mendayakan mod SPA jika anda menetapkan bendera ini atau itu dalam next.config.js anda.

Apa kejadahnya?

Sebagai langkah pertama, berikut ialah glosari – walaupun ia tidak akan membantu anda memahami butiran:

CSR = Rendering Sebelah Pelanggan
SPA = Permohonan Satu Halaman
SSR = Rendering Sebelah Pelayan
SSG = Penjanaan Tapak Statik

Seterusnya, mari kita berikan sedikit cahaya ke dalam kegelapan.

Pelayan Web Statik

Pada mulanya, tapak web ialah fail HTML yang anda minta daripada pelayan.

Pelayar anda akan bertanya kepada pelayan, "Hei, bolehkah anda menyerahkan halaman itu kepada saya?" dan pelayan akan bertindak balas dengan fail about.html. Penyemak imbas anda tahu cara menghuraikan fail tersebut dan menghasilkan tapak web yang cantik seperti ini.

Kami memanggil pelayan sedemikian pelayan web statik. Seorang pembangun menulis HTML dan CSS (dan mungkin sedikit JS) dengan tangan, menyimpannya sebagai fail, meletakkannya ke dalam folder, dan pelayan menghantarnya atas permintaan. Tiada kandungan khusus pengguna, hanya kandungan umum, statik (tidak berubah) yang boleh diakses oleh semua orang.

app.get('/about', async (_, res) => {
  const file = fs.readFileSync('./about.html').toString();
  res.set('Content-Type', 'text/html');
  res.status(200).send(file);
})

Salin selepas log masuk

Apl Web Interaktif & Kandungan Khusus Permintaan

Tapak web statik, bagaimanapun, membosankan.

Lebih seronok bagi pengguna jika dia boleh berinteraksi dengan tapak web. Jadi pembangun membolehkannya: Dengan sentuhan JS, dia boleh mengklik pada butang, mengembangkan bar navigasi atau menapis hasil cariannya. Web menjadi interaktif.

Ini juga bermakna halaman /search-results.html akan mengandungi elemen berbeza bergantung pada perkara yang dihantar pengguna sebagai parameter carian.

Jadi, pengguna akan menaip ke dalam bar carian, tekan Enter dan menghantar permintaan dengan parameter cariannya ke pelayan. Seterusnya, pelayan akan mengambil hasil carian daripada pangkalan data, menukarnya kepada HTML yang sah dan mencipta fail /search-results.html yang lengkap. Pengguna menerima fail yang terhasil sebagai respons.

(Untuk memudahkan membuat HTML khusus permintaan, pembangun mencipta bahasa templat HTML, seperti Bar Hendal.)

app.get('/search-results', async (req, res) => {
  const searchParams = req.query.q;
  const results = await search(searchParams);

  let htmlList = '<ul>';
  for (const result of results) {
    htmlList += `<li>${result.title}</li>`;
  }
  htmlList += '</ul>';

  const template = fs.readFileSync('./search-results.html').toString();
  const fullPage = embedIntoTemplate(htmlList, template);

  res.set('Content-Type', 'text/html');
  res.status(200).send(fullPage);
});

Salin selepas log masuk

Lencongan singkat tentang "membawa"

Untuk masa yang paling lama, saya dapati istilah merender sangat mengelirukan.

Dalam maksud asalnya, perenderan menerangkan komputer mencipta imej yang boleh diproses manusia. Dalam permainan video, contohnya, perenderan merujuk kepada proses mencipta, katakan, 60 imej sesaat, yang boleh digunakan oleh pengguna sebagai pengalaman 3D yang menarik. Saya tertanya-tanya, sudah mendengar tentang Rendering Sisi Pelayan, bagaimana ia boleh berfungsi — bagaimanakah pelayan boleh memaparkan imej untuk dilihat oleh pengguna?

Tetapi ternyata, dan saya menyedari ini agak terlambat, bahawa "perenderan" dalam konteks Pelayan- atau Penyampaian Sebelah Pelanggan bermaksud perkara yang berbeza.

Dalam konteks penyemak imbas, "rendering" mengekalkan makna asalnya. Pelayar ada memaparkan imej untuk dilihat oleh pengguna (tapak web). Untuk berbuat demikian, ia memerlukan cetak biru tentang rupa hasil akhir. Rangka tindakan ini datang dalam bentuk fail HTML dan CSS. Penyemak imbas akan mentafsirkan fail tersebut dan memperoleh daripadanya perwakilan model, Model Objek Dokumen (DOM), yang kemudiannya boleh dibuat dan dimanipulasi.

Mari petakan ini kepada bangunan dan seni bina supaya kita dapat memahaminya dengan lebih baik: Terdapat pelan tindakan rumah (HTML & CSS), arkitek mengubahnya menjadi model fizikal berskala kecil di mejanya (DOM) jadi bahawa dia boleh memanipulasinya, dan apabila semua orang bersetuju dengan hasilnya, pekerja binaan melihat model itu dan "menjadikannya" menjadi bangunan sebenar (imej yang dilihat pengguna).

Apabila kita bercakap tentang "membawa" dalam konteks Pelayan, bagaimanapun, kita bercakap tentang membuat, berbanding menghuraikan, fail HTML dan CSS. Ini dilakukan terlebih dahulu supaya penyemak imbas boleh menerima fail untuk ditafsirkan.

Beralih kepada Rendering Sisi Pelanggan, apabila kita bercakap tentang "rendering", kami maksudkan memanipulasi DOM (model yang dicipta oleh penyemak imbas dengan mentafsir fail HTML & CSS). Penyemak imbas kemudian menukar DOM kepada imej yang boleh dilihat oleh manusia.

Rendering Sebelah Pelanggan & Aplikasi Satu Halaman (SPA)

Dengan peningkatan platform seperti Facebook, pembangun memerlukan interaktiviti yang lebih dan lebih pantas.

Memproses klik butang dalam apl web interaktif mengambil masa — fail HTML perlu dibuat, ia perlu dihantar melalui rangkaian dan penyemak imbas pengguna perlu memaparkannya.

All that hassle while the browser could already manipulate the website without requesting anything from the server. It just needed the proper instructions — in the form of JavaScript.

So that's where devs placed their chips.

Large JavaScript files were written and sent to the users. If the user clicked on a button, the browser would insert an HTML component; if the user clicked a "show more" button below a post, the text would be expanded — without fetching anything.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <body>
    <div id="root"></div>
    <script>
      document.addEventListener('DOMContentLoaded', () => {
        const root = document.getElementById('root');

        root.innerHTML = `
            <h1>Home</h1>
            <button>About</button>
        `;

        const btn = document.querySelector('button');
        btn.addEventListener('click', () => {
          root.innerHTML = `
            <h1>About</h1>
        `;
        });
      });
    </script>
  </body>
</html>

Salin selepas log masuk

Though the code snippet suggests the opposite, developers didn't write vanilla JavaScript.

Ginormous web apps like Facebook had so much interactivity and duplicate components (such as the infamous Like-button) that writing plain JS became cumbersome. Developers needed tools that made it simpler to deal with all the rendering, so around 2010, frameworks like Ember.js, Backbone.js, and Angular.js were born.

Of them, Angular.js was the one that brought Single Page Applications (SPAs) into the mainstream.

An SPA is the same as Client-Side Rendering, but it is taken a step further. The conventional page navigation, where a click on a link would fetch and render another HTML document, was taken over by JavaScript. A click on a link would now fire a JS function that replaced the page's contents with other, already preloaded content.

For this to work properly, devs needed to bypass existing browser mechanisms.

For example, if you click on a