---
title: "JSS Angularサンプルアプリにおけるルーティングおよび状態管理"
slug: "routing-and-state-management-in-the-jss-angular-sample-app"
abstract: "JSS Angularサンプルアプリにおけるクライアントサイドおよびサーバーサイドのルーティングおよび状態管理フロー"
---
# JSS Angularサンプルアプリにおけるルーティングおよび状態管理

サンプルアプリは [レイアウトサービス](https://doc.sitecore.com/xp/ja/developers/hd/19/sitecore-headless-development/layout-service.html "Layout Service") (または切断モードのローカル [ルートデータファイル](https://doc.sitecore.com/xp/ja/developers/hd/19/sitecore-headless-development/types-of-jss-manifest-data.html "Types of JSS Manifest data") )に基づく動的ルーティングを使用し、ルートやナビゲーションの変更によってアプリの状態変更をトリガーします。主要な実行フローの追跡はルート設定から始めなければなりません。

## クライアント側ルーティング

クライアント側ルーティングはウェブブラウザ上で行われます。以下はクライアント側のルーティングフローを説明します。

-   ルート変更(または初期負荷)がトリガーされ、src/app/routing/routing.module.tsで設定されたAngularルーティングが発生します。
-   ほとんどのURLはJSS *のキャッチオール* ルートに移行しますが、これはローカルアプリケーションがSitecoreで設定されているすべての潜在的なルート(アイテムやページ)を把握していないため必要です。
-   キャッチオールルートはパスではなくマッチャー、具体的にはjssRouteMatcher関数で構成されます。この関数はJssRouteBuilderServiceを使ってURLをSitecoreフォーマットのルートとして解析しようと試みます。 /language/then/the/item/path/。
-   jssRouteMatcher関数は言語とserverRouteパラメータを返し、それらは設定されたルートリゾルバに提供されますJssRouteResolver。
-   JssRouteResolver最初にJssContextServicechangeRouteを呼び起こす。
-   JssContextServiceクライアント側では、以下のいずれかからルートを取得します:
    -   サーバーレンダリング直後に統合またはヘッドレスサーバーサイドレンダリング(SSR)モードで動作する場合、サーバー側レンダリング状態を含む必要があるTransferStateからルートデータを取得しようと試みます。この場合、レイアウトサービスへのHTTP呼び出しはスキップされます。
    -   それ以外の場合、ルートデータはSitecoreレイアウトサービスへのHTTP呼び出しを通じて取得されます。
-   JssContextServiceは現在のルート状態を保持し、JssRouteResolverに返します。ルートリゾルバはエクスペリエンスエディターのサポートに必要なルーチンを実行します。
-   最後に、設定されたルートコンポーネント(routing.module.tsで定義され、デフォルトはapp/routing/layout/layout.component.ts)がsrc/app/app.component.tsで定義されたルーターアウトレットに読み込まれ、ルートリゾルバからのデータが提供されます。このレイアウトコンポーネントは以下の責任を負います:
    -   HTTP 404や500などのデータ取得エラーに対するUIの処理。
    -   ページタイトルやその他のメタフィールドなどのルートレベルの状態を更新すること。
    -   ページタイトルやその他のメタフィールドなどのルートレベルの状態を更新すること。

## サーバーサイドルーティングとデータ転送

AngularアプリがNodeサーバーによってプリレンダリングされると、最初の応答でクライアントにHTMLを返します。つまり、ルートデータフローはクライアント側のルーティングに似ていますが、いくつかの重要な違いがあります。

以下は、サーバー側のルートデータフローがクライアント側のルーティングとどのように異なるかを説明します。

-   最初のステップは適用モードによって異なります:
    -   [統合モード](https://doc.sitecore.com/xp/ja/developers/hd/19/sitecore-headless-development/start-a-jss-app-in-integrated-mode.html "Start a JSS app in integrated mode")のみでは、Sitecoreはリクエストを受け取り、サーバー側でルートを解析し、リクエストされたアイテムがJSSアプリケーションによって処理されているか、またどのバンドルを実行するかを判断します。
    -   [ヘッドレスモードのみ](https://doc.sitecore.com/xp/ja/developers/hd/19/sitecore-headless-development/headless-server-side-rendering-mode.html "Headless server-side rendering mode")では、Node SSRプロキシがリクエストを受け取り、それをSitecoreレイアウトサービスに渡します。
-   ノードホストはserver.bundle.tsアーティファクト内のrenderView関数を呼び出します。関数の引数にはルートデータ/レイアウトサービスの出力が含まれます。
-   renderView関数はAngular SSRを使ってアプリケーションをレンダリングし、モジュールの初期化には2つの重要な違いがあります。
    -   このアプリは、一部のサービスのサーバー固有の実装を提供する AppServerModuleを使用しています。
    -   初期ルート状態はJSS\_SERVER\_TO\_SSRインジェクショントークンを用いて依存注入によって注入されます。
-   ルーティングはサーバーサイドで実行され、サーバーサイドの実装JssServiceを呼び出します。
-   JssServerServiceはJSS\_SERVER\_TO\_SSRインジェクショントークンからのルートデータを返し、クライアント側で読み取るためにデータをTransferStateに入れます。
-   ルートレンダリングはクライアント側と同様に継続されます。