カスタムコンポーネントを実装してみて思ったこと

この記事を書いているひと

CrowdWorks.jp デザイン基盤チームでデザイナーをやらせていただいている id:ksmxxxxxx です。

普段は CrowdWorks.jp のデザインシステム構築における、UI デザインと Vue コンポーネント作成をメインに活動しています。

今回は「デザインに軸足を置きながら、Vue コンポーネントを作っているデザイナーがデザインとフロントエンドの狭間で右脳と左脳を殴り合わせながらカスタムコンポーネントを実装した」ポエムをお送りします。
あくまで個人の感想であり他にも解釈はありますが、ひとりのデザイナーの中でデザインする自分とコーディングする自分が河原で殴り合ったポエムなので気軽に読んでいただけたら幸いです。

何もわかっていなかったカスタムコンポーネント

ここ 1 年くらいデザインシステムを構築するチームで、UI デザインの作成 →Vue コンポーネントへ実装という仕事をしていました。
私のコーディングスキルは初学者でもまだまだ尻にカラがついている程度のもの…...という自覚があります。実装もやっていても軸足はデザインなので、能力比率としては デザイン 8 : エンジニアリング 2 くらいの割合です。

そんな私がカスタムコンポーネントなるものを実装することになりました。
以前から「やってみたい」と息巻いていたこともあって「やっと手がつけられる〜」なんて呑気に構えていたころが、今では懐かしいです。
2 ヶ月前の自分に言いたい。「そんな呑気にしてられるの、今のうちだぞ」と。
それくらいはじめてのカスタムコンポーネント実装は私にとって学びの多い機会でした。

カスタムコンポーネントとは

自分でカスタムコンポーネントについてわかりやすく説明を書く自信がなかったので ChatGPT くんに説明してもらいました。

カスタムコンポーネントについて説明してください。なるべく専門ではない人にもわかりやすい言葉を使ってください。

カスタムコンポーネントとは、ソフトウェアやウェブ開発などで使われる「自分で作った部品」のことを指します。たとえば、アプリやウェブサイトには、ボタンやフォーム、メニューなどの小さなパーツがありますよね。これらは「コンポーネント」と呼ばれます。

「カスタムコンポーネント」というのは、既存のパーツを使うのではなく、自分のアプリやウェブサイトに合わせて、新しく作った特別なパーツのことです。

たとえば、標準のボタンではシンプルすぎる場合、自分のブランドに合ったデザインや機能を追加したボタンを作りたいとします。このように、特定のデザインや動き、機能を持たせた独自のパーツを作ることが「カスタムコンポーネント」です。

技術的には、これを行うには HTML や CSS、JavaScript といったウェブ技術を使ったり、React や Vue といったフレームワークでコンポーネントを作成することが一般的です。

簡単にまとめると：

コンポーネント = アプリやウェブの「部品」

カスタムコンポーネント = 自分のニーズに合わせて特別に作った部品

これにより、デザインを統一し、再利用可能なパーツを作ることで、開発が効率的になり、ユーザーにも使いやすいインターフェースを提供できます。

ふむ…わかるような、わからないような。

図説するとこういうやつです。

画像の左がネイティブな HTML で実装されたドロップダウンな UI です。こちらは select要素でマークアップされ、スタイルはブラウザのデフォルトスタイルに依存します。クリック前のボタン状態は CSS でスタイルをあてることができますが、ボタン押下状態のリストは CSS でスタイルを上書きできません。

画像の右がカスタムコンポーネントで実装されたドロップダウンな UI です。カスタムコンポーネントでは ul要素とbutton要素でマークアップされています。button の部分をクリックするとメニュー部分が開きます。カスタムコンポーネントではこのメニューの部分はul 要素でマークアップされており、CSS で自由にスタイルを当てることができます。

スタイリングの自由度だけ見ると「良いじゃんカスタムコンポーネント」って感じるところ。ブラウザのデフォルトに依存していないので、一貫したスタイリングが提供できるのは、デザイナー目線でみるととても素敵なものに見えます。

だがしかし…...ネイティブな HTML である select 要素と同じ操作ができるようにするためにはひと手間を加える必要があります。

JavaScript で〝ボタンが押された時メニューを開く〟、〝n 番目のメニューがフォーカスされている時 ↑ キーを押したら次にどこをフォーカスされる〟みたいな実装をする必要があります。ネイティブな HTML で実装すればそんなコードを書く必要はありません。

つまり…めちゃくちゃめんどくさいッ（心の叫び）

改めて考えてみるメリットとデメリット

メリット
- スタイリングを自由に変えられるのでネイティブな HTML ではできないデザインの実装が可能になる
- ネイティブな HTML では用意されていないような新しい UI を開発できる
デメリット
- スタイリングや UI が既存に縛られない自由を得られる反面、JavaScript 側で DOM の操作を制御する実装が必要になってくる
  - フォーカス時に選択している DOM を指定したり…
  - 現在フォーカスしている要素からキーボードの矢印キーを押した時、次はどこに行くのかを丁寧に書いてあげないといけなかったり…...
  - とにかく「ネイティブな HTML だったらこんなことしなくていいのに」っていうことをいちいち JavaScript で懇切丁寧にやってあげないと、使える UI にならない
- 実装が大変な割に、それがユーザーに受け入れられるのかは「出たとこ勝負」になるので…...ぶっちゃけコスパが良くない
- 上記の技術的な事情を知らないノーコードなデザイナーのほうが多そうで、その場合はデザイナーとエンジニアの共同作業でのコミュニケーションコストも膨らむ。やっぱコスパわるくね？

…...頑張ってメリットも書き出そうという努力はしたけど、小一時間考えても出てきませんでした。努力はしましたよ？？？

結局ネイティブな HTML が一番つよいのでは

自分が実装したのは select 要素をカスタムコンポーネントにしたドロップダウンメニューでした。
最初は「ほかの UI にスタイリングを寄せたいし、ほかにも入ってくるメニューの数も制限を設けたい（47 都道府県の名前がズラッと出たときに沖縄県を選択する必要がある時の絶望感ハンパねぇ）」など、理由はそれなりにあったので、やってみました。

結論「やめときゃよかった…...」みたいな気持ちになるわけです。

いや、やってよかったと今は思っています。やらなければわからないままだったことも多いです。ただそれは己の知見を得られた部分に限った話です。

ネイティブな HTML の select みたいにキーボードの矢印上下で選択できるようにしたかったです。が、それをやろうとすると自分のスキル不足も多大にありますが…...DOM 操作する JavaScript 書くことについていろいろな面において「割に合わない」と感じてしまいました。

ネイティブな HTML だったらこんなめんどくさいことしなくてもキーボード操作できるようになっているのに、ルックアンドフィールを合わせるためにめんどくさいことを懇切丁寧にコードで指示してあげないと、キーボード操作できません。

見た目を整えることはデザインで大事な部分です。一方で整えるだけではなく「機能的である」ことが求められる Web アプリケーションの UI としてはキーボード操作もセットで対応が不可欠です。

そんなことを考えると「つまりネイティブな HTML で実装しておいたほうがコスパ良いし、アクセシブルでもあるから一番つよいのでは」というところに着地します。

🍙

大前提に、自分の練度不足が大きいです。
しかし、デザイナーが「デフォルトのスタイルはイモっぽいから今どきのスタイルにしようぜ」と言ってイケてるデザインにしたところで、キーボードで選択・操作できない UI は使いづらいです。
あと…...個人的な嗜好の話になりますが、自分がキーボードからなるべく手を離したくない民というのもあります。
そんな陥りがちな罠に気づけたことは、自分にとって良い学びだったなと思いました　まる

最後に。
ここまで書いていると「こいつカスタムコンポーネント絶許なのか、アレルギーか」と思われるかもしれませんが、自分としてはそこまで思っていません。
これに懲りず、本当に必要であればカスタムコンポーネントを選択するのは全然ありだと考えているので、またやっていきたいですね。