Atomic Design+SPA=Atomic Components
ここで、コンポーネントの粒度について少し紹介したいと思います。
この2～3年でAtomic Designが認知され導入事例も出てきておりますが、「ワイヤーフレームを持つTemplates」「実際のテキストや画像が入るPages」という概念がSPA（シングルページアプリケーション）では馴染みにくいと考え、Atomic Designから派生しSPA向けに最適化されたAtomic Componentsを参考にして設計を進めました。
私たちは以下のような構成でコンポーネントを分類しています。
Atoms
これ以上分解不可能なUIの最小単位。また、これ以上分解することはない粒度のUIもAtomsに配置しています。
- 例：Avatar、Button、Checkbox、Input Field、Tooltip、etc……
Molecules
Atomsに属するコンポーネントを繰り返し配置したもの、もしくは複数のAtomsコンポーネントを配置してグループ化したもの。内部で状態を持つことはありません。
- 例：Dropdown、Nav、Pagination、etc……
Organisms
Moleculesに属するコンポーネントを複数並べたもの、もしくはOrganismsの中で別のOrganismsを呼び出す必要があるもの。内部で状態を持ち、状態はOrganismsの中だけで完結するものであり、他のOrganismsや上位のEcosystemに干渉を受けることはありません。
- 例：Popover、Tabs、RichtextEditor、ImageCrop、etc……
Ecosystem
Atomic DesignではTemplatesに相当するレイヤー。ReactでいうContainer Component的な立ち位置のコンポーネントで、状態管理が求められるレイヤー。Organisms、Molecules、Atoms Componentを用いてEcosystem Componentを実装していきます。
Environments
ページ全体を指すもので、Atomic DesignではPagesに相当するレイヤー。SPAであればEnvironmentsは基本的には1つだけとなります。また、ページ全体で持たせたい状態（例えば、サイドバーの開閉状態）は、Environmentsレイヤーで持っています。
HRMOS採用管理では原則として、Organismsまでの粒度のコンポーネントはUI Componentライブラリ側で持たせ、Ecosystemsに関してはいわゆるContainer Componentとして各Angularアプリケーション側で実装するアプローチを採っています。
複雑なComponentの実装には、Angularの公式ライブラリを活用する
開発当初は多数のサードパーティAngularライブラリを入れてトライ＆エラーを繰り返しましたが、現在ではほぼAngular teamが開発しているAngular Material & Angular Component Development Kit（CDK）をベースに、HRMOSオリジナルのスタイルを反映しています。
Angular CDKは、カスタムUIコンポーネントを作るための根幹となるものです。一言で言えば、UIライブラリを作るためのライブラリと言えます。
例えばOverlayというコンポーネントは、画面上に別のコンポーネントを重ねて表示するために必要な機能がCDK側で実装・提供されているため、ModalやPopoverといった類のコンポーネントでは、「表示／非表示の制御」と「HRMOSのデザインレギュレーションに沿ったスタイリング」を実装するだけで済むようなるため、開発工数の短縮ができます。
年に2回あるAngularのメジャーバージョンアップになるだけ早く追従していきたいこと、各コンポーネント単位でユニットテストが記述されており高い品質が担保されていることも、Angular Material／CDKを採用した理由となりました。
リリース作業にかかる負担を減らしながら、頻繁にリリースできる仕組み
開発中のUI Componentsライブラリを実際のAngularアプリケーションに導入すると、コンポーネントに持たせるパラメーター（@Input アノテーション。Reactでいうpropsに相当するもの）が足りず、想定していたインタラクションが実装できなかったり、実装が不完全で不具合になることがありました。
ある意味UIコンポーネントを分離したがゆえの弊害ではありますが、この問題を逆手に捉え、頻繁にリリースできる仕組みを作ることにしました（リリースするとはいってもgit tagでバージョン番号のタグをセットし、npm publishするだけです）。
UI Componentsライブラリをnpm publishした後は、Angularアプリケーション側のpackage.jsonに新しいバージョン番号をセットしてnpm installすることで、最新のコンポーネントが利用できる流れになっています。
頻繁にリリースが行われると、Angularアプリケーション側の開発を行うエンジニアはCHANGELOG（変更履歴）を見たくなるのは当然のことでしょう。とはいえCHANGELOG.mdファイルを毎回記述するのも面倒なものです。この負荷をなるべく軽減したい想いがあったため、standard-versionを導入しました。
standard-versionは、gitのcommit logを元に、CHANGELOG.md（変更履歴）の自動生成と、次のバージョン番号を自動的に付けてくれるツールです。git commit時にCommit Message Guidelineに準拠したコミットメッセージを記述する必要がありますが、リリースの際にドキュメントを作る手間が省けるメリットの方が大きいことから、導入を決めました。
