デザイナーがエンジニアとの連携について考える：FigmaのdaisyUIコンポーネントからインスタンスを切り離してカスタマイズする

こんにちは、UX/UIデザイナーの出口です。
現在daisyUIを取り入れた開発をしています。

daisyUIの導入により、デザイナーはFigma上のdaisyUIコンポーネントのインスタンスを、エンジニアはTailwind CSS向けのdaisyUIライブラリを活用して効率的に開発を進めることができます。

daisyUIのサイト

実際の開発ではインスタンスに要素の追加や変更などカスタマイズが必要になってきます。
デザイナーがカスタマイズする際は、どの程度までならエンジニアの開発に支障ない、または調整を軽減できるのかが課題となります。

特に「インスタンスの入れ替え」プロパティが設定されていないレイヤーに新しい要素を追加したい場合など、デザイナーがdaisyUIのインスタンスをメインコンポーネントから切り離さないと追加ができない場合、切り離しによるエンジニアとの連携や開発への影響が気になるところです。

（画像出典：daisyUI）

インスタンスを切り離すときに起こりやすい問題や影響を把握しておくことで、エンジニアとのコミュニケーションや実装作業がよりスムーズに対応できるようになるのではと思いましたので、調べたことなどまとめてみました。

この記事の中の用語で特に明示しない場合は「メインコンポーネント」、「コンポーネント」はFigma上のdaisyUIのメインコンポーネントのことを差し、「インスタンス」はFigmaの自分の作業スペースにコンポーネントのコピーを生成して配置したものを指します。

※エンジニアへの説明ですが、コンポーネントとインスタンスの関係は、クラスとインスタンスと同じでオブジェクト思考的な関係です。コンポーネントの変更はインスタンスに反映されます。

「クラス名」、「クラス」はエンジニア側のTailwind CSSのクラス名のことを指します。

daisyUI以外のUIコンポーネントライブラリとも共通と思われる部分もありますので、共通かどうかは記載したいと思います。

daisyUI以外のUIコンポーネントライブラリに詳しいわけではありませんが、daisyUIの特徴は、エンジニアが実装で使用するTailwind CSSのクラス名やCSS変数と、デザイナーがFigma上のdaisyUIコンポーネントで使うコンポーネント名・プロパティの名称や値が対応している点にあります。その点に焦点をあてて、違いについてどこまで共通で、どこからがdaisyUI独自のものなのかを記載出来ればと思います。

同期がとれなくなる

メインコンポーネントに直接変更を入れることは基本的にないと思いますが、切り離したインスタンスには変更が反映されなくなります。

これはdaisyUIコンポーネントでなくても共通の問題です。

メインコンポーネントを変更せずに開発を進めるなら、気にする必要はありません。

消えてしまうプロパティの再設定

切り離すと、メインコンポーネントで設定されていたプロパティは消えてしまいます。

切り離しによるプロパティの消失はdaisyUIコンポーネントでなくても共通です。

daisyUIの場合は、サイズや色を定義している「バリアント」などのプロパティの値が、daisyUIライブラリのドキュメント上のタイプ名やTailwind CSSのクラス名と対応しているので、切り離し後も引き継ぎたいプロパティがある場合は、元のコンポーネントと同じプロパティ名で値も同じにして設定しなおす必要があります。

右のパネルにプロパティを設定する場所がある（画像出典：daisyUI）

レイヤー構造を把握しやすくしておく

切り離して新しい要素を入れることで、コンポーネント内部のレイヤー構造が複雑化する可能性があります。

要素を追加していくことでレイヤーが複雑化してしまうのは、daisyUIでなくても共通ですね。。。

元々のインスタンスと共通する部分のレイヤー構造は元の構造やレイヤー名をなるべくそのまま利用して、daisyUIの場合は新しく追加した要素のレイヤー名は、可能であればdaisyUIのクラス名を含めるとエンジニアがHTML構造を理解しやすくなります。

カードのコンテンツを内容として持つレイヤー　→　card-body
カードのタイトルを内容として持つレイヤー　→　card-title

daisyUIのドキュメントで見たCardコンポーネント

daisyUIではレイヤー構造を示すクラス名は部分的で数も少ないので、大体はレイヤー名をつけなくても問題ない場合が多いです。エンジニアには申し訳ないことを言うと、構造を理解しやすくなるという程度なので、なかったら理解できなくなるというわけではないため、daisyUIのクラス名を必ず含めなくてはいけないということもありません。対応するクラス名があるならつけるといいよくらいの感じです。

実際、FigmaのdaisyUIのコンポーネントで用意されたレイヤー名が全て対応しているかというと、一部対応しておらず異なる名前がつけられていたりします。Cardコンポーネントのcard-bodyはFigmaでは「Container」となっています。

Figma上で見たdaisyUIのCardコンポーネント（画像出典：daisyUI）

コンポーネントの命名には元のコンポーネント名を含める

切り離した元インスタンスに要素を追加したあと、再度コンポーネント化するときは元のインスタンス名（コンポーネント名）と異なる名前をつけたりしますが、daisyUIのTailwind CSSではクラス名に対応していて意味があるため、Figma上で分かりづらい命名をするとエンジニアが実装時に対応するクラス名がわかりづらくなる可能性があります。

名前をつけるときは、daisyUIのクラス名（元のコンポーネント名）を含めると、エンジニアが対応するクラスがわかりやすくなります。「custom-」などのプレフィックス（接頭辞）をコンポート名につけて、カスタマイズ要素があることをわかりやすくします。

Card　→　custom-Card　または　ctm-Card

daisyUIに限らず、ベースとなっているコンポーネントはどのコンポーネントだったのかがわかりやすくなると思うので、元のコンポーネント名を含めるのは良いと思います。

オリジナルな独自コンポーネントの場合は「original-」などのプレフィックス（接頭辞）をコンポート名につけてdaisyUIやカスタマイズしたインスタンスと見分けやすくします。

original-Movie　または　og-Movie

名前のつけ方については一例なので、命名規則はプロジェクト毎にルールを決めておくといいと思います。

インスタンス内にはもともと使う予定のないプロパティやレイヤーも含まれていると思いますが、切り離したあと使わないプロパティやレイヤーは消してしまっても大丈夫なものもあります。

daisyUIコンポーネント以外のUIコンポーネントライブラリでは、削除によってエンジニアの作業に支障が出るものもあるかもしれませんので、各UIコンポーネントライブラリ毎に確認が必要だと思います。

プロパティの場合

daisyUIでは、Figmaのプロパティの「ブール値」はFigmaのレイヤーの表示・非表示を操作できるプロパティで、エンジニア側のTailwind CSSでも表示・非表示を操作するクラスhiddenはあるものの、例えば「ステータスによって表示・非表示の切り替え」を予定していないような、ずっと表示または非表示のままのレイヤーなのであれば、ブール値は設定しなくても問題ありません。プロパティはインスタンスの切り離しを行うと消えてしまうので、使わないのに再設定しなくてはならない手間が省けるということです。

daisyUIでは、Figmaのプロパティの「テキスト」も、配置したテキストボックスに対してテキストの入力が出来るプロパティですが、エンジニア側ではテキストを直接配置するだけでテキストを入力出来るクラスがあるわけではないので、テキストが固定なのであれば設定しなくても問題ありません。

その他、クラスで使用されているプロパティかどうかはdaisyUIのドキュメントで確認できます。

レイヤーの場合

daisyUIでは、プロパティと同じく実装時にHTMLタグを削除するだけなので、将来的にも使う予定が無いのであれば削除しても問題ありません。

「Noise（ノイズ効果）」や「Depth（深度効果）」のようなTailwindのCSS変数と対応しているレイヤーもありますが、これらもエンジニア側で記述しなければ表示されないので削除しても問題ありません。

ただ、レイヤーの非表示にはブール値で非表示にしたりレイヤーを直接非表示にする以外に、バリアブルモードでレイヤーを非表示に出来るレイヤーもあります。「Noise（ノイズ効果）」や「Depth（深度効果）」もバリアブルモードで非表示に出来るレイヤーです。バリアブルモードを使って表示を消した場合は、レイヤーや外見セクションに消したとわかるよう表示されるので、表示をしておきたい意図があるならレイヤーを物理的に削除せずにバリアブルモードによる非表示をしたほうが良さそうです。

Buttonコンポーネントのバリアブルモードによる非表示

daisyUI以外のUIコンポーネントライブラリでも、バリアブルモードによる表示の変化はあると思います。

前述で、「レイヤー構造を把握しやすくするためにdaisyUIの対応するクラス名を含めると良いが必須ではない」と書いていますが、基本的にはプロジェクト毎にエンジニアと要相談だと思います。

私のプロジェクトでは「切り離し後も引き継ぎたいプロパティがある場合は、元のコンポーネントと同じプロパティ名で値も同じにして再設定する」だけがエンジニアとの相談の上必須となりました。エンジニアとの間で必須とまでルール化しなかったものに関しては、ルール化しなかっただけでデザイナー側が判断して取り組んでいたりします。

daisyUIが、エンジニアが実装で使用するTailwind CSSのクラス名やCSS変数と、デザイナーがFigma上のdaisyUIコンポーネントで使うコンポーネント名・プロパティの名称や値が対応しているという特徴を持つ以上は、カスタムした後もコンポーネント名やプロパティ名などをカスタム前の元々のコンポーネントが持つ名前を引き継ぐ必要はありそうです。

当初デザイナー側でFigmaのインスタンスを切り離さずになんとかデザインしていたのですが、daisyUIコンポーネントで効率的に開発を進められるはずがかえって作業を困難にしていたため、「インスタンスを切り離したい」「ついでに切り離したインスタンス内の不要なレイヤーやプロパティは削除したい」となったので、エンジニア側への連携で何か困ることが出ないか調べた次第です。調べた範囲をまとめると以下4点です。

• 切り離しによって同期が失われることを理解しておく
• メインコンポーネントのプロパティとの整合を保つため、必要なバリアントは再設定しておく
• レイヤー名や構造、コンポーネント名の命名を、なるべくdaisyUIやTailwindと対応づける
• 使わないプロパティやレイヤーは削除して問題ない

たぶん切り離しはダメなんじゃないかとか、切り離しによって何か影響でているんじゃないかとか、デザイナーとエンジニア双方で漠然とした不安があったので、実際にどうなのかを調べたことで影響を把握できるようになり、安心して開発を進められるようになったと思います。

daisyUIのインスタンス切り離しによるカスタマイズを検討されている方の参考になればと思います。