Storybook の用なコンポーネント単位の粒度で入力・レイアウトするとしたらどうするかを考える
この辺はどちらかいったら CMS の都合なので、そのできる範囲でやるか、できそうなCMSを探すか、なんか他の代替手段でやるかといったところになる。
一方で最近のサイト構築だとデザインをつくってフロントエンド作ってという流れの中で、 Storybook とかをつかったりしてデザインシステムを作ったりということもやる。
デザインシステムを作るかどうかという話より前に、フロントエンド側、デザイン側はある程度パターンだししてコンポーネント整理とかしていたと思う。
Storybook に定義した要素を CMS でも使えないか？という話を考えてみる。
これまでやってきていた CMS の実装に関する設計だと、ある程度の入力・表示パターンが絞り込まれていて、それを満たすためのフィールドのパターンを用意する、ということをやっていた。
追加・調整があればその時追加したり調整するような感じ。
Movable Type だと MTAppjQuery でマルチフィールドで用意する。 Craft CMS だと Matrix フィールドで用意する、といった形になる。
Storybook に定義したものを、CMS上で自由に使いたい（つかいこなせるかどうかはおいておいて）というパターンをどう対応するかを考えた時があった。
それの1つの解は @tinybeans が拡張した MTAppjQuery のマルチフィールドで使う汎用フィールドにも繫がっている。
MTAppjQuery v2.8.0 で追加された「汎用フィールド」が便利ですよ | かたつむりくんのWWW
https://tinybeans.net/blog/202...
設定する方も若干大変なところはあるけど、そこは拡張との裏返しとおもってご理解いただきたい。
実際便利なので、是非試してみてほしい。
似たような話を、先日の Neo プラグインを使った時にどうなるかを試してみた。
例えば、Storybook のサイトで公開されていた、 Smart HR UI のボタンを見てみる。
Projects | Component Encyclopedia | Storybook
https://storybook.js.org/showc...
Button - Button ⋅ Storybook
https://smarthr-ui.netlify.app...
ボタンの設定としてこんな感じで、テキストとURLを入れるのはほぼ確実だろうからそれを入れるフィールドを用意しておく。
設定値は Storybook でいうところのこの辺の話。
それぞれの要素に対して複数の設定値を持てることになる。
Neo の設定としてはこんな感じで設定用にフィールドを追加していく事になる。
1行テキストやドロップダウン、チェックボックスとかを個別に用意していくとフィールドの数が多くなるので、ここはある程度まとめて設定できた方が便利そう。
「ボタン用の設定」「画像用の設定」とか story の数だけフィールドを作る事にはなるので数がすごいことになるのは想像に難くない。
ボタン関係の設定用として、テーブルフィールドを1つ用意する。
これを Neo のボタンブロックに設定用のタブに追加すると、こんな感じになる。
数がこのくらいであれば問題なさそう。
テーブルフィールドは元々行を自由に追加できるわけだが、今回はその設定は不要なので最小行数、最大行数ともに1にしておく。
ボタンのテキスト、URLはよく使うという前提で別タブにしておく。
この辺の1行テキストとかテキストエリアはボタン以外の story でも使うことになるだろうから、Craft のフィールドとしては text1, text2, text3 とかを用意して使い回す事になりそう。
テーブルフィールドだと若干見づらいな、と思っていたら @tinybeans がマトリックス（行列）フィールドも入れられるとアドバイスくれたので試してみる。
そのパターンだとこんな感じの入力欄になる。
Matrix フィールドの設定はこんな感じで。
ブロックは1つで必要な設定のフィールドを追加していく感じ。
この story 全部の設定をするのか、、、と考えると若干萎えるところはあるが。
まぁ、できなくはなさそうかもなぁという気はする。
レイアウト的な要素のものや、ヘッダーフッターとかコンテンツに使わないもあるので、そういうのは除外できそう。
（ヘッダーフッターとかでてくると、コンテンツ部分以外も含めて管理を、、、とかになりそうだがそれは一旦考えない）
この設定ができたところで使いこなせるのか？というのはまた別の問題。
本当に必要なのか？というのもちゃんと考える必要もある。
CMS側（Craft だと Neo）の設定パターンとしては大きくこんな感じにわかれて、入れ子になるんだろうなぁと。
- wrapする物
- section
- nodes
- Grid
- アコーディオン
- ...
- Grid
- nodes
- Grid
- アコーディオン
- ...
- アコーディオン
- nodes
- Grid
- ...
- section
- nodes（末端、ノード、フィールド）（+ settings）
Neo の最小単位。フィールドは種類ごとにいくつか用意しておく- テキスト
- テキストエリア
- ボタン
- ...
こういうのを用意して組み合わせるとこんな感じということで。
まぁまぁページが大変になりそうではある。
設定系はタブにわかれるが、そうならない物（カラムの幅設定とか）が若干ジャマな感じがする。
この辺は WordPress のブロックエディタの方が使いやすそうなイメージがある。使ってるわけではないので見ただけの印象ではあるけど。
フィールドが多いので保存するときも気にはなるが、やれないことはなさそう。
提案するか・・・・というと悩ましい。
これで柔軟に設計はできそうだが、これがよかったのかということを考えそうな気がする。
まだまだ考えることも多いし、いかに普段の考えが足りず惰性でやっていたのかということを再認識した。