プロジェクトの背景
このプロジェクトでは、パーソナライズされた共有の問題を1週間以内に解決する必要があり、急を要しました。
このプロジェクトは初期段階でVue-cliを使用して作成され、数ヶ月の間、数十ページで開発を繰り返してきました。共有時にタイトル/説明/イメージなどの情報をカスタマイズする問題を解決する必要がありますが、Vue-cliでは単一ページのアプリケーションしか作成できず、コンテンツページでは投稿内容に基づいて動的にMeta情報を設定することができません。
当時は主に2つのプログラムがありました。
オプション1: SSRをサポートするようにVue-cliを変更する方法
このオプションを検討する理由は、2つの理由がある、1、Reactのssrプロジェクトを使用しての経験がある、あなたがから学ぶことができます;2、プロジェクトは、ユーザー側の製品であり、軽量化と柔軟性を維持する必要がある場合は、サードパーティのフレームワークのより多くの使用は、私はそれが対象となることを恐れている、その結果、高フォローアップのメンテナンスコストは、要素- uiの以前の使用の削除など、多くのエネルギーを要した。
このソリューションの特徴は、ビジネスロジックのコードはほとんどそのままで、ssr部分はゼロから始める必要があるということです。
オプション2:プロジェクトのビジネスコードをNuxtJSに移行します。
NuxtJSを使ったことがあるので、比較的慣れています。そして、NuxtJSは長年の開発で非常に成熟しています。このソリューションの特徴は、ssrの部分は基本的に心配する必要がないのですが、ビジネスコードの移行過程でどのような問題が発生するかという概念がないことです。
どちらの選択肢にも不確実性があるため、まずは最初の選択肢を選んで試してみてください。
プログラムIの実施
このオプションは最終的に失敗したので、カスタムSSRのキーポイントを簡単に説明します。
ssrでは、プロジェクトをクライアントサイドとサーバーサイドの両方で実行する必要があります。client-entry.jsはmain.jsに相当し、server-entry.jsはnodejsに相当します。
すべてのビジネスコードについて、ノード環境との互換性が必要です。再利用が難しいコードについては、2つのコピーを書いて、1つはブラウザだけで実行し、もう1つはノードだけで実行します。より多くのシナリオについては、実行環境がブラウザかどうかを判断して異なる処理を行うことができます。以下に例を示します:
function isBrowser() {
return typeof window !== 'undefined'
}
- サーバサイドで遅延する必要のないプロジェクトで使用されるvueコンポーネントには、もっと簡単な解決策があります。それは、vueプロジェクトに付属するクライアント専用のコンポーネントにコンポーネントを入れることです。例を以下に示します:
<client-only>
<my-swiper />
</client-only>
なぜあきらめるのか
ビルドツール。spaの選択をssrに変更するには、ビジネスコードだけでなく、ビルドツール、特にvue-cli関連のビルドに精通することも大きな課題の一つです。例えば、npm run serve:ssrの開発環境を作るには、vue-cliプラグインのやり方に精通している必要があります。
ssrは予想以上に考慮すべき要素が多いです。例えばMetaのセットアップですが、サードパーティの成熟したvue-metaを使った方がいい匂いがします。
プログラム II の実施
NuxtJSはドキュメントが非常に充実していますが、実戦で重要なポイントを理解するのに短い時間しかない人にとっては、誰かに助けてもらうのが一番です。例えば、公式サイトにはプラグインの使い方について書かれている箇所があるのですが、それがサーバーサイド/クライアントサイドの業務コードの互換性に対応するための推奨方法であることをすぐに理解することができませんでした。
最終的な移行作業は比較的スムーズでした。ちょっとした落とし穴を踏んだ国際化コードの部分を除けば。具体的な移行手順は以下の通り: