はじめに
Angularコーディングスタイルガイドは、Angularの構文、慣習、およびアプリケーション構造に関するガイドとして多くのエンジニアから長年参考にされてきました。
そんな中2024年10月末、AngularチームのテックリードであるJeremy Elbourn氏によって、スタイルガイド更新版ドラフトのRFCがアナウンスされました。
今のスタイルガイドはAngularのv2.0.0がリリースされた2016年に書かれたもので8年もの年月が経過しており、その間にあった様々な変化を反映する必要があったようです。
この記事では、まずスタイルガイド更新の狙いや主な変更点についてのJeremy氏の説明文を日本語で要約していき、このRFCの概要をお伝えします。
次に、コメント欄からAngularエンジニアの反応をいくつかピックアップしてみたいと思います。RFCにコメントするほどのエンジニアなのでやはりAngular自体に詳しく、どの意見も非常に勉強になるものでした。
- この記事は2024/11/17時点の情報に基づいています。まだRFCプロセスの途中であるため、変更される可能性があることに注意してください
- 日本語での抜粋は筆者が独自に行なっているものであり、正確性を完全に保証できるものではありません。必ず原文も合わせて参照してください
RFCの概要
スタイルガイド更新の主な目的
- スタイルガイドの短縮（今のガイドは紙に印刷すると52(!)ページにもなるとのこと）
- 煩雑または定型的なガイダンスの簡素化
- Angularに直接関係しないガイダンスの大部分の削除
- Angularの一般的なベストプラクティスではなく、"スタイル"の選択に関するガイドへのフォーカス
- フレームワークの新機能やAPIに対応したガイダンスの最新化
- 実際のAngular開発の観察に基づく以前の推奨事項の更新
スタイルガイドの主な変更点
一般的なコード品質ガイダンスの削除
Angularとは直接関係のない一般的なコーディングベストプラクティス（例:「ファイルの行数を400行に制限」「関数は75行以内に」など）を削除。これらを解説する書籍や動画は世の中にたくさん存在するため、更新版のスタイルガイドはAngular特有のプラクティスに集中。
Angularのベストプラクティスを適切なドキュメントに移動
スタイルガイドの目的を「コーディングスタイル」に絞り、ベストプラクティスの多くは関連するドキュメントに移動。例えば、コンポーネントセレクタに関するアドバイスはセレクタ専用のドキュメントに記載。
ファイル名やクラス名のサフィックス推奨を廃止
「.component.ts（クラス名は~Component）」「.service（クラス名は~Service）」などの命名規則を廃止。クラス名はその振る舞いや責任を表すべきで、「UserService」より「UserDataClient」の方が明確。ただし、NgModuleやPipeは例外。
NgModuleに関するほとんどのガイダンスの削除
NgModule関連の推奨事項を削除。代わりに、スタンドアロンコンポーネントやprovidedIn: 'root'を推奨。従来のガイドラインはアーカイブとして参照可能。
テンプレートの分離に関する推奨の削除
テンプレートが3行を超えた場合に別ファイルへ分離する推奨を撤回。インラインと分離ファイルの両方が受け入れられる。
@HostBindingと@HostListenerの推奨を撤回
@Component、@Directiveのhostプロパティの使用を推奨。新しいSignalベースのAPIとの整合性や、CSSクラスやARIA属性を一括管理できる利点を考慮。
イベントハンドラ名の「on」プレフィックス廃止
onClickのような命名を推奨していたが、メソッドが実際に何をするかを表す名前を推奨する方針に転換。
FAQ
なぜスタイルガイドを変更するのか？
- Angularが進化：NgModuleからスタンドアロンコンポーネントへの移行や新しいシンタックスの導入など、Angular自体が大きく変わったため
- 8年分の学び：スタイルガイド作成当初に比べ、多くのコードを見て改善すべき点が明確になった
- Web開発の変化：2016年当時の考え方が変わり、単一ファイルコンポーネントのような新しいスタイルが一般的になった
従来の方法が好きな場合は？
従来のガイドラインを使い続けても問題なし。アーカイブ版も引き続き利用可能。
コミュニティツール（例: angular-eslint）は新ガイドラインに対応するか？
公式化に合わせてツール開発者と連携し、対応を進める予定。
新しいスタイルガイドはバージョン19に含まれる？
No。バージョン19では間に合わず、後のバージョンで適用予定。
なぜ新しいスタイルガイドでSignalsを推奨する記載が無いのか？
一部APIがまだ開発者プレビュー段階で、FormやRouterなどが対応中。成熟に伴い、ガイドを随時更新予定。
ng newで生成されるコードは更新される？
スタイルガイドの更新に伴い、生成コードも更新する予定。
新ガイドラインに従うコードへのリファクタリングツールは提供される？
可能な場合はオプトイン方式のスキーマを提供予定。ただし、ng updateで自動実行はされない。
Angularエンジニアの反応
以下に、コメントセクションから独断と偏見で代表的なものを抜粋していきます。
スタイルガイド更新への賛成
確かにこのガイドは8年前のものであり、とっくに期限切れだと思う。更新はありがたい
サフィックス削除への賛成
確かにサフィックスを全てにつけるのは意味が無い。
サフィックス削除への反対
サフィックスはLintルールを調整する際に重要。特定のファイルタイプに適用すべきでないLintルールを除外するのに役立つため、サフィックスがないと除外設定が難しくなる。
一般的なベストプラクティス削除への反対
このドキュメントに含めるべきでないかもしれないが、Angularの公式見解を引用できるのは非常に助かる。
特にチーム内で説得力を持たせる際、「以前の職場ではこうだった」や「Xフレームワークでは必要なかった」という反論に対抗しやすくなる。
一般的なベストプラクティスであっても、広く認められた基準として示せるのは有用。
ライフサイクルフックの解説を希望
やりたいことに応じて、どのフックを使うべきかを説明すると良いかも。
よく見かけるのは、ngOnInitを使っているけれど、同じ処理をコンストラクタやクラスフィールドで済ませられるケース。同様に、ngAfterViewInitの代わりにafterNextRenderやafterRenderを使うべき場合もあります。
また、シグナルが安定したら非推奨になる可能性が高いフック（例: ngOnChangesなど）は避けるべきだという指針もあると良い。
他のトピックの提案
- アプリケーションの構造化
- アプリをどう構造化するか、フォルダ（例: components, models, services, pagesなど）の作り方や配置場所について、SPA全般に役立つ指針を提供
- サービスとAPI呼び出しの構造化
- 例えば、"Api"サービスを作成し、それを他の"ビジネス"サービスが利用する方法と、各サービスが個別にリクエストパスを持つ方法のどちらが良いか、DTOモデルをリポジトリ内でどう整理するかといったアイデア
Angularに特化した内容ではないかもしれないが、こうした指針があると非常に価値がある。
まとめ
以上、スタイルガイド更新RFCの概要とAngularエンジニアの反応をまとめました。
記事に載せた反応はほんの一部で、GithubのDiscussionコメント欄にはもっとたくさんのコメントが付いています。
特に、サフィックスの削除についてはかなり賛否両論分かれており、最終的にどうなるのか非常に気になるところです。
議論コメントには、Angularエンジニアの"命名"に関する様々な考え方が飛び交っており、読むだけでとても勉強になりました。
また、周辺ツールがサフィックスの存在を前提にしているものもあり、削除すると問題が出そうだという指摘も多数されており、このあたりで初めて知った知識もたくさんありました。
Angularを使っているエンジニアの方はぜひ一度RFCの内容とコメント欄をチェックしてみてはいかがでしょうか。
最後に改めて、この記事は11/17時点の情報(RFCプロセス進行中)を基にしており、スタイルガイドの正式更新版は違った形になる可能性があることにご留意ください。