スタイルガイドは取り入れやすく捨てやすくが大切

スタイルガイドの作成にはfractalを使っている。

ずっとHologramをつかっていたけど、fractalに乗り換えたという記事(post_link slug='styeguide-generator-fractal-recommend')を書きました。

fractalをどういう風に使うのがよいか、ある程度自分の中で考えが固まりました。

fractalのディレクトリ構成はくせがある

先に紹介した以前書いたfractalの記事ではfractalのデメリットとしてディレクトリ構成が冗長になりやすいということを書いた。

これはfractalがスタイルとテンプレートと設定を一つのディレクトリで管理するというコンポーネント思考を持っているからです。

たとえばボタンのスタイルガイドを作ろうとした時、下記のようなファイル構成になる。

— button
|— button.css(scss)
|— button.hbs
|— button.config.json(yml)

通常開発するときはcssなりscssをこんな形で配置することはないと思う。

つまり一から作るプロジェクトでも、すでに運用中のプロジェクトでも、fractalを使うためのディレクトリ構成になってしまう。

使っている間は良くてもfractalを捨てた時に不自然なディレクトリになり、途中から入れるにしてもこのディレクトリ構成に作り直す必要がでてしまう。

スタイルガイドを取り入れやすく、捨てやすく

取り入れにくく、捨てにくいfractalのディレクトリ構成だけど、一つ我慢するだけで取り入れやすく、捨てにくいスタイルガイド生成ツールになる。

唯一我慢しなければいけないのはcss(scssやless)のコードをドキュメントに載せないこと。

fractalではスタイルガイドでHTMLはもちろん、スタイルシートのコードも見ることができる。

ただしスタイルシートのコードを見るには先に書いたfractal特有のディレクトリにする必要が出てくる。

スタイルガイドのコードを完全に分離する

プロジェクトでよくあるディレクトリ構成は下記のようなものだと思う。
— root
|— src/
  |—— styles/
     |———— style.scss
  |—— scripts/

こういうディレクトリ構成でたとえばrootなりsrcなりにstyleguideというディレクトリを切って、そこにfractalで使うコードを入れるようにすれば完全に分離することができる。

分離することで運用中のプロジェクトにもすぐに取り入れることはでき、スタイルガイドを捨てたくなってしまった時に、styleguideのディレクトリだけまるごと消してしまうことができる。

fractalの設定を変更する

fractalではcomponentsでsetしたpathがスタイルガイドのコードが置かれるディレクトリになる。
fractal.components.set('path', __dirname + '/styleguide'); //スタイルガイドのコードがあるディレクトリ

このディレクトリにテンプレートファイル(hbs)、設定ファイル(json or yaml)を配置することで通常どおりスタイルガイドを生成することができる。

fractalではディレクトリ内にcssやscssがある場合にのみ、スタイルシートのコードもスタイルシートガイドが参照できるけど、参照の必要がなければ別に配置しなくてもよい。

このディレクトリ構成にすることで、スタイルガイドのコードだけを完全に切り離すことができる。

スタイルガイドは導入した後を考える

スタイルガイドってどういうUIがあるか目に見えてわかるから、導入するときなんかは「おお!めっちゃ便利!」って感じがち。

フロントエンドとサーバーサイドの開発者が別れている時にも、サーバーサイドのエンジニアは定義されているUIがHTMLと一緒に見られるのはメリットだと思う。

ただスタイルガイドは見るだけの人は良いけど、運用する側は結構なコストがかかる。

正直スタイルガイドの運用はかなりめんどくさい

運用が進み次第に手入れされないスタイルガイドと最新のスタイルシートのプロジェクトができることもある。

更新されないスタイルガイドは混乱のもとなので、それならば無いほうがマシとも言える。

そんな時にスタイルガイドを捨てる選択が生まれ、いらなくなったスタイルガイドのコードだけを捨てることができるのは大きなメリットだと思う。

スタイルガイドは作ってみないと運用できるかわからない

スタイルガイドを作るのも仕事ならきちんとメンテしろと言われそうだけど、プロジェクトによってはどうしてもメンテできないことだってある。

先にも書いたようにメンテするのは大変。

box color='blue' title='メンテできなくなる理由'

  • スタイルガイドの工数を確保しなければならない。
  • 作ってみたけど、あまり見られなくなった。
  • デザイン段階でコンポーネントがうまくされていない。
[/box]

実際に取り入れてみたもののメリットよりもデメリットのほうが大きくなるなんてことは、運用してみてわかること。

こういう状況でスタイルガイドは見やすくわかりやすいのはもちろん大切だけど、取り入れやすく、捨てやすいものがいいんじゃないかと思う。

コウジ
Vue.jsが好きなフリーランスのフロントエンドエンジニアです。 フロントのHTML・CSS・JavaScriptの設計実装をメインに、RubyとNodeでサーバーサイドやってたりもします。
目次
    Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発