SSR/SSGに関する改善
SSR（Server-Side Rendering、サーバーサイドレンダリング）はサーバー側でWebページの内容を生成する技術、SSG（Static Site Generation、静的サイト生成）はコンパイル時にWebページの内容を生成しておく技術で、いずれもパフォーマンス向上の効果が期待できます。Angular 17ではSSR/SSGへの対応が改善されました。
SSR/SSG対応プロジェクトを生成可能に
Angular 17では、Angular CLIでのプロジェクト生成時にSSR/SSGを有効にする選択肢が提供されるようになりました（図9）。なお、Angular 16で開発プレビューとして導入されたハイドレーションがAngular 17では正式版となり、SSR/SSGを有効にするとデフォルトで有効になります（ハイドレーションについてはAngular 16の紹介記事も参照してください）。
ここでは、図9の指定で生成したプロジェクトをもとに実装したサンプル（p005-ssr-ssg、図10）で、Angular 17のSSR/SSG対応について説明していきます。このサンプルではルート（URLのパス）によって、「ルーターの出力」部の内容が変わります。
このサンプルのルートと、「ルーターの出力」部に表示されるコンポーネントは表1の通りです。実装の詳細はサンプルコードを参照してください。
| No. | ルート | 表示されるコンポーネント |
|---|---|---|
| 1 | /（ホーム） | DefaultComponent |
| 2 | /comp1 | Comp1Component |
| 3 | /comp2 | Comp2Component |
| 4 | /comp1/<ID> | Comp1Component（コンポーネント内にIDが表示される） |
このサンプルを「ng build」コマンドでビルドすると、dist/p005-ssr-ssgフォルダーに成果物が出力されます。このうち、browserフォルダー（クライアント側の成果物）を見ると、SSGにより、表1のNo.1～3のルートに対応する静的ページのindex.htmlが出力されていることがわかります（No.4のルートはIDが可変なので、SSGで静的ページを生成できません）。
成果物を動作させるには、serverフォルダー（サーバー側の成果物）に含まれるserver.mjsを指定して、「node server.mjs」と実行し、Webブラウザーで「http://localhost:4000」にアクセスします。表1のNo.1～3のルートにアクセス（してWebブラウザーを再読込）した時はSSGによる静的ページが表示され、SSGで静的ページが生成されないNo.4のルートにアクセスした時は、SSRによりサーバーサイドでWebページが生成されます。ソースコード（図12）を見ると、サーバーサイドで生成されたWebページの内容を確認できます（ソースコード内にWebページのテキストやルートのIDが含まれることに注目してください）。
Firebaseデプロイの改善
Firebaseのコマンドラインツール（Firebase CLI）に、Angular（などのWebフレームワーク）をデプロイ時に自動検出して処理する機能が、早期プレビューとして実装されました。以下で利用方法を説明していきます。なお、以下の説明では、Firebase CLIはインストール済みで、「firebase login」コマンドでGoogleアカウントにログイン済みであることを想定します。Firebase CLIの詳細は公式ドキュメントも参考にしてください。
まず、「firebase experiments:enable webframeworks」コマンドで早期プレビュー機能を有効にします（このコマンドは1回だけ実行すればよいです）。次に、任意のフォルダー（ここでは「p005-ssr-ssg」と同じパスに作成した「p006-firebase」フォルダー）で「firebase init hosting」コマンドを実行します（図13）。
①でデプロイ先のFirebaseプロジェクト（既存のプロジェクトを使うか新規作成するかを選択可能）、②でデプロイするプロジェクトを指定します。②の「Do you want to use a web framework?」で「y」（Yesの意味）、「What folder would you like to ...」でAngularプロジェクトフォルダー（この場合は「../p005-ssr-ssg」）を指定すると、「Detected an existing Angular codebase...」と表示され、Angularのプロジェクトが自動検出されます。そのほかのオプションはデフォルトを受け入れると、AngularのプロジェクトをFirebaseにデプロイするための設定ファイルが出力されます。
図13のコマンドを実行完了後、「firebase deploy」コマンドで、先ほど指定したAngularプロジェクトがFirebaseにデプロイされます。このとき、プロジェクトに含まれるSSR/SSGがFirebase上で動作するよう、自動的に処理されます。
なお、本機能の利用に当たっては、以下の注意が必要です。
- デプロイ先Firebaseプロジェクトは、従量制プラン（Blaze）の契約が必要です。
- 記事執筆時点では、プロジェクトに含まれるserver.tsで「run();」をコメントアウトする必要があります（コメントアウトしないとFirebaseでSSRが動作しません）。本機能は早期プレビューなので、将来改善される可能性があります。
そのほかの変更・改善点
ここまで説明してきた以外の主な変更・改善点を以下に記述します。
開発プレビュー版から正式版への移行
これまで開発プレビュー版だったSignalや、Vite/esbuild利用のビルドが正式版になりました。
スタンドアロンAPIがデフォルトに
Angular 15で正式版になったスタンドアロンコンポーネントなどが、プロジェクト生成時のデフォルトになりました。
Angular Materialのレガシーコンポーネントが削除
UIライブラリー「Angular Material」のバージョン17では、バージョン15でレガシーとなった古いコンポーネントが削除されました。なお、Angular 18まではAngular Material 16と組み合わせてレガシーコンポーネントが利用できるとされています。
コンポーネントのスタイル指定が簡略化
これまでコンポーネントのスタイル指定（styles、styleUrls）は、リスト12の通り、配列形式で指定してきました。
@Component({
styles: [`
（略：CSSの記述）
`],
styleUrls: ['./styles.css']
})
しかし、Angular 17からはリスト13の通り、配列ではない指定ができるようになりました。このとき「styleUrls」のプロパティ名が「styleUrl」に変更されていることに注意してください（「styles」は変わりません）。
@Component({
styles: `
（略：CSSの記述）
`,
styleUrl: './styles.css'
})
まとめ
本記事では、2023年11月にリリースされたAngular 17の変更点や追加機能を説明しました。Angular独自の記法をよりシンプルに置き換える改善とともに、angular.dev Webページで学習環境を充実させるなど、より多くの開発者がAngularに取り組みやすいよう改善が行われています。
