Salesforce Lightning Design System について
こんにちは、三宅です。
今回は、Salesforce Lightning Design System (SLDS) について、フロントエンドエンジニアの視点から掘り下げてみたいと思います。
その前に、少し SLDS についての説明を。
Salesforce は 8 月末に、Lightning Experience を発表しました。
Lightning Experience は、Salesforce1 プラットフォーム上でモバイルアプリケーショをコンポーネントベースの UI で構築できる Salesforce1 Lightning Framework をデスクトップの Web ブラウザまで拡張したものと言えます。
10 月の Winter '16 のリリースで利用できるようになり、モダンで Salesforce1 モバイルアプリのデザインと一貫性のあるデスクトップ UI となるようです。
SLDS は、Lightning Experience のユーザインタフェースにマッチしたアプリケーションを開発する際に利用できる CSS フレームワークです。
Force.com では Visualforce や Force.com Canvas を用いて独自の UI を持つアプリケーションを開発することができます。
従来は CSS フレームワークを使うにせよ、独自に CSS を記述するにせよ、Salesforce 自身の CSS との衝突に気をつける必要があったり、デスクトップとモバイルでプラットフォーム自体のデザインが異なる中で両者で違和感のないデザインとしなければいけないなどの苦労がありました。
Lightning Experience と SLDS でそういった苦労が解消され、より容易にユーザにとって統一感のあるデザインのアプリケーションを開発することが可能となるでしょう。
Pure CSS フレームワーク
有名どころの CSS フレームワークとして、Bootstrap、Material-UI、Pure などが挙げられます。
SLDS は Pure と同様に、CSS のみで実装されたフレームワークとなります。
Bootstrap や Material-UI は JavaScript も含んだフレームワークで、CSS ファイルと Script ファイルを読み込むだけで簡単にモーダルダイアログやドロップダウンメニューなどのインタラクティブなコンポーネントを利用することができます。
SLDS にもモーダルダイアログなどのコンポーネントは用意されていますが、それをユーザのアクションに表示するなどの処理は自分で実装する必要があり、Bootstrap などと比較して利用する際に少し手間がかかります。
しかし、JavaScript フレームワークとともに利用する際に、CSS のみのフレームワークであることは有利に働きます。
AngularJS や React 上で Bootstrap を利用しようとすると jQuery による DOM 操作の部分が JavaScript フレームワークと競合し、Bootstrap の実装を参考に自分で実装する必要であったり、Material-UI ではそもそも React の利用が前提となっていたりします。
シングルページアプリケーションなど複雑なフロントエンドアプリケーションを開発する際に、JavaScript フレームワークの制約がないこと、インタラクションを自分たちの実装で制御できることは大きな利点と言えるでしょう。
SASS を用いたカスタマイズ
SLDS のダウンロードには、CSS ファイルやアイコンなどのアセットに加え、SASS のソースコードが含まれています。
フレームワークで利用するカラーやフォントサイズ、スペースなどの値が、「/scss/design-tokens.scss」に全て変数として定義されています。
$color-brand: rgb(21, 137, 238) !default;
$color-brand-dark: rgb(0, 112, 210) !default;
$font-size-x-small: 0.625rem !default;
$font-size-small: 0.875rem !default;
$font-size-medium: 1rem !default;
$font-size-large: 1.25rem !default;
$font-size-x-large: 1.5rem !default;
$font-size-xx-large: 2rem !default;
上記は定義されている変数の抜粋です。
全ての変数は !default とともに定義されているため、SLDS の index.scss をインポートする前に任意の変数の値を定義することで、簡単にカスタマイズすることが可能です。
Salesforce コミュニティでは独自のブランドカラーを定義することができるため、それらのブランドカラーを適用した SLDS フレームワークをコンパイルすることができます。
ただ、全ての変数に直接値が定義されているため、一つ一つ値を設定する必要があります。Bootstrap のように、カラーパレットで一括で変更できるようになっていればよかったのですが。
コンポーネント志向
SLDS は徹底したコンポーネント志向に基づいて設計されています。
AngularJS や React、それに Web Components でも見られるように、コンポーネント化はフロントエンドの大きな流れです。
AngularJS や React は、JavaScript で UI コンポーネントの機能を定義し、それをアプリケーションの様々な箇所で再利用可能とするような思想に基づいて作られています。
そのようなフレームワークを利用する際に従来のページごとや特定のコンテナに依存した CSS の定義をしていると、重複したスタイル定義が発生したり外側のスタイル定義の影響を受けたりし、再利用性や保守性が大きく損なわれることとなります。
CSS にはネームスペースやスコープが存在しないため、命名規約などでコンポーネント志向の設計を行うこととなります。
SLDS では、BEM に似た設計に基づいてコンポーネントが定義されています。
Components > Cards を例に確認してみます。
.slds-card {
padding: 0;
border-radius: 0.25rem;
background-clip: padding-box;
background-color: #f4f6f9;
border: 1px solid #d8dde6;
}
.slds-card + .slds-card {
margin-top: 1rem;
}
.slds-card__header {
padding: 0.75rem 0.75rem 0.25rem;
}
.slds-card__body {
padding: 0.5rem 0;
}
.slds-card__footer {
padding: 0.25rem 1rem 0.5rem;
}
.slds-card .slds-tile {
margin: 0.5rem;
padding: 0.5rem;
}
.slds-card で Card コンポーネントの定義を行い、ヘッダやフッタなどのパーツを、.slds-card__header のように __ で続けて定義しています。
Card コンポーネントが内包するコンポーネントのカラーやフォントサイズなどの定義はここでは行われていません。
リンク先のマークアップのように、.slds-media や .slds-text-heading--label などのより具体的なコンポーネントを定義してスタイリングが行われています。
独自のデザインの Card を作りたい場合は、既存のコンポーネントを組み合わせたり、内包する新たなコンポーネントを定義します。
このような設計とすることで、アプリケーション全体のデザインの一貫性を保ちつつ、容易に拡張や修正が可能となります。
今回は、Salesforce Lightning Design System をフロントエンドエンジニアの観点で紹介してみました。
AngularJS や React などメジャーな JavaScript フレームワークの思想や、Web Components の仕様策定が進んでいることをみても、UI のコンポーネント化は今後さらに進んでいくことが予想されます。
特に CSS に関しては、これまでとは考え方を大きく変える必要が出てきます。
SLDS は Salesforce Experience の UI を容易にデザインできるツールであると同時に、コンポーネント志向に基づく CSS 設計のよいお手本であると言えます。
コンポーネント志向の CSS 設計に興味のあるデザイナやプログラマは、SLDS を使うだけでなく、どのように定義されているか実装を覗いてみるだけでも勉強になると思います。
のSalesforce/Force.com
コメント