最近DesignSystemを作る機会が増えています。
以前だったら0ベースで作るかUIライブラリーをカスタマイズして作るようなことをしましたのが、最近は新しい選択肢も出てきたので本記事で紹介します。
Headless UIとは
HedlessUIとは、Styleがあたっておらず、Componentsのロジック部分のみを責務としたUser Interfaceを指します。
同名ライブラリもありますが、これは設計方針がHeadless UIで作られてるだけのもので少し紛らわしいですね。（本記事では「Headless UI」は設計の方を指して使います）
実は私もHeadless UIという設計方針はこのライブラリを通じて知りました知りました。
Headless UIの魅力
下記のようなメリットを感じています。
- ロジックと見た目の分離
- メンテナンスコストの低さ
- 拡張のしやすさ
先程ご紹介したようにHeadless UIはStyleが無いため、見た目の適応のしやすさはピカイチです。
ロジック部分がHeadless UIの責務になるため、感覚としてはHTMLタグがもっと機能拡充されたようなComponentが提供されてるような感じです。
Headless UIをベースにComponentsを作る場合は機能拡充もできるので本当に必要なものを最低限提供されてる感じがありまして、把握しておく仕様が少なく使いやすいです。
Headless UIのようなものは仕様が変わりにくいため、バージョンアップに追従するコストも少なく済むのに好感を持っています。
また移植系の案件の場合CSS-in-JS,だったりstyled-componentなど既存のStyle適応方法でそのまま使えるのも魅力です。
Libraryの紹介
Headless UIの設計をベースに作られたLibraryの開発も盛んです。
私が興味を持っているComponentsLibraryをいくつかご紹介します。
イチオシはRadix UIです
Zag – Rapidly build UI components without sweating over the logic. – Zag
refine | Build your React-based CRUD applications, without constraints! | refine
Ariakit – Toolkit for building accessible UIs
他にもGitHubでまとめられているリポジトリがあります。
デザインシステムとの親和性
デザインシステムを自分で作ろうとした場合ルールや設計はそのプロダクトの文化の影響があるのでフレームワークのようなものでは、どこかで限界が出てきます。
Hedless UI Components Libraryのようなものを使えば、自由に作れるのでデザイナーの設計意図を反映點せやすいです。
またHedless UI ではComponents毎の依存関係がないため、複数のOSS Libraryも導入可能です。
例えば、Modalだけは○○のHeadless UI Componentsを使い、Buttonは□□のHedless UI Componentsを使うなどです。
最期に
HeadlessUIのような設計はデザインシステムの需要が高まった背景から出てきた設計と思っています。
新しめの設計と感じて敬遠せず、デザインシステムに関わる方ならHeadless UI Components Libraryも一度触ってみるのをおすすめします。