hiz

UX designer, developer in Japan.

HomeWorksBlog

kintone UI Component × React

kintone プラグインの UI を構築するにあたり、その実装方法を検討した。 やはり kintone 内で使用されるという都合上、独自の UI を設計するのではなく極力 kintone ライクな UI としたい。

それを容易に実装する為の方法が、公式よりいくつか提供されている。

ひとつは 51-modern-default というスタイルシートで、これを読み込みコンポーネントに応じてクラスを設定する事で、kintone ライクな UI が構築可能となる。シンプルに CSS だけで見た目を整えるアプローチとなる為、使用しているフレームワークなどを無関係で活用が可能。しかし CSS のみという都合上、対応するコンポーネントの幅は狭く、ダイアログやタブなどの JS を伴うものの多くは未対応となっている。またアクセシビリティの観点でも今一歩といった印象。たとえばボタンコンポーネントが提供されているが、キーボード操作でフォーカスを当てた際にそれがスタイルに反映されなず、どこにもフォーカスが当たっていないように見える。

もう一つ、kintone UI Component が提供されている。こちらは JS による UI コンポーネント集で、提供 UI が充実しているのはもちろん、いくつか試したところアクセシビリティも力が入っている様子。

ただ、過去の v0 系では素の JS 版に加え React コンポーネント版が提供されていたが、現行の v1 からは React コンポーネント版はオミットされている。単純な UI で簡潔するのであればこの JS 版で十分なのだが、複雑な UI を構築するのであればやはり React で構築することが保守性や (所属先における) 属人性低減の観点からも望ましい。しかし v0 系はセキュリティ対応を含め開発が終了しているとのことなので、採用は厳しい。

最終的に、kintone UI Component の v1 を React でラップする方法を採用する事とした。kintone UI Component は lit を介した Web component で実装されており、@lit/react を挟むことで簡単に React コンポーネント化する事ができる。当初は @lit/react を使用せずに公式のディスカッションにある方法を試みたが、TS の型を付けるのが面倒で断念した。@lit/react は少し工夫が必要な部分もあるが、大部分に型を付ける事ができる。

それとは別で、react-aria-components をベースに構築する事も検討したが、やはり多くのコンポーネントを kintone ライクにカスタマイズするのはそれ相応の時間を要する為、残念ながら見送った。ボタンやタブ、ダイアログ程度であれば選択肢になり得たが、DatePicker を kintone ライクとするのは (もちろん可能だと思うが) なかなかややこしそうだと感じた。

また kintone UI Component より Table と ReadOnlyTable という二つのテーブル系コンポーネントが提供されているが、これらはあまり大量のデータを表示するケースを想定していないようで、ソートやフィルター機能が含まれていない。その拡張も容易ではないため、テーブルは React Table をベースとした独自実装となった。

しかし全体的には @lit/react でラップした kintone UI Component を用いて非常に効率よく UI を構築する事ができており、ライブラリ自体の品質の高さはもちろん、Lit 周りの環境もかなり進んでいる事を実感している。