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に取り組みやすいよう改善が行われています。