は、だから私は怠惰なロードされた機能モジュールと、比較的大規模なアプリケーションを持っており、それらのモジュール内の特定のデータ構造に取り組む一連の構成要素、例えば：angular2セットサービスプロパティは、
/thing/123/profile /thing/123/subscriptions /thing/123/history
これらのコンポーネントは、解決ガードを使用して、URLで参照されるデータID（123）が適切なデータ構造を支配的なthingサービスに確実にロードするようにします。解決ガードは、このサービスデータを優先的に使用して、兄弟経路のナビゲーションでデータを繰り返し調べることを避け、コンポーネントが（profile,subscriptions,history）サービスから単にthingを使用するだけで、解決ガードの努力に無関係読み込まれました。データがサービスにロードされている場合、resolveはそれを使用し、そうでない場合、ルート解決中にルックアップします。
いいですね。まあまあ2.0.Xの何かのまわりで、解決のガードはルート解決の間にデータでサービスを更新するのを止めました。
個々のコンポーネントのOnInitにActivatedRoute.data.forEach()を使用すると、解決ガードが実際にデータを読み込んだことがわかりましたが、現時点でサービスに戻すことができますが、私は避けようとしています特に、ほとんどの場合（兄弟ナビゲーション）、データはすでにサービスに設定されているため、各子コンポーネントのルートデータチェックを再実装する必要があります。解決ガードは、自らのデータメンバーを設定する問題のthingサービスから観測可能です。オブザーバブルが実行されるときにサービス内で値が適切に設定されます。適切にルートデータに解決されます。ルートがロードされるまでにこのデータはサービスから消えてしまいました...
これは、完全なURLをロードする場合にのみ問題です。解決がデータを新鮮にロードしなければならない最終ルートのリフレッシュ - ルートにナビゲートする前にサービスに入っている場合、それは問題ありません。
私は後で簡単な例をあげてplunkrを組み立てることができますが、実際のアプリからすぐにそれを取り除く時間はありませんが、誰かがこの動作を見ているのか、 （ルート解決の目的のためにベースアプリケーションに注入されたサービスではスコープが問題になりますが、ルートがロードされた後はフィーチャモジュールなどで）、またはこれが予期しない動作であるかどうかを確認します。
tl; dr - ルート解決中にサービスが自分自身でプロパティを正しく設定するのはなぜですか（ルートが実際にロードされるとそのプロパティは設定されません）。これは1つのフィーチャモジュールに固有のものではなく、アプリケーション全体で一貫しているため、ルートパラメータの解決をサービスに抽象化する機能が破壊され、コンポーネントはルックアップを知らないままになります。前もって感謝します！
サービスを提供する場所と関係がありますか？解決されたルートデータが最初に設定された後、どこかで再初期化される可能性はありますか？ –
@Fredrik - これは良い考えです。私はサービスコンストラクタをトレースして、ある時点で再作成されているかどうかを確認しますが、理由はわかりませんが、それは提供する機能モジュール – derelict