JavaScript を理解するにはサーバー側レンダリングを使用する必要がありますか?

JavaScript学習チュートリアル列では、サーバーサイドレンダリングを使用するかどうかを紹介します。

まえがき

最近 React サーバーサイド レンダリング プロジェクトを開始しました。これを使用する必要がありますか?それは主にシーンによって異なります。

よく話題になるSEOやファーストスクリーンレンダリングに適しており、一般的にはtocビジネスで必要となります。

同型性

最新のフレームワークのサーバー側レンダリングと jsp および php の間には、まだ多くの違いがあります。 nextjs と nuxtjs はサーバー側のレンダリングだけでなく、同型フレームワークでもあるためです。

同型写像とは何ですか?つまり、コードはブラウザーとサーバーの両方で実行できます。これは、サーバー側での NodeJS の人気によるものです。

jsp、php、django などの従来のサーバー側レンダリング フレームワークはすべて、従来の MPA マルチページ モードと同様に html 文字列を返します。そのため、ページを切り替えるとページが更新され、css ファイルと js ファイルが再度要求されるため、ユーザー エクスペリエンスが低下します。

現在人気のあるフロントエンド開発モデルは SPA シングル ページです。これは、更新せずにページを切り替える H5 履歴に基づいており、より良いユーザー エクスペリエンスを実現できます。

つまり、nextjs と nuxtjs はサーバーサイド レンダリングをサポートするだけでなく、SPA もサポートします。サーバーサイド レンダリングはホームページによく使用され、他のページは SPA の非更新アクセス モードを維持します。

Django を使用して書かれたページがありますが、メンテナンスが非常に困難です。なぜなら、どれがフロントエンドを担当し、どれがバックエンドを担当するかを明確に伝えることができないからです。したがって、これを維持するには、フロントエンドとバックエンドの両方で Python と Django を学習する必要があり、メンテナンス コストが大幅に増加します。

実際のアプリケーション シナリオに関しては、サーバー側のレンダリングに適したいくつかのシナリオがここにあります。

サポート投稿リクエスト

1 つは再構築された h5 ページです。プロジェクトは以前シンガポールのチームによって Python Django を使用して書かれていたため、一部のページはサードパーティ Web サイトの投稿フォームが開きます。

再構築された H5 ページはすべて Tencent Cloud CDN にハングしており、Post で開くことができません。 Get に変更してみてはいかがでしょうか?なぜなら、これは彼らが以前に交わした協定であり、銀行は皆父親であるため、彼らは私たちのために協定を変えるつもりはないからです。

ページの機能は比較的シンプルなので、再構築のスケジュールに追いつくために、当時私の隣にいた友人は、ES5 構文のみをサポートする Express EJS を使用したバージョンを実装しました。 。

その後要件が何度か変更になり、元のページに機能を追加するのが面倒です。たとえば、JS Bridge を実装したい場合、microbundle を使用して既存の npm パッケージを umd ファイルにパッケージ化し、それを script タグを使用してインポートすることしかできません。

ダイナミック レンダリング タイトル

先ほど別の要件に遭遇しました。複数のバンクに同じ H5 ページを実装する必要があります。関数は次のとおりです。基本的にはすべて同じですが、アプリのヘッダーには異なる銀行の名前を表示する必要があります。

AirPay アプリでは、クライアントが Web ビューを開くと、HTML 内のタイトルを読み取り、ネイティブ ヘッダーのタイトルとして設定します。

コード内で document.title を使用すると、動的設定は有効になりません。動的にヘッダーを設定できるのは、JS Bridge を介してのみです。

ただし、このページは AirPay によって使用されるだけでなく、Shopee によっても提供されるため、2 セットの JS Bridge と互換性がある必要があり、これは利点を少し上回ります。

ただし、サーバー側直接出力方式を使用すると、サーバー側で表示する必要があるタイトルを直接決定し、それを HTML タイトルに設定できます。これも適切なビジネス シナリオです。

そこで、前のプロジェクトに基づいて、React による同型アプリケーションの開発をサポートするために、React サーバーサイド レンダリング機能が追加されました。 Next はここでは使用されていません。私が実装した一連の同型写像だけです。

一般的な実装アイデアは、isomorphic-style-loader と universal-router を使用して、スタイルとルートの同型性を処理することです。サーバーはデータを取得した後、それを window._INITIAL_STATE__## に出力します。 #. ブラウジング時 プロセッサは、データの同型性を達成するためにこの初期化データを取得します。

同時に、Express ルーティングに基づいて配布されるオリジナルの EJS テンプレートが保持され、EJS を使用してレンダリングしたり、React サーバーから直接エクスポートしたりできます。

このページは、第 1 フェーズでは Tencent Cloud CDN にハングしています。第 2 フェーズでは、サーバーサイド レンダリングが使用されます。明らかに読み込み速度が速くなっていることがわかります。以前も引き続き表示されます。

プロセス監視の観点から見ると、部門全体のノード サービスは上司が作成したノード エージェントを使用して実行されており、さまざまな主要な昇進のテストに耐えてきました。

欠点

もちろん、サーバーサイド レンダリングを悪用すべきではありません。

たとえば、社内のバックエンド管理システムは Nuxt を利用しており、ローカル ビルドにはそれぞれ 10 分かかるようになり、開発効率に大きな影響を与えています。

Nuxt の機能は依然として非常に強力で、たとえばルートに応じてビルド ファイルを動的に分割したり、Nuxt-link ルーティング コンポーネントにマウスを置くと JS ファイルをプリロードしたりします。

但實際上帶來的收益幾乎為零，因為我們不需要 SEO，也不需要提高首屏載入速度。

幾乎組裡面每個人都有嘗試用各種手段去優化構建，但效果不是很明顯。直到最近開始做微前端拆分，才曲線解決這個問題。

除此之外，服務端渲染在寫法上也和客戶端渲染有些差別，容易導致 bug。

例如下面在 Vuex 的 state 檔案裡面的這段程式碼：

const date = moment().format('YYYY-MM-DD')
export default () => ({  
date
})

打開頁面的時候，時間應該要顯示的是今天。就算頁面放置剛好跨天了，打開再刷新也應該是當天時間。

但在 Nuxt 裡面，這個展示的日期就是你服務啟動那天的日期，不管你怎麼刷新，它永遠不會改變。

因為Nuxt 初始化的時候會把這些資料存到store 裡面，後續再怎麼刷新，這個檔案也不會在服務端重新加載，因為模組會被Node 快取起來，所以日期就不會更新。

但在客戶端渲染裡面，由於頁面刷新會導致瀏覽器端重新載入 JS 文件，這個日期也會重新計算。

推薦（免費）：Javascript學習教學

以上がJavaScript を理解するにはサーバー側レンダリングを使用する必要がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。