KJ DEV
Tips

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

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

ずっとHologramをつかっていたけど、fractalに乗り換えたという記事を書きました。

https://zenn.dev/koojy/articles/styleguide-generator-fractal-recommend

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

目次
  1. fractalのディレクトリ構成はくせがある
  2. スタイルガイドを取り入れやすく、捨てやすく
    1. スタイルガイドのコードを完全に分離する
    2. fractalの設定を変更する
  3. スタイルガイドは導入した後を考える
  4. スタイルガイドは作ってみないと運用できるかわからない

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

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

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

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

1
2
3
4
— button
|— button.css(scss)
|— button.hbs
|— button.config.json(yml)

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

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

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

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

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

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

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

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

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


プロジェクトでよくあるディレクトリ構成は下記のようなものだと思う。

1
2
3
4
5
— root
|— src/
  |—— styles/
     |———— style.scss
  |—— scripts/

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

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

fractalの設定を変更する


fractalではcomponentsでsetしたパスがスタイルガイドのコードが置かれるディレクトリになる。

1
fractal.components.set('path', __dirname + '/styleguide'); //スタイルガイドのコードがあるディレクトリ

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

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

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

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


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

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

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

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

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

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

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

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


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

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

メンテできなくる理由は

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

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

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

開発で参考になった本

実際に読んでみて開発に役立った本を紹介しています。

これから本格的にデザインシステムを学んで作りたい時にとても参考になる一冊でした。デザインシステムついて幅広く触れられているけど、「tailwindを触ってデザインシステムに興味を持った」という人でも少しずつ取り入れやすいです。