Angular ルート再利用の実装戦略

この記事では主に Angular のルート再利用戦略についての簡単な説明を紹介します。編集者はそれを参考として共有します。編集者をフォローして見てみましょう。皆さんのお役に立てれば幸いです。

1. はじめに

ルーティングは、実行中にコンポーネントに対してステートレスに動作します。つまり、コンポーネントのステータスもルートが終了すると削除されます。これは、ほとんどのシナリオで妥当です。

しかし、場合によっては、特別なニーズによって人々が半死状態になることもあります。これはすべてユーザー エクスペリエンスのためであり、ユーザーがモバイル端末でキーワードやそのようなリストを使用して商品を検索するという非常に一般的なシナリオです。死んでいるかどうかの判断は通常、自動次ページ アクションです。このとき、ユーザーが最終的に 2 ページ目にスクロールして、見たい製品が見つかると、製品の詳細ページに誘導され、バックします。 ..ユーザーは混乱しています。

Angular ルーティングとコンポーネントは、RouterModule.forRoot を通じて最初から関係を形成します。これがルーティングの本質です。

そして、各ルートは必ずしも 1 回限りの消費ではありません。Angular は RouteReuseStrategy を使用してルーティング状態を実行し、コンポーネントを構築する方法を決定します。もちろん、最初に述べたように、デフォルトでは何も処理されません。

RouteReuseStrategy は 2 から実験的であり、現在も実験的です。これは長い間信頼できるはずです。

2. RouteReuseStrategy

私はこれをルート再利用戦略と呼んでいます。これは複雑ではなく、いくつかのわかりやすいメソッドを提供します:

• ルートの再利用を許可するかどうかを決定する

• ストアルートが離れるときにトリガーされます。保存されたルート

• を復元するには、ルート

• を取得します。同じルートが再利用されるかどうかを確認します。

これは、タイムラインの関係に似ています。言語的には、次のようになります。再利用を許可するようにルート/リストを設定し ( shouldDetach )、 shouldReuseRoute が確立されたときにルートのスナップショットをストアに保存します。 /list ルートを再度検出した後、ルートを再利用する必要がある場合は、最初に shouldAttach で復元が許可されているかどうかを判断し、最後にコンポーネントの取得とビルドからルート スナップショットを取得します。

• この原理を理解すると、最初に検索リストから返された問題を取り上げると、非常に簡単に解くことができます。

3. 例

上で説明したように、ルート使用戦略をカスタマイズするには、RouteReuseStrategy インターフェイスを実装するだけで済みます。

1. 戦略を作成します

import {RouteReuseStrategy, DefaultUrlSerializer, ActivatedRouteSnapshot, DetachedRouteHandle} from '@angular/router';

export class SimpleReuseStrategy implements RouteReuseStrategy {

  _cacheRouters: { [key: string]: any } = {};

  shouldDetach(route: ActivatedRouteSnapshot): boolean {
    return true;
  }
  store(route: ActivatedRouteSnapshot, handle: DetachedRouteHandle): void {
    this._cacheRouters[route.routeConfig.path] = {
      snapshot: route,
      handle: handle
    };
  }
  shouldAttach(route: ActivatedRouteSnapshot): boolean {
    return !!this._cacheRouters[route.routeConfig.path];
  }
  retrieve(route: ActivatedRouteSnapshot): DetachedRouteHandle {
    return this._cacheRouters[route.routeConfig.path].handle;
  }
  shouldReuseRoute(future: ActivatedRouteSnapshot, curr: ActivatedRouteSnapshot): boolean {
    return future.routeConfig === curr.routeConfig;
  }
}

データ (ルーティング スナップショットと現在のコンポーネント インスタンス オブジェクト) をキャッシュするための _cacheRouters を定義します。

shouldDetach は直接 true を返し、すべてのルートで再利用が許可されていることを示します。ルートが離れると

store がトリガーされます。パスをキーとして使用して、ルーティング スナップショットとコンポーネントの現在のインスタンス オブジェクトを保存します。このパスは RouterModule.forRoot の設定と同等です。
shouldAttach パスがキャッシュに存在する場合、ルートの復元が許可されているとみなされます
retrieve キャッシュからスナップショットを取得します。存在しない場合は null を返します
shouldReuseRoute ルートトリガーを入力します同じルートかどうかを判断するため
2. 登録

• 最後に、戦略をモジュールに登録します:

providers: [
 { provide: RouteReuseStrategy, useClass: SimpleReuseStrategy }
]

このようなルーティング設定があると仮定します:

RouterModule.forRoot([
 { path: 'search', component: SearchComponent },
 { path: 'edit/:id', component: EditComponent }
])

検索コンポーネントは検索アクションに使用されます。検索結果に基づいて編集ページに移動し、最終的な検索結果のステータスを保存した後に戻ります (コードのこの部分は投稿しません。plnkr を参照することに興味があります)。

4. 結論

上記は簡単な紹介にすぎませんが、実際には、スクロールバーの位置やキャッシュのクリーニングなど、再利用の判断はさらに複雑になります。

このルーティング再利用戦略メカニズムをうまく利用すると、Web エクスペリエンスの多くの問題を解決できます。

関連する推奨事項:

angular2 ルーティングのプリロード例の詳細な説明

以上がAngular ルート再利用の実装戦略の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。