PWA Kit アプリのデバッグ

バグとパフォーマンスのボトルネックは、Web アプリの開発で避けようのない部分です。PWA Kit では、アプリを詳細に検討するためのツールやテクニックを使用して、これらの問題の根本に迫ることができます。

このガイドに記載されている特定の問題に焦点を絞ったアドバイスに従う前に、以下の一般的なトラブルシューティングの手順を試してみてください:

  • ローカル開発サーバーを起動する前に、サポートされているバージョンの Node を実行していることを再度確認します (入門ガイドを参照)。
  • 開発サーバーが現在実行されていることと、ポートが別のプロセスで使用されていないことを確認します。
  • コードの変更後、ブラウザーを再度読み込む前に、HTTP development server listening というメッセージがターミナルに表示されることを確認します。
  • ブラウザーコンソールとターミナルの両方でエラーを探します。
  • ブラウザーの開発ツールを使用して、ネットワークエラーレスポンスを探します。(Chrome のデベロッパーツールで Network (ネットワーク) タブを開きます。)
  • 構文エラーやミススペルを見つけるために、コードの formatter と linter を実行します。Retail React App では、Prettier (code formatter) と ESLint (linter) の両方に対して構成ファイルが提供されています。
  • コンピューターのアンチウィルスとファイアウォールの設定で、コードの実行を阻止しているものや、ネットワークリクエストをブロックしているものがないかを確認します。
  • パフォーマンスの問題を識別および分析するには、Chrome のデベロッパーツールで Profiler を使用します。詳細については、Google によるガイドの Analyze Runtime Performance (ランタイムパフォーマンス分析) を参照してください。また、Chrome 向けの React Developer Tools 拡張機能をインストールして、コンポーネントレベルで同様の情報を表示できる別の Profiler タブを取得できます。

コマースアプリによって処理される任意の URL に 2 つの特別なクエリパラメーターを追加して、サーバー側コードに関する問題をデバッグできます。

__server_only クエリパラメーターは、ページがサーバー側のレンダリング後とまったく同じようにブラウザーに表示されるように、ハイドレーション プロセスを停止します。サーバー側にレンダリングされるページのバージョンを見ることで、サーバー側のレンダリングの問題だけでなく、SEO に関する問題のトラブルシューティングも行うことができます。これは、検索エンジンはこのバージョンのページをクロールするためです。

__pretty_print クエリパラメーターは __PRELOADED_STATE__ オブジェクトに形式を追加し、読みやすくします。このオブジェクトは、ハイドレーションが始まる前に、アプリの状態にスナップショットを提供します。このため、予想する値が含まれているかを確認することでデバッグの助けとなります。オブジェクトのコンテンツを表示するには、アプリを読み込み、ページのソースを表示し、__PRELOADED_STATE__ を検索します。

__PRELOADED_STATE__ オブジェクトは、アプリがサーバー側で実行を開始する際に最初にリクエストされるページの HTML ソース内の <script> タグに含まれています。__PRELOADED_STATE__ オブジェクトは getProps 関数から返されたシリアル化された値を含みます (_app コンポーネントとページコンポーネントにアタッチされた getProps のバージョンを含む)。

デフォルトでは、アプリサーバーはターミナルにコンソールメッセージを表示しますが、それ以外はコードの実行を観察することはできません。この制限によって、サーバー側で (またはローカルマシンで) ページのレンダリングを行うコードのデバッグが難しくなります。

デバッグを向上させるために、デバッガーをアタッチできる Node でインスペクタープロセスを実行する代替コマンドを使用してローカル開発サーバーを起動できます。(詳細については、Node のドキュメントを参照してください。)

広く使用されている多くのブラウザーやテキストエディターに付属しているデバッガーを、Node のインスペクタープロセスにアタッチできます。以下に、Google Chrome と Visual Studio Code での手順を示します。

  1. ターミナルを開きます。
  2. プロジェクトディレクトリに移動します。
  3. npm run start:inspect を使用してローカル開発サーバーを起動します。
  4. デバッガーがリッスンしていることを確認するために、ターミナルの出力で “Debugger listening” (デバッガーがリッスン中) というメッセージを探します。
  5. Chrome を開き、URL に chrome://inspect と入力します。
  6. Open dedicated DevTools for Node (Node 専用 DevTools を開く) をクリックします。
  7. DevTools が新しいウィンドウに開きます。
  8. デバッガーがアタッチされていることを確認するために、ターミナルの出力で “Debugger attached” (デバッガーがアタッチ済み) というメッセージを探します。
  9. ブレークポイントの設定や、debugger ステートメントの追加などを行います。
  10. Chrome でローカル開発サーバーからページを読み込みます。
  11. デバッグには専用のウィンドウを使用します。

これでサーバー側コードの実行をトレースできます。

DevTools でのブレークポイントを使用したデバッグの詳細については、Google によるガイドの Debug JavaScript (Javascript のデバッグ) を参照してください。

  1. Visual Studio Code でプロジェクトファイルを開きます。
  2. メニューバーで、Terminal (ターミナル) > New Terminal (新規ターミナル) の順に選択します。
  3. npm run start:inspect を使用してローカル開発サーバーを起動します。
  4. コマンドパレットを開きます。Windows のショートカット: Ctrl + Shift + P。Mac のショートカット: Command + Shift + P
  5. 次のコマンドを入力します: “Debug: Attach to Node Process.”
  6. Node プロセスのリストが表示されます。リストの最初のプロセスを選択します。
  7. デバッガーがアタッチされていることを確認するために、ターミナルの出力で “Debugger Attached” (デバッガーがアタッチ済み) というメッセージを探します。
  8. ブレークポイントの設定や、デバッガーステートメントの追加などを行います。
  9. Web ブラウザーでローカル開発サーバーからページを読み込みます。
  10. Visual Studio Code に統合されているデバッガーを使用してデバッグを行います。

これで Visual Studio Code でサーバー側コードの実行をトレースできます。

Node プロセスを繰り返しアタッチしなくてもいいようにするには、コマンドパレットを開いて、“Debug: Toggle Auto Attach” と入力します。設定を Always (常時) に切り替えて、Visual Studio Code ターミナルでローカル開発サーバーを再起動します。

アプリが Managed Runtime にデプロイされる場合、リモートデバッグはサポートされません。ただし、Managed Runtime 環境のログをリアルタイムで追跡して、サーバー側のエラーの診断に役立てることができます。

コマンドラインを用いてログを追跡するには、以下の 2 つのオプションがあります。

バージョン 2.4.1 以降で生成された PWA Kit プロジェクト内で作業している場合、次のことができます。

  • ログコマンドのヘルプの表示: npm run tail-logs -- --help
  • 特定のプロジェクトおよび環境のログの追跡: npm run tail-logs -- --environment $ENV_ID

上記コマンドでは追加の--が必須です。

PWA Kit プロジェクト外で作業している場合、またはバージョン 2.4.1 より前のバージョンで生成されたプロジェクトで作業する場合は、npxを使用して次のことができます。

  • ログコマンドのヘルプの表示: npx @salesforce/pwa-kit-dev tail-logs --help
  • 特定の環境 ID とプロジェクト ID のログの追跡: npx @salesforce/pwa-kit-dev tail-logs --environment $ENV_ID --project $PROJ_ID

--environment および --project 引数の代わりに、より短い -e および -p 引数を使用することもできます。

ログを追跡する場合は、次の点に注意してください。

  • 各ログ追跡セッションは 60 分後に終了します。
  • 各環境では、すべてのユーザーに対しアクティブなログ追跡セッションを一度に 100 セッションまでサポートできます。
  • ログを追跡するには、Managed Runtime プロジェクトに対し、デベロッパーまたは管理者としてのユーザー許可を取得している必要があります。