前フリ

ルーティングモジュールを作ってはいるけれど、中身は空っぽ。

app-routing.module.ts

@NgModule({
  imports: [RouterModule.forRoot(ルーティング設定した配列)],
  exports: [RouterModule]
})
export class AppRoutingModule {}

疑問

空っぽのルーティングモジュールいるんかなぁと思っていました。
もしかしたら、なんかいろいろ楽しい機能追加できるん？

回答

とか考えていたら、答えが書いてありました。

Do you need a routing module

曰く

The Routing Module replaces the routing configuration in the root or feature module. Either configure routes in the Routing Module or within the module itself but not in both.

The Routing Module is a design choice whose value is most obvious when the configuration is complex and includes specialized guard and resolver services. It can seem like overkill when the actual configuration is dead simple.

ルーティングモジュールは、ルートモジュールや機能モジュール内のルーティング設定を置き換えます。ルーティング設定はどちらか一方に書けばよいです。両方はいりません。

ルーティング設定が複雑かつ特別なガードやサービスリゾルバを含む場合は、設計的にルーティングモジュールを作成することも選択肢です。ルーティング設定がめちゃくちゃ簡単であればオーバーキル¹かもしれません。

Some developers skip the Routing Module (for example, AppRoutingModule) when the configuration is simple and merge the routing configuration directly into the companion module (for example, AppModule).

開発者によっては、設定が単純であればルーティングモジュール（例えば、AppRoutingModule）は作成せず、その随伴モジュール（例えば、AppModule）に直接設定を書くかもしれません。

Choose one pattern or the other and follow that pattern consistently.

Most developers should always implement a Routing Module for the sake of consistency. It keeps the code clean when configuration becomes complex. It makes testing the feature module easier. Its existence calls attention to the fact that a module is routed. It is where developers expect to find and expand routing configuration.

どちらかのパターンを選択し、一貫してそれに従いましょう。

ほとんどの開発者は、一貫性のためにルーティングモジュールを作成します。ルーティング設定が複雑になってきたとき、コードをシンプルに保つことができるからです。また機能モジュールのテストが容易になります。ルーティングモジュールが存在することで、その(ルート

機能)モジュールにルーティングがあるという事実に注意を惹けます。ルーティング設定がどこにあってどこをいじればよいのか、開発者はの期待に沿うことにもなるでしょう。

結論

オーバーキルかもしれんけど、人に見せる機会があるモジュールならルーティングモジュール作っておいたほうがよい。

さらなる疑問

実は、イベントハンドラ定義したりして、色々楽しいことできたりする？？？そんなことない？？
↑
しつこい

（筆者のどうでもいい感想）ゲームとか戦闘モノ以外の文脈で「オーバーキル」って初めて見たかも。 ↩