コンポーネント設計【 2 】
前回のがわりとごちゃごちゃうるさく書いていたので今回からは真面目にコンポーネント設計をやろうと思います。
（というかこの記事から見たほうがいい）
まず今回作るのがこれ。
このデザインをまずじっくり考えてみる。(gifだから動くけど)
AtomicDesign
atomicdesign.bradfrost.com
英語だからわかんねーよ！と思うけど、日本語化しているブログとかは訳者の主観がすごく入るからなるべく英語を原典にしたほうがいい。
Atom=原子ということで「原子レベルまで分解しようぜ」っていうデザイン（設計方法）。
原子＜モジュール（ユニット）＜集合体＜テンプレート＜ページ、とこんな感じどんどん大きくなる。
つまり、右から順に分解していくのがセオリーというわけ。
いろんなブログには分解としか書いていないけど、一番重要なのはなんの情報を保持するべきか。その分解したものが「知っておくべき情報」「知らなくてもいい情報」というのが必ずあるはず。
例えば人間の手が情報として視覚の情報を持っていなくて困ることはないと思う。手には目がない。もつべきものは触覚の情報だけである。
AtomicDesignはUIデザインの話だけではなく、情報設計もしっかり考えてやらないとやる意味がない。
次から解説する。
Pages
AtomicDesignにおける最大の要素。
ブラウザで見るページ、スマホで見るページ、デジタルサイネージで見る広告全体。
ここまで完成して初めて世界に産み落とされる一つの生命体になる。
作業内容は肉付けになるかな。
人間で言う、人間そのもの。
持つべき情報
肉。Webにおける肉ってなんやねん。
テキスト、画像、色かなぁと思う 太ったり痩せたりするように流動的な情報になるのかなぁ。
このブログで書いているときが肉付けなのかも。これ書かないとただの骨だもんね。
Template
これもちょっと概念が難しいなと思った。
ワイヤーフレームみたいなもので、骨組みを考える。俺は骨格と言っている。
これもComponentなの？って思うかもしれない。確かに違和感があるけど、骨格次第で原人にも現代人にもなる。
持つべき情報
骨の配置情報。骨の位置を決めているのは骨格だ。
なにをどこに、どういう感じ置くかを情報として持つべき。
SPAだと「表示する」「表示しない」とか「なかったら詰める」みたいなことになる。
Organisms
翻訳すると「有機的組織体」らしい。なんやねん。俺は集合体ということで良いと思う。
Headerとかが好例としてあるが、Templateの骨組みとかなり近いものがある。言い換えると骨格と骨ともとれるだろう。
頭蓋骨には脊髄の情報はいらない、両方いるのは骨格（Template）。
骨格には頬骨の情報はいらない、いるのは頭蓋骨（Organisms）。
この感覚はわかりにくいかもなぁ。
持つべき情報
臓器の配置情報。例えば、頭蓋骨が把握しとくべきは「眼球をどこにおくか」「脳みそをどこにおくか」ということになると思う。
頭にある臓器をすべて知ってれば頭が完成する。
Molecules
分子。人体で例えると臓器としたい。
個人的に一番むずかしい。
検索ボックス、リンクボックス、カードなどかなぁ。
わりとUIデザイナーはMoleculesから考えるような気がする。
持つべき情報
原子の数、原子に送る情報を包括的に持っておくべきかなと。
個人的にはAtomicDesignで最もたくさん情報を持つべきところでもある。
たとえば検索ボックスもラベルの長さ（文字数）によって検索ボックスの長さ（横幅）が変わるかもしれない。（固定の横幅とか、文字数とか往々にして発生すると思う）
その場合、だれが情報を持つべきか。禅問答がはじまる。
ラベルが検索ボックスの長さをもつ？その逆？
仮にどっちかに情報をもたせたとてメンテしやすい？
もしラベルと検索ボックスの間にアイコンが入ったらどうする？
なら、原子を包括している分子で情報を持つべきだ。
コードで書くとこんな感じ。
searchConfig = { labelLength: 11, inputWidth: 200 }
let isLabelLong = searchConfig.labelLength > 10 ? true : false
let isInputLong = searchConfig.inputWidth > 100 ? true : false
<label long={isLabelLong} /><input long={isInputLong} />
ここでの包括的情報はsearchConfigというオブジェクトだ。
labelLengthとinputWidthにはそれぞれの原子に必要不可欠な情報が格納されている。
しかし、必要不可欠といってもラベルの文字数は必要なく、そのラベルが閾値と比較して長いか長くないかだけ必要にするべきだ。
細かく文字数ごとにスタイルが変わるとかだったら必要かもしれないが、原子に送るべき情報は小さければ小さいほどメンテしやすい。
Atoms
原子。身体で言うなら赤血球とかかなぁ。
HTMLのタグとイコールになってもいいのかもしれない。
タグまで行ったらほぼ最小単位だろうが、
タグの中に があったらどうする。
分子になりえるのか？ここもすごく難しい。
意味合いとしてのAtomsなのか、構造上のAtomsなのか。
持つべき情報
ラベルなら文字だけ。もしかしたら自分自身で解決するスタイルもあるかもしれない。
原子以下の要素は存在できないようにする。
どうしても存在する場合は分子と考えてAtomicDesignをやりなおす。
ざっとこんなん。
人体で例えるとわかりやすいかも。
次回はデザインを実際にAtomicDesignします。
コンポーネント設計【 1 】
狂えばカリスマか！？
吠えれば天才か！？
死んだら神様か！？
何もしなけりゃ生き仏か！？
はじめに
フルスタックエンジニアと言われる人たちが3年くらいかけて書いたコードを理解した上で修正、機能追加、リファクタリングをしている。
積み上げられた3年間は、マークアップから「SPAやりたい！」って激動のJavaScript界隈に飛び込んだ俺にとっては、まさに「魔法の書」というより「ヴォイニッチ手稿」に近い。
もちろん、そのまま未解読だと仕事にならないから、さっぱりわからない俺に先輩が一から教えてくれた。
おかげで最近ではなんとか体裁が整ったコードが書けるようになった。多分。。。
とは言うものの、インプットがあまりにも多すぎて俺の脳みその容量が溢れてしまう。なので、外部記憶装置として神話の如く時代を超えて自分の脳みそに語り継ぐためにブログに書こうと思った。
今回は筆者の経緯とか状況の説明とかそんなん。
アニメ12話が終わって「こうして出会った」が語られるOVAみたいな感じ。
俺はあんまり好きじゃない。
その後 or つづき
HTMLとCSSと（今思うとゴミみたいな）JavaScriptを時間重視で書いてた前職と比べて今はメンテナンス、パフォーマンス、セキュリティとかを重視してコードを書くようになった。
受託開発と自社開発の違いもあるし、前職も別に手を抜いて書いていたわけではないけど、とにかく時間に追われて書くことが多かった。というか全部。
現在も期限はあるけど、時間への追われ方全然違うような気がする。
そうなるとコードの基本方針も前述の通りな方向になる。
エンジニアとしては当たり前なんだけど、当時の俺としては初めて意識した概念だったのでそこからちゃんと理解していく必要があった。
それについては今度別の表題にして記事を書こうと思う。
本連載はもうちょっと深掘りしてメンテナンス、パフォーマンスの向上に繋がるコンポーネント設計について実際のソースコードを交えながらまとめることにする。
Component 最終形
メンテナンス、パフォーマンス重視の面から肝心のコードはというとReactを使っていた*1。
そうまたReactだよ。なんかみんな難しいからって諦めるやつ。
そもそもこの記事を書こうと思った理由がこのQitaの投稿。
俺が書きたかったやつやん！
と思ったけど後半急にfluxアーキテクチャとか出て、ナチュラルにReactも出る。
これ昔の俺だったらその瞬間、アニヲタWiki(仮)見始めるやつだよ。
今の俺は復習、予習も兼ねて読めるからすごく勉強になったけど、これ結構難しいやつ。
すごく文章きれいだからわかりやすいけど。
コンポーネント設計にどう関係あるんだよ！
状態まではなんとなく理解できたけどRedux？Store？
HTMLとCSSとjQueryで生きているので関係ないわ！
わかる。
ワイ「で、でもワイ、、、なんの能力もないゾ、、、」
ルフィ「うるせェ！！！！イこう！！！！！」ﾄﾞﾝ!!!!!
フィ「俺は面白い奴が好きだ！！！」ﾆｨ
けど、設計を考えるのはすごく面白いから一緒に学ぼう！
Reactも最初から説明するよ！
よゆーよゆー。
ってかこういう俺もそんな自信が無いんだよ。
デザイン
というわけで本連載で最終的に作るコンポーネントはこれだ！
こんなん<select>タグをCSSで装飾すればできる！と思うけど、先日にこんな感じのコンポーネントを作っててコンポーネント設計のあり方、ひいては嵌まりやすい状態とインタラクションをすごく意識できたのでぜひ作成してほしい。
- HoverでOptionがリストで表示される
- LeaveでOptionがリストで非表示になる
- Optionリストの項目をHoverすると背景色が変わる
- Optionリストの項目をClickすると現在の値としてテキストが変わる
ちょっと説明がわかりにくいけど、要するによくみるSelectBoxと同じ挙動。
ということで次回からコンポーネント作っていくぜ！