見出し画像

kintone開発小ネタ集2・51-modern-default と kintone UI Component v1 って、何が違うの?どうやって使い分けるの?

ずっと気になっていたのですが…

kintoneのカスタマイズやプラグインを作成する時、皆さんはどのようにUIを構築するのでしょうか?もし、「素」のJavaScriptだけで画面を作ろうとすると、kintoneの他の画面とは異なる、違和感があるというか、素人くさいというか、そんな画面になってしまいます。すぐにわかるのはボタンですね。CSSで見た目を調整しないボタンをHTMLだけで表示すると、Webブラウザーのデフォルトの、あの小さくて灰色のボタンが出てしまい、kintoneの画面で表示される他のボタンと比べて、いかにもミスマッチです。
そこで、顧客にとって使いやすいものを提供したいと願うソフトウェアエンジニアの端くれである私は、どのような実装が「Best way」なのか調べてみます。するとどうでしょうか。cybozu developer networkには 51-modern-default と kintone UI Component v1 という、kintoneカスタマイズ画面の「見た目」を整える2つのライブラリが見つかってしまいました。

なぜ2つなんだ…しかも困ったことに、この2つのライブラリをどのように使い分けろ、というサジェスチョンはcybozu developer networkには一切書かれていないのです。この2つのライブラリは一体どのように使い分けるのか、自分なりに調べてみました。ちなみに私はどちらも使ったことがあります。使ったことがあるくせに、これをどのように使い分けたらよいのかわからなかったんです…。

2つのライブラリの機能を比べる

2000年代後半のことでしょうか?Twitter社が公開した Bootstrap はその使い勝手と共に「CSSフレームワーク」という言葉を一般的にした記憶があります。当時珍しかったレスポンシブレイアウトや、統一感のあるスタイルで、あの頃は「いかにもBootstrapで作りましたとわかるWebサイト」がたくさんあった記憶があります。
ここでよく理解していない私は「フレームワーク」といえば、それはWebアプリケーションフレームワークの事を指していて、それは当時流行っていた、Javaといったバックエンドで利用される言語で書かれたものだ、という先入観がありました。しかしWebサイトのデザイン・レイアウトを統一的に扱うという意味でCSSでも「フレームワーク」という言葉を使うのでしょうね。

ここまで読んだ方は「Bootstrapの話がkintoneの2つのライブラリに何の関係があるんだ」とお思いでしょうが、私の勝手な印象から、 51-modern-defaultは「CSSライブラリ」であり、kintone UI Component v1(KUI)は「フレームワーク(CSSかJSかは問題ではなく、どちらかというとJS寄り)」のような印象を受けます。
つまり、ちょっとしたボタンを1つや2つ追加したい、というだけのためにKUIを使うのは「大げさ」であり、それは51-modern-defaultで事足りるような気がします。というか、私は実際にそのようにしました。

51-modern-default の使用箇所はHTMLである

例えば画面にボタンを設置したいなら、HTMLでこのように書きます。

<button class="kintoneplugin-button-normal">通常のボタン</button>

https://cybozu.dev/ja/kintone/sdk/library/plugin-stylesheet-guide/ より引用

ここで注目すべきはクラス名だけですね。
もしこれだけで事足りる用途であるのに、KUIを使ったらどうなるでしょうか?

    const Kuc = Kucs['1.4.0'];
    const button = new Kuc.Button({
      text: 'sample',
      type: 'submit',
      className: 'options-class',
      id: 'options-id',
      visible: true,
      disabled: false
    });
    header.appendChild(button);

https://cybozu.dev/ja/kintone/sdk/library/kintone-ui-component-v1/ より一部抜粋

JavaScriptで結構な量のコードを書く必要があり、面倒です。
ではなぜJavaScriptでわざわざボタンを定義しなければならないのでしょうか?想像できるケースとしては、ボタンを動的に生成・破棄するような場面では、HTMLに静的にボタンを定義することはできません。そのため、どうしてもJavaScriptにより「コードとしてボタンを定義する」必要があります。これは51-modern-defaultにはできないことです。

私なりの結論

  • KUIは画面上のコンポーネントを「The kintone way(kintoneのやり方)」で実装でき、見た目は「おまけ」としてkintoneに似たものが自動的に表示されるのがKUI。

  • ちょっとしたカスタマイズ、プラグインではなくJSカスタマイズで少しだけkintoneにボタンなどを追加したい場合、コンポーネントの見た目だけkintoneと合わせたい場合は51-modern-default

こんな感じでしょうか?51の方が先に作られて、後からKUIがリリースされたような雰囲気ではあります。ここで「適材適所」などと使い古された言葉を言いたくもなりますが、必要なことは「実際に使ってみて、それが自分の用途に合っていた場合は採用する」ということですね。これを読んでいる方は記事の結論が当たり前すぎて拍子抜けしたかもしれませんが、2つのライブラリの使い分けについての記事が見つからなかったので、今回私が書いてみました。

お問い合わせ

Kintone導入検討時のご相談から、導入後の利活用・定着化に至るまで、私たちは、お客様と「伴走」しながら思いを込めてサポートいたします。ご相談無料ですので、ぜひお気軽にお問い合わせください。

記事作成
kintone推進チーム
使用画像
UnsplashRaquel Martínezが撮影した写真