UIコンポーネント集 Qiita：Coat

LTを聞いているという感覚でご覧ください。

Qiita:Coat

• Qiita用のUIコンポーネント集
• GitHub用のUIコンポーネント集をForkしてつくりはじめた
• レポジトリ: https://github.com/increments/qiita-coat
• デモサイト: http://increments.github.io/qiita-coat/

今週月曜からやってる

これはcommit数

Qiita:Coatが必要に感じた背景

• 全ての開発者に共通する願い
  • 高速に開発したい
  • 秩序がほしい (a.k.a. 最低限度の品質の保証)
• 開発体制の情勢に起因する理由
  • 開発人数が徐々に増えつつある
  • 社員11人+アルバイト3人
  • 四半期に1人ぐらい増えてる
  • 50人が51人になるとかならともかく、5人が6人とかになると大きく変わる
• その他の理由
  • サポートサイトや採用サイトなどQiita風のデザインをあてたい別サービスも増えてきた
  • Qiita風のデザインでプロトタイプをつくりたい機会が増えてきた
  • bootstrapに依存してるとbootstrapに存在しないUIの共通化に失敗する
  • bootstrapのUI無理矢理使って品質落とすか共通化諦めて手で書くかコピペするか機能追加諦めるか
  • そもそも変更要求の多いサービスで汎用クラスの濫用に未来が見えない
  • 片手間CSSへの反抗

導入にあたってどうしたか

• 特に「今期はUIに対する施策としてこれをやりましょう」みたいに決めたわけでは無い
• r7kamuraが興味を感じたのでとりあえず俺が責任持つんでやってみますという感じ
• 雑に言うと勝手にやってる
• 1日の10%ぐらいのリソースを使っているイメージ
• 失敗したらすぐ逃げられるようにはしてある

Qiita:Coatの開発どう進めてるのか

• とりあえずr7kamuraが全部やってる
• Qiita:Teamからスタート、のちのちQiitaにも適用する
• 設定画面からスタート、のちのちそこ以外にも適用する

Qiita:Coatの思想など

• mixin, placeholder, variableだけを提供する
• .btnや.col-sm-9みたいに汎用クラス名は提供しない
• アプリのHTMLでは.editor-submit-buttonのようなドメインの言語を使ってクラス名を書いていく
• アプリのCSSでは @include button-primary などして適切にデザインを当てていく
• http://bourbon.io/ と少し思想が近いかもしれない

使用例

Qiita:Teamの設定画面に実験的に適用してみた例。

ちゃんとやるなら意外と多方面への知識と興味が必要

• Sassの細かい仕組み (mixinがどうとかplaceholderがどうとか変数スコープがどうとか)
• 大人数の開発でどこで破滅するか知っておく
• Railsのsprocketsとの相性良くするにはどう工夫すべきかとか
• sprockets捨てるのもいいけどそれで世界からsprocketsが消えるわけではない
• bower, npm, gulpなどのエコシステムの現状も知ってた方がいい
• どうせビルドツール使うことになるのでどれでもいいけどどれも使えないとかだとつらい
• CI用意してGitHub Pagesと連携させてデモサイトつくるみたいな知識も要る
• GitHub Pagesのルーティングルール色々と癖があるので注意が必要
• ローカル開発時のプレビュー用サーバも用意しないといけない
• 一貫性のある命名規則を決められるかどうかが品質を大きく左右しそう
• そもそもCSSに幾らか自信が無いと無理 (他人に使わせることになるので気後れしてしまう)
• 他のCSSフレームワークがどうなってるか調べる能力も要る
• 普段からCSS書いててどこで困るか肌感で知ってないと使いにくいものができそう

内部実装

• GitHubのやつは実際には参考にしただけで結局いちからつくる手間は必要だった
• そもそもGitHubのはmixinベースではないので直接は使えない
• デモサイトがJekyllベースで柔軟性が無いとかその他細かい部分で不満がいろいろある
• 以降内部実装を幾つか紹介

npm run

• npm run xxx が全てのコマンドのエントリポイントということにしてる
• package.jsonのscriptsプロパティに必要なコマンドを全て集約していく形式
• 内部でrspecを使っているとかgulpを使っているとかは意識しなくてもいいようにしてる
• qiita-coatの開発に従事したい人はとりあえず npm install して npm run すればいい

デモサイト・プレビュー環境構築技術

• 開発時にUIをプレビューできる必要がある
• 本体のアプリに直接組み込まないと確認できないとかだとつらすぎる
• ユーザ用にデモサイトも用意する必要がある
• プレビュー用サイトとデモサイトは同じやつを使えばOK
• Rails開発に慣れてる人が多いのでサイトはそれ系のツールを使いたい
• 新しくmiddleman導入して開発者に覚えさせるとかはNG
• Rackアプリ (今回はSinatra製) でプレビューできるようにした
• テンプレートエンジンは社でslim使ってるのでslimにした
• CSSはnpm run watchで適当に監視してgulp-sassで変換する
• Sitespecを使ってそれをそのまま静的サイトに変換できるように
• gulp-gh-pagesを使ってそれをGitHub Pagesにpushするように
• Travis CIでGitHubのPersonal Access Tokenを使ってCIからビルドできるように
• 同時にテストも手に入れられてお得
• できたのがこれ http://increments.github.io/qiita-coat/
• モバイル対応とか全くしてなくて雑

命名規則hacks

• 名詞-形容詞1-形容詞2-...-形容詞n という命名規則
• e.g. button, button-primary, button-primary-disabled, avatar-small
• 形容詞1, 2の追加順序に曖昧性が残るのが課題
• コーディングルールとして理由が無ければ要素の定義順序をABC順にしている
• この命名規則とコーディングルール合わせるとソートするだけでグループ化できて便利

今後

• まだまだ実験段階。Forkしてあまり変えてないのでGitHubと大差ない
• UI哲学は参考にしてブランドに合わせて改良していけるとよい
• まずはQiita:Teamにゆるゆると導入、Qiitaにも還元していけるとよい
• Qiita <-> Qiita:Team で互いにユーザビリティとブランドイメージ高められるとベスト
• Qiita風のなサイトをつくりたい人達やパーツちょっと借りたいみたいな人も使えるように汎用性を高める
• UIのコンポーネント化が正しい道なのであれば、事例として他社のサービス開発者にも勧められる
• UIのコンポーネント化が間違った道なのであれば、事例としてやめといた方がいいよと言える
• 確実に成功とかはなくてその中間のいずれかの状態にあるだろうと思うので、変数を集めてこういう条件が揃えばUIコンポーネント化した方がいいよということが言えると嬉しい (中間状態にある = トレードオフだよねという結論だと思考停止してて意味無いので気を付ける)