Angular1によるSPA開発 – 設計編
Angular1によるSPA開発 – 基本編
こんにちは、エンジニアの尾形です。
前回のブログではSassコーディングを行なう上で必要となる各種自動化の例についてお伝えしました。
今回からはAngular1によるSPA(シングルページアプリケーション)の開発について、数回にわたってご紹介していきたいと思います。
CSS設計の選定に学ぶ仕事術
おはようございます おやすみなさい 皆さま、初めまして。今回のプロジェクト開発者の一人コースケと申します。
本日は連載中の尾形(以降リーダーと呼びます)に代わり特別編といたしましてイチ開発者である僕からフロントエンド挑戦における失敗談を皆さまにお伝えさせてください。
不安の中始まったフロントエンドの挑戦
今回のプロダクトで僕が任されたのは、フロントエンド周り全般。
特に、デザイン周りでは自分一人で結構な量の調査や選定、実践を行ないました。
- HTML/HTML5の調査
- CSS/CSS3の調査
- Sassの調査
- CSSデザイン/設計の参考書の選定
- 設計方針の選定
- 参考となる規約の選定
- プロトタイプの作成
などなど。
フロントエンドの調査に僕一人で突っ込まれて孤立しながら、右も左もわからぬまま「初心者」と「入門」を&検索にググり続けました。。

※画像はイメージです。
CSS、HTMLの情報はネットに豊富にあるので、情報量については困りませんでした。
とにかく困ったのは、実際にCSSを書き始めた時。CSSにはたくさんのTipsがあります。その中でデザインに合うものを組み合わせてサイトを構築するのですが、当たり前ですが、TipsはTipsだけを説明しているものばかりです。
だから、


のような場合は、数あるCSSプロパティの中から原因を調査、発見して解決しなければならなかったのです。
Tipsだけでは対処できない部分ですし、原因の検索の仕方も難しいです。
対処法としては
- 地道に対象を探し、違う方法でのデザインを行なう
- 力技で無理やり対応する(位置を無理やり固定する。邪魔なモノは「display:none;」で消す。 などなど)
です。
綺麗なCSSが書ければ、もちろんよいのですが、まだフロントエンドのテクニカルレベルが低い僕には、スケジュール重視で無理やりなところも多々ありました。
あとになって、もっと正しい対応方法がわかることもありました、あまり立ち止まりすぎず、どんどんと前に進むことが重要だと実感もしました。
少しづつ見えてきたフロントエンドのカタチづくり
さて、悪戦苦闘しつつも進めていたフロントエンド挑戦ですが中でも特に印象的だったのが「CSSの役割分担」の設計の選定です。
いまはFLOCSSという設計思想を使用しています。ですが、立ち上げ当初はITCSSを使用しておりました。
フロントエンドの調査前に、チームメンバー全員で読んだのが『Web+DB PRESS』という書籍のCSS記事でした。
記事には「ITCSS」について記述があり、ここで初めてCSSの設計という概念を知りました。
CSS設計調査ではその情報をもとに調査を行ないました。以下調査結果です。
http://qiita.com/makotot/items/2c3e99f15dca2789d403
⇒CSS分割、レイヤーごとの役割分担
SMACSS
http://chroma.hatenablog.com/entry/2013/07/22/120818
⇒CSS分割、レイヤーごとの役割分担
FLOCSS
https://github.com/hiloki/flocss
⇒CSS分割、レイヤーごとの役割分担
⇒命名規約のBEMについても触れている
OOCSS
http://www.risewill.co.jp/blog/archives/5652
⇒オブジェクト指向CSS
BEM
http://blog.ruedap.com/2013/10/29/block-element-modifier
→命名規約としてよく取り上げられている。
これらは調査中に良く目にしたため、この中から選定しました。
(※今回はOOCSSやBEMは本線から外れるので割愛)
選定方法としては時間が限られていたため、設計方針を2つに絞り、実際にテストコードを書き、より良いものを選ぶことにしました。
採用
SMACSS … 最もよく使われているという情報があった。
ITCSS … 役割分担がわかりやすいと個人的に感じた。
落選
FLOCSS … BEM規約まで触れており、初心者にはボリュームが大きすぎると感じた。
以下は実際に作成したSMACSSとITCSSのサンプルコードです。
[SMACSS]
/** * SMACSS * https://app.codegrid.net/entry/smacss-1 * http://qiita.com/matsui-a/items/9b9188904d160a3ec223 * http://chroma.hatenablog.com/entry/2013/07/22/120818 * * 「Scss」の設定ファイル * Settings...................プリプロセッサで利用するグローバル変数や全体の設定 * Tools......................プリプロセッサで利用するmixinやfunctionなど * * 「SMACSS」の設定ファイル * ベースルール................normalize.css、reset * ベースルール................要素型セレクタ * レイアウトルール............ページのエリア分け * モジュールルール............再利用可能なパーツ * →BEMを取り入れる場合はここ(http://chroma.hatenablog.com/entry/2013/12/15/165511) * 状態ルール..................特定の状態によってスタイルを上書き * テーマルール................テーマ管理用のCSS */ @charset "utf-8"; /* SCSS */ @import "settings"; @import "tools"; /* SMACSS */ // ベースルール @import "normalize"; @import "base"; // レイアウトルール @import "layout-1"; // モジュールルール @import "module"; // 状態ルール @import "state"; // テーマルール @import "theme";
[ITCSS]
/** * ITCSS * http://qiita.com/makotot/items/2c3e99f15dca2789d403 * * Settings............プリプロセッサで利用するグローバル変数や全体の設定 * Tools...............プリプロセッサで利用するmixinやfunctionなど * Generic.............normalize.css、reset * Base................要素型セレクタ * Objects.............装飾を持たないデザインパターン * Components..........コンポーネント * BEMを入れるならここ * Trumps..............ヘルパー。!importantを利用していい */ @charset "utf-8"; // definitions @import "settings"; @import "tools"; @import "generic"; @import "base"; @import "objects"; @import "components"; @import "trumps";
@import “settings”; ←これらが「レイヤー」と呼ばれ、各レイヤー毎に意味を持ちます。
@import “tools”;
importでレイヤーを呼び出しています。呼び出し順も重要で、CSSによる不具合を最小限にする仕組みのひとつです。
(詳細は各サイトでご確認ください)
結果としては、両者に大きな隔たりはなく、それよりも役割毎のレイヤー分割を行うことが重要だと感じました。
またSassの導入は決定しており「ITCSSのレイヤー設計の方がプロジェクトに合っている」と判断しました。
この一連の流れをリーダーに報告し、採用の許可を頂き、そして本格的なデザイン作成に入りました。
チームリーダーのフロントエンド参入により崩れ去った足場と気づいた未熟さ
設計方針がITCSSに決まり、少しづつ画面もできてきました。
画面自体はお見せできませんが
・全体レイアウト
・ヘッダ
・サイドバー
・メインコンテンツ
とTOP画面だけでいうと6,7割くらいです。

いままで外注したデザインのCSS/HTMLの拡張はありましたが、ゼロからのコーディングは初めてで骨が折れました。
ですが、少しづつデザインが完成されていくのはやりがいがあり、また成果が目に見えて楽しかったです。
「よし、もう少しでTOP画面は終わりそうだぞ!」と思っていたある日。いよいよリーダーがデザイン作業に参入しました。
リーダーはすぐに独自に調査とテストコーディングに着手しました。
「少し調べてみたいから、そのままTOP画面は作成を続けて」ということで僕はTOP画面作成を続けました。
やがて他メンバーも参入し、みんな独自にCSSのテストコーディングをしました。
ちなみに、この時点では以下を提出していました。
- ITCSS
- シングルクラス
- BEM
- 外部の使いやすそうな規約
しかし、やがてリーダーの調査が終わると「FLOCSSの導入をしよう」という話しが持ち上がりました。
理由としては以下です。
- 「FLOCSSは OOCSS, SMACSS, BEM, SuitCSS, MCSSなどの考え方を取り入れたもの。CSS設計のいいとこ取りをしたいときは、FLOCSSをベースにすると良い」という情報がある。
- ITCSSの日本語ソースが少ない、世の中の流行りとネットの情報量は重要である。
- 全体の方針が固まっていない、共通部品がないのに、各々がなんとなく作業に着手してしまったので、既にカオスになりつつある。
なので、FLOCSSの導入、ガイドライン策定、共通部品・画面の雛形(サンプル)を先に定めてレビューしてから、全員で開発に入りたい。
聞いた時の正直な感情としてはスーパーサイヤ人になるのではないか、と感じるくらいに怒りと悲しみの狭間にいました。
「え、ちょいまって、OKしましたやん」とか
「全体の方針は決めましたやん、、だからITCSSでがんばってたんやん」とか
「TOP着手って僕だけやん、結局一人で全改修かい」とかとか
ただリーダーの
「みんなほぼ初心者なので、実際にやってみないと良し悪しがわからないし。で、実際にやってみた結果、方向性や改善点が見えてきたので、軌道修正と規約策定に入るところだね。」の言葉で、「いままでやってきた結果として、次の段階に進めたんだ」と言われた気がして救われました。
冷静に考えると
- 日本語の文献が豊富。
- BEMの考えを取り入れているので使いやすい。
というのは大きな利点です。
想定通り、改修作業はひとりで行なうことになり、精神的に辛いところでしたが、FLOCSSとITCSSは基本的な構造は似ているので、改修作業は案外簡単に完了しました。
また、リーダーの規約を決める力はすごく高く、それまでは方向性だけが決定しているのみで曖昧だった規約が次々に明文化されました。
チームにおいて「これを規約とします」を明らかにすると、メンバーも安心してコーディングができることも勉強になりました。
今回の挑戦を経て得たもの
以下が今回の失敗です。
- 選定基準として「情報量」や「世の中の流れ」を考慮しなかった。
- TOP画面のような大きい画面から作ってしまった。
- 規約の明文化をしていなかった。
以下、反省と学んだことです。
>選定基準として「情報量」や「世の中の流れ」を考慮しなかった。
選定基準は多岐に渡るため、これを考慮すればいいというわけではない。
リーダーを満足させられなかったことが問題で、他の設計手法と比べてより良く、より合っていると言えるだけの材料が必要。
選定時のインプット量をもっとを増やす。
>TOP画面のような大きいものから作ってしまった。
まず試作に時間がかかる。それだけで悪といっても過言ではない。
モーダルのような小さな雛形があれば話しにも説得力が増し、改修時に手戻りも少ない。
小さく始めることを心掛ける。
>規約の明文化をしていなかった。
「これがうちのチーム規約だ。」という明確な形まで落とし込むと、メンバーは安心してコーディングができる。
規約の選定時にはここまでを行なうこと。
以上です。
リーダーからの一言コメント
チームリーダーの尾形です。
CSSのコーディングを行なう上で一番重要となるのは、やはり「規約」です。
規約を定めずにチームメンバーが好き勝手にコーディングを行なったらどのような結果になるか。。想像に難くないですね。
CSSの設計方法(方法論)は数ありますが、サイトやチームの特性を考慮したうえで、それに適した方法論を採用することが重要です。
ひとりだけでコーディングするのであれば、正直どの方法論でも大きな問題はないと思います。
今回の開発では、わかりやすさ、チームでの開発のしやすさ、再利用性や拡張性の高さが、規約策定においての重要なポイントとなりました。
まとめと予告
今回僕の失敗談をお話させて頂きました。
あまりフロントエンドの失敗談ではない気がしますが、これから選定やプレゼンを行なう方の参考になれれば幸いです。
最後まで読んでいただきありがとうございました。
チーム作業をするための最適なCSS規約、Sassについて考えた
こんにちは、エンジニアの尾形です。
前回のブログではHTML/CSSコーディングを行なうにあたっての事前準備についてお伝えしました。
今回はCSS規約やSassによるコーディングの実例について、ごく一部ではありますが、ご紹介します。
FLOCSSをベースとした構成について
前回のブログで少し触れましたが、CSSコーディングを行なうにあたり、FLOCSSをベースとしたCSS規約を作成しました。
数あるCSS方法論の中でFLOCSSを採用した理由は以下の通りです。
- コンポーネントの概念がエンジニアにとって馴染みやすい。
- 候補のひとつであったBEMの概念が含まれている。命名しやすい。Sassとの相性が良い。
- 再利用性や拡張性が高く、機能追加や仕様変更に柔軟に対応できそう。
- 情報量が比較的多くわかりやすい。
FLOCSS本家サイト
hiloki/flocss: CSS organization methodology.
FLOCSSのカスタマイズ事例も公開されていましたので、こちらをベースとしました。
styleguide/css-coding-rule.md at master · manabuyasuda/styleguide
ファイル・ディレクトリ構成は以下の通りとしました。なお、Sassを使用しています。
(root) |-- foundation/ | |-- base/ | |-- function/ | |-- keyframes/ | |-- mixin/ | |-- variable/ | |-- vendor/ | `-- vendor-extension/ |-- layout/ `-- object/ |-- component/ |-- project/ |-- scope/ `-- utility/
FLOCSSは次の3つのレイヤーと、Objectレイヤーの子レイヤーで構成されます。
1. Foundation - プロジェクトにおける基本的なスタイル 2. Layout - ページを構成するコンテナーブロックのスタイル 3. Object - プロジェクトにおけるビジュアルパターン 3.1 Component - 小さな単位のモジュール 3.2 Project - プロジェクト固有のパターン 3.3 Utility - 便利クラス、汎用クラスなど
今回のプロジェクトでは、前述した構成にあるようにFoundationレイヤーに子レイヤーを追加しました。レイヤーというよりはグループに近いです。グループ化して構成をすっきりさせるのが狙いです。
1.1 Base - 要素セレクタと属性セレクタのデフォルトスタイル 1.2 Function - プロジェクト全体で使用される@function 1.3 Keyframes - プロジェクト全体で使用される@keyframes 1.4 Mixin - プロジェクト全体で使用される@mixin 1.5 Valiable - プロジェクト全体で使用される変数 1.6 Vendor - 外部のライブラリやフレームワーク 1.7 Vendor-Extension - Vendorレイヤーの上書き
また、Objectレイヤーにも子レイヤーを追加しました。ここではComponentやProjectのコンポーネント単位ではなく、それより大きな括りでのスタイルを定義します。ページ固有のスタイルもここで定義しました。
3.4 Scope - ページ内のスコープでのスタイル
カスケーディングについても少し触れたいと思います。カスケーディングはCSSの大きな特徴のひとつです。カスケーディングとは、ある要素のあるプロパティに対する宣言が複数あるときに、ひとつの宣言だけが有効になるようにする仕組みのことです。カスケーディングの管理が煩雑だとCSSが破綻していきます。FLOCSSにおいては、後ろのレイヤーになるほど抽象的なスタイルから具体的なスタイルになり、カスケーディングにおいて強いルールにする必要があります。
上記を踏まえ、レイヤーの読み込み順序は以下のようになっています。
@import "foundation/variable/"; @import "foundation/vendor/"; @import "foundation/vendor-extension/"; @import "foundation/base/"; @import "foundation/function/"; @import "foundation/mixin/"; @import "foundation/keyframes/"; @import "layout/"; @import "object/component/"; @import "object/project/"; @import "object/scope/"; @import "object/utility/";
命名規則について
命名規則はFLOCSSの規約に従って、BEMをベースにしたMindBEMding を採用しました。BEMは、Block、Element、Modifierという3つの概念で構成されます。BEMを使用すると、命名ルールが統一され、HTMLを見ただけでBlockの範囲をとらえることが容易になります。また、再利用性、拡張性も向上し、開発のしやすさ、メンテナンスのしやすさにもつながります。
Objectレイヤーのモジュールに対しては、役割の明確化と名前の重複を避けるために以下の接頭辞を付与しました。
- Component – `.c-*`
- Project – `.p-*`
- Scope – `.s-*`
- Utility – `u-*`
FLOCSSではマルチクラスパターンを基本としていますが、今回の開発ではシングルクラスを基本としました。マルチクラスとシングルクラスの違いを簡潔に言うと、部品の組み合わせをHTML側で行なうかCSS側で行なうかの違いです。シングルクラスを採用した理由は、開発メンバーはオブジェクト指向でのプログラム開発に慣れており、Sassの@extendを使用したシングルクラスの方が馴染みやすくコーディングしやすかったためです。
シングルクラスの例を挙げると以下のようになります。
.button { display: inline-block; cursor: pointer; } .button--primary { @extend .button; background-color: #CCAA00; } .button--secondary { @extend .button; background-color: #FFCC00; }
BEMを使用すると、子要素が多い場合にElementが複数になることがあり、マークアップの仕方にバラつきが出ることがあります。
今回はバラつきを避けるために以下のようなルールを追加してマークアップしました。
<ul class="nav"> <li class="nav__item"> <ul class="nav__item-items"> <!-- 3単語で区切る場合 --> <li class="nav__item-items-item"> <!-- ここから子孫として新Blockにします。 --> <a href="#" class="link"></a> </li> <li class="nav__item-items-item"> <a href="#" class="link"></a> </li> </ul> </li> <li class="nav__item"> <!-- 2単語で区切る場合 --> <ul class="nav__item-items"> <!-- ここから子孫として新Blockにします。 --> <li class="item"> <!-- 新Blockに対してBEMでElementを追加します。 --> <a href="#" class="item__link"></a> </li> <li class="item"> <a href="#" class="item__link"></a> </li> </ul> </li> </ul>
- .nav__itemの子要素は.nav__item-items、.nav__item-items-itemのようにBlock__Elementの後に-を区切りとしてElementを追加していきます。
- Element名自体に-が含まれる場合も、Element区切りの-との区別は設けません。
- ElementはBlockのスコープから飛び出してはいけません。
- Element名は3単語までとします。それ以上の入れ子となる場合は、ブロックをリセットして子孫とします。
- 3単語で区切る際に3単語目がBlockになってしまう場合は2単語でBlockをリセットします。
Sassは以下のようになります。
// 3単語で区切る場合 .nav { &__item { } &__item-items { } &__item-items-item { // ここで親Blockをスペース区切りで指定して、子孫として新Blockにします。 // 子Block名は親Block内でユニークであれば任意の値で問題ありません。 & .link { } } } // 2単語で区切る場合 .nav { &__item { } &__item-items { // ここで親Blockをスペース区切りで指定して、子孫として新Blockにします。 // 子Block名は親Block内でユニークであれば任意の値で問題ありません。 & .item { // 新Blockに対してBEMでElementを追加します。 &__link { } } } }
上記の場合、CSSは以下のようになります。
// 3単語で区切る場合 .nav {} .nav__item {} .nav__item-items {} .nav__item-items-item .link {} // 2単語で区切る場合 .nav {} .nav__item {} .nav__item-items {} .nav__item-items .item {} .nav__item-items .item__link {}
プロパティの宣言順
CSSのルールセット内のプロパティの宣言は、機能ごとにまとめて記述することでCSSの可読性が上がると思います。例えば、表示方法に関するプロパティ(display, visibility など)、位置に関するプロパティ(position, z-index など)、フォントに関するプロパティ(font-size, line-height など)などのことです。
ただ、これらの宣言順序を各開発メンバーが意識しながらコーディングするのでは効率が悪いので、CSSのプロパティを自動で並べ替えしてくれる CSScomb というツールを使用して、開発メンバー間で同じような記述となるようにしました。
開発メンバーが使用していたエディター(IDE)は、Atom、PhpStorm、NetBeans、VisualStudioCodeとバラバラでしたが、どのエディターにもCSScombのプラグインは提供されていました。蛇足ですが、私は Eclipse -> NetBeans -> VisualStudioCode とエディターを乗り換えて今に至りますが、キーバインディングはEclipseのものをずっと使用しています。操作感を特に変えずにエディターを変更できるのは良いですよね。
いま現在は、VisualStudioCodeを利用しているメンバーが多くなってきています。その理由は、TypeScript言語での開発をメインで行っており、その点においてほかのエディターと比べて秀でていると感じたためです。(感想には個人差があります)
エンジニアとデザイナーの思考の違い
本筋から外れますが、今回SPAの開発を行なうにあたり、デザイナー(非エンジニア)とエンジニアが協働してデザイン・UI/UXを作り上げ、ともにHTML/CSSコーディングを行ないました。その際に感じた点を少しお伝えしたいと思います。
我々エンジニアは「ボタン」や「入力ボックス」などの最小単位の部品(オブジェクト指向で言うオブジェクト)から考える傾向にあります。それとは逆にデザイナーは全体のレイアウトを考えてから内部の部品を考える方が多いのではないでしょうか。
そのため、エンジニアがコーディングを行なう際に「あの画面とこの画面で微妙にデザインが違う!同じにして!」というのはよくあると思います。もちろん明確な理由があってデザインを変えているケースはあると思いますが、エンジニアにとってはできるだけ共通の部品を使用してコード量を減らしたいですよね。
この思考に違いについては、デザイナーにもFLOCSSでHTML/CSSコーディングを行なってもらいオブジェクト指向の考え方を理解してもらうことで、隔たりを埋められたと思っています。念のためお断りしておくと、一方的にエンジニアの思考を押し付けたわけではありません。我々エンジニアも類似サービスの調査等を通してUI/UX設計について理解を深める努力をしました。デザインに関して疑問が生じた際は、そのようにした理由・経緯をデザイナーから説明してもらいエンジニアが納得したうえで進めるようにしました。お互いの思考を理解しあって歩み寄ることも必要だと思います。
まとめと予告
今回はCSS規約やSassによるコーディングの実例について、ごく一部ではありますが、書かせていただきました。
次回はSassコーディングを行なう上で必要となる各種自動化の話について紹介させていただきたいと思います。
引用元・出典
hiloki/flocss: CSS organization methodology.
styleguide/css-styleguide.md at master · manabuyasuda/styleguide
styleguide/css-coding-rule.md at master · manabuyasuda/styleguide
フロントエンドエンジニアへの道
1- HTML/CSSコーディングはじめるぞ〜HTML/CSSコーディングを行なうにあたっての事前準備
2- チーム作業をするための最適なCSS規約、Sassについて考えた
3- Sassコーディングを行なう上で必要となる各種自動化の話
4- Angular1によるSPA開発 – 基本編
5- Angular1によるSPA開発 – 設計編
6- Angular1によるSPA開発 – Tips編
HTML/CSSコーディングはじめるぞ〜HTML/CSSコーディングを行なうにあたっての事前準備
いま現在、HTML5/CSS3/Angular1を使ったシングルページアプリケーション(SPA)の開発を行なっています(自社サービスとして近日中にローンチ予定です)。
私はプレーイングマネージャーとして、このSPA開発に携わっており、開発環境・インフラ周りも担当しています。
もちろん、コーディングも行ないます。
開発チームは私を含めて4人体制ですが、チーム発足当初、我々にはフロントエンドエンジニアとしてのスキルが不足していました。そこで、フロントエンドエンジニアとなるべく奮闘が始まったのですが、開発の過程で感じたこと、苦労した点などを、今回から数回にわたって紹介していきたいと思います。
まず、フロントエンドエンジニアとは?何をする人たちなのか
フロントエンドエンジニアとは?と聞かれたあなたはどう答えるでしょうか。
フロントエンジニアの定義は各社によって異なると思いますが、当社では「HTML/CSS/JavaScriptのコーディングだけでなく、UI/UXの設計、フレームワークやライブラリの選定、API等のサーバーサイドのプログラミングも含めて、WEBサイトの制作ができる人」と定義しています。
このような考え方の会社さんが多いのではないでしょうか。
開発チームでは、これまでにWEBサイトの制作をいくつも行なってきましたが、モダンなサイトにしたい場合は、デザイン(見た目)とHTML/CSSのコーディングを外部業者に委託していました。
しかし、今回自社サービスを立ち上げるにあたり「デザインもコーディングもすべて自社でやろう!フロントエンドエンジニアになろう!」というミッションのもと、開発を進めることになったのです。
デザイン/CSSを外注していたことから、我々開発チームにはデザイン/CSSの知識が不足していました。
また、SPAの開発を行なう上では、ブラウザー側でのコンポーネントの管理やルーティングなどの処理も必要となるため、JavaScriptの知識もこれまで以上に必要となります。
各メンバーにはjQuery/Ajaxでの開発経験がありましたので、jQueryでSPAを実装するのも一案でしたが、かなりの労力がかかることが想定されたため(もちろんjQueryで事足りるケースもあると思います)、SPAフレームワークも導入することにしました。
このような状況では「私たちはフロントエンドエンジニアです」とはとても言えません。 ここからフロントエンドエンジニアへの道のりが始まります。
HTML5/CSS3の基礎知識を身につける〜すぐにできたことはこれだ!
これまでにもWEBサイトの制作は行なっていましたので、HTMLは書くことができますし、CSSもある程度は読み書きすることができました。
しかし、HTMLの知識はHTML4がベースとなっており、HTML5/CSS3についてはきちんと学習したことがなかったため、オンラインの学習サービスと書籍を併用し、HTML5/CSS3の学習を行ないました。学習期間は3日程度でした。
書籍は以下を利用しました。参考までに。
これらの学習が終わったら「習うより慣れろ! 実際にコーディングを始めよう!」・・・とはいきません。
CSSの規約の策定が必要でした。
CSS規約をつくるために考えたこと
CSSのコーディングを始める前に、最低限以下の事項(項目)を決定する必要があります。
– マルチクラスにするかシングルクラスにするか?
– クラスの命名規則をどうするか?
これらは、CSSの設計方法(方法論)として各種提唱されており、OOCSS、BEM、SMACSS、FLOCSS、ITCSS などが有名かと思います。わかりやすさ(初心者にとっての開発しやすさ)が重要だったり、メンテナンス性が重要だったりと、ケースによって重視するポイントは異なってくると思いますので、どれが正解でなにが優れていると、一概に言えるものではありません。
サイトやチームの特性を考慮したうえで、それに適した方法論を採用することになると思います。
我々のチームでは、FLOCSSをベースとして一部をカスタマイズする形式をとりました。その内容については、次回ご紹介したいと思います。
hiloki/flocss: CSS organization methodology.
– CSSプリプロセッサー(Sass や Less)を導入するか? 導入するとコーディングの効率化、簡略化が見込めます。
我々のチームでは、導入以外の選択肢はありませんでした。
全員エンジニアなので導入の敷居が低かったこともありますが、エンジニアは少しでも楽をしたいと常日頃思っていますからね。
実際にCSSコーディングを行ない、CSS規約をブラッシュアップする
CSS規約ができたら、実際に規約に従ってサンプルページのコーディングを行なってみました。
実際にコーディングを行なってみると、改善すべき点や追加すべき規約も浮き彫りになってきますので、規約をブラッシュアップしていくことになります。
テキストボックスやボタンなど、共通的に使用可能なスタイルは部品化する。
さらに、部品化したスタイルについて、使い方やマークアップ例をスタイルガイドにまとめます。
今回は「sc5-styleguide」というスタイルガイドジェネレーターを使用しました。
CSSファイルに所定の形式でコメントを記述すると、自動でスタイルガイドを生成してくれるので、重宝しました。
また、CSSの規約だけではなく、HTMLに関する規約も追加する必要が出てくることがあります。
たとえば、
・フォームのボタンには<button>タグもしくは<input type=”button” />タグを使用します。
・<a>タグは不可(disabledが効かないため)。
などです。
今回はCSSコーディングを行なうにあたっての事前準備について書かせていただきました。
次回はCSS規約の実例について紹介させていただきたいと思います。
フロントエンドエンジニアへの道
1- HTML/CSSコーディングはじめるぞ〜HTML/CSSコーディングを行なうにあたっての事前準備
2- チーム作業をするための最適なCSS規約、Sassについて考えた
3- Sassコーディングを行なう上で必要となる各種自動化の話
4- Angular1によるSPA開発 – 基本編
5- Angular1によるSPA開発 – 設計編
6- Angular1によるSPA開発 – Tips編