本セッションの登壇者
セッション動画
「これからのアプリケーション設計トレンド in Angular」ということで発表させていただきます。
私は AngularのGoogle Developer Expert をしております、@lacolacoといいます。Angular日本ユーザー会 の代表などもしており、ユーザー会では最近 discord をはじめました。Classiという会社で働いています。
今日お話するのは、AngularのStandalone-based appと、これからのAngularについてです。今日持ち帰っていただきたいのは、(他のセッションでも)Hydrationなどのお話がありましたが、Angularも基本的に同じ土俵、同じ戦場にいるということです。
Standalone Componentsとは
まずStandalone componentsですが、これはAngularのコンポーネント定義の新しいフォーマットです。これまでコンポーネント定義はやや複雑でしたが、Standalone componentsでは単純化されています。たとえば下記のような10行の1ファイルでコンポーネント定義が完了します。この例ではメッセージを受け取って、そのメッセージを表示するMessageComponentを定義しています。
このコンポーネントは静的にインポートし、テンプレートの中でHTMLタグとして使うことができます。
Standalone Componentsのメリット
Standalone componentsの良いところは、遅延読み込みが簡単にできるというところです。コンポーネントのインポートをDynamic importを使った読み込みに変更し、それを動的に差し込むという処理にすることで、コード分割が自動的に行われます。たとえばダイアログのような最初は不要だが必要になったタイミングでファイルを読み込みたいようなコンポーネントがあるときも、コンポーネント単位でファイルを分割することで、Bundleを分割しやすくなります。
このようなアプリケーション内での遅延読み込みもStandalone componentsのメリットですが、これに加えてコンポーネントのポータビリティが改善されることによるメリットを2つ紹介したいと思います。1つ目がAngular Elements(Web Componentsに連携する機能)で使いやすいという点と、2つ目がAstroなどAngularの外でコンポーネントを使えるようになるという点です。
1つ目の Angular Elements はAngularコンポーネントをCustom Elements(カスタムタグ)に変換する機能です。これを使うと、一度コンポーネントをカスタムタグとしてブラウザに登録してしまえば、あとはAngularのアプリの外でもどこでも使えるタグになるので、既存のWebアプリ/WebページでAngularのコンポーネントを簡単に表示できるようになります。
2つ目のAngular外でのコンポーネントの使用例についてお話します。Astroは先ほどFurukawaさんの発表にも出てきたフレームワークですが、Astro Angular を使うとAstro内のHTMLに自然にAngularのコンポーネントを埋め込めるようになっています。これもStandalone componentsならではのポータビリティです。
これからのAngular
今後のAngularのエコシステム全体は、Standalone componentsにどんどん傾倒していくはずです。エコシステム的には基本的にまだOptionalでOpt-inで使うものなのですが、今後のフレームワークの改善がStandalone前提になったり、周辺のライブラリやツールがStandaloneであれば便利になるような機能がどんどん増えていったり、Standaloneを前提にした学習コンテンツが増えていったりするはずです。今後のメインストリームはStandalone componentsをベースにしたAngularアプリになるでしょう。
ということは、アプリケーションを自分たちで作るときもStandaloneベースで考えていく必要があります。ただし、普通のSPAではStandalone componentsベースで作るモチベーションはそんなに多くありません。Standaloneになって単純化することで、少しボイラープレートが減るとか、先ほどご紹介したようなコンポーネント単位のコード分割/遅延読み込みがしやすくなるといったメリットはありますが、せいぜいその程度です。
Standaloneベースで作るモチベーションとして他に紹介したいのは、下記の4つです。
- コンポーネントの外部利用 (SSG; Static Site Generation)
- Micro Frontends
- Islands Architecture
- Resumable SSR
1つ目のコンポーネントの外部利用については、先ほどのAngular ElementsやAstro Angularのように、コンポーネントをCustom elementなどに変換してAngularの外で使えるようにできるというメリットです(2つ目のMicro Frontendsについては今回は割愛します)。
3つ目のIslands Architectureについては次のりぃさんの発表で話されるはずなのであまり話しませんが、ひとことでいうと「Root componentを持たないSSR」だと思います。AngularのコンポーネントがStandaloneになることで、1アプリまるごとではなく1コンポーネントごとにSSRできるようになります。ということでAngularでもIslands Architectureができるようになったというのが最近のアップデートです。
4つ目のResumable SSRは、これは先ほどのFurukawaさんの発表で出た Qwik に関連していて、Hydrationをしないというアーキテクチャです。SSRされたアプリケーションをbootstrapしないことでパフォーマンスがかなり改善します。これを現状実装しているフレームワークの中ではQwikが有名です。Qwikはbuilder.ioが提供していますが、ng-conf 19のKeynoteでTech LeadとしてResumable SSRについて語っていたMisko HaveryがCTOを務める会社で、彼がResumable SSRを実現するフレームワークを作りにいったという感じがします。Angularでは現状Resumable SSRを実現することはできないのですが、QwikがAngularコンポーネントをサポートするのが先か、AngularがResumable SSRを独自にサポートするのが先か(ロードマップには含まれています)、どちらかは神のみぞ知るところです。
まとめ - Standalone-first化は不可避
Angularアプリケーションを作っていく上で、Standalone化は不可避で、Standalone componentsに徐々に寄せていくことになるでしょう。現時点でも、ボイラープレートの削減やコード分割/パフォーマンスチューニングがしやすくなる、コンポーネントを外部利用できるというメリットがあります。また、将来のいろんな可能性のためにStandalone化しておくとお得かもしれません。より複雑なアーキテクチャやより厳しいパフォーマンス要求に対応するために、またMicro Frontends / Islands Architecture / Resumable SSRに適用するためにStandalone化していることが今後求められていくでしょう。
以上、ありがとうございました。
