多くのフロントランナーになじみのある痛み。 古い機能を複製する新しい要素の外観。 ラジオボタンの外観、リンクの新しい色、新しいページごとのインデントがわずかに変更されました。 通常、この問題は、新しいデザイナーの出現、チーフデザイナーの変更、またはデザイナーの不在により悪化します。
問題の結果：新しいページの作成に不必要に多くの時間が費やされます。 サイトの整合性が失われます。 スタイルシートとコードは成長しています。
通常、このような問題は、プロジェクトが既に十分に大きい移行期間中に発生しますが、設計部門はまだ形成されていません。
どうする
実用的なフロントエンド開発者としての直接的な責任は、製品の整合性を維持し、冗長性を防ぐことです。 結局のところ、誰もがこれから恩恵を受けます：
- サイト要素の均一性に慣れているエンドユーザー
- 設計者は、新しい要素を発明する必要をなくしました
- フロントエンド自体、既製のコンポーネントから新しいページを作成する速度の素晴らしいガイド
この相乗効果は、以下の3つの原則に従うことで達成されます。
1.すべてを表示
ほとんどの場合、設計者は、そのようなボタンがアクセスできないために、電子メールアドレスの確認ページに既にあることを単に知りません。 サイトの利用可能な機能要素を1か所に表示すると便利です。 そのため、このコレクションを最新の状態に保つのは可能な限り簡単です。 そして、ここにコンポーネントのライブラリがあります。 「スタイルガイド」または「パターンライブラリ」とも呼ばれます。 現時点では、スタイルガイド生成ツールの膨大な選択があり、このトピックに関する多くの記事が書かれています。
Githubユーザーであり、同時にJekyll Styleguideの著者であるDavid Handは、既存のコンポーネントライブラリジェネレーターを分類しようとしました。 このページでは、利用可能なツールのリストを見つけることができます。
2.コンポーネントライブラリを最新の状態に保つ
コンポーネントライブラリの各要素は、最新の状態に保つための努力を必要とするコードを使用するための別のオプションです。 リリース後にスタイルガイドのコンポーネントを更新する誘惑は非常に高くなります。 ただし、コンポーネントライブラリは、リリースプロセスの不可欠な部分であるドキュメントとして扱う方が適切です。
スタイルガイドにコンポーネントを保存する方法により、2種類のジェネレーターを区別できます。
1.コンポーネントはスタイルシートで表されます。
+メンテナンスが簡単：スタイルを変更し、同じファイルのコメントを変更しました。
-強調表示やIDEサポートがないためなど、大きな例では不便
このタイプの利用可能なジェネレーターのかなり大きなリストを以下に示します。
2.要素は個別のファイルに保存されます
+ IDEのすべての楽しみ、サンプルの追加と保存の自由
-サポートが必要な別のファイル
ライブラリの例： Fractal 、 Pattern Lab on Node 、 Fabricator
3.新しいコンポーネントよりも現在のコンポーネントの改善を優先する
あなたは、利用可能なコンポーネントの再活性化に最も時間を費やした人として、通常、そのリスト、機能、および欠点を知っています。 デザイナーと協力して、既存の機能を改善します。 デザイナーとの対話の例：
-こんにちは、見て、私たちはすでに同様のラジオ要素を持っています。 http：//アドレス-スタイルガイド/洗練された-radiobox.html
-はい、知っていますが、影や説明文がないため、新しいページには適していません
-したがって、現在のアイテムは十分ではありません。 影とオプションの説明テキストを追加して改善しないのはなぜですか？
-確かに、やろう
最後に
数年にわたるスタイルガイドの使用の結果として現れた私の経験： コンポーネントライブラリを共有したいと思います。 以下は、Habrコンポーネントに基づいた使用例です 。
コンポーネントライブラリの膨大な選択にもかかわらず、コンポーネントライブラリは多くのツールの利点を兼ね備えています。
- 現在のシステムへの信じられないほど簡単な統合。 フロントエンドアセンブリプロセスがある場合、コンポーネントライブラリはいずれかの段階で簡単に実装できます。
- ウェブサイト自体の矛盾のないスタイルとスクリプト
- サポートのしやすさ。 各コンポーネントは個別のHTMLファイルであり、コンポーネントの一般リストと個別のページの両方で利用可能です