【プロジェクト概要】ECサイトフロントエンドCSS全体のアーキテクチャ設計(1)_html/css_WEB-ITnose

最近私はアウトソーシングのウェブサイトを書くのに半分忙しいです。ウェブサイトの主な機能はアートの入札とアートの派生商品の販売です。現在、プロジェクトの約 80% が完了し、フロントエンドとバックエンドのコード量は約 50 万行に達しています。私は主にフロントエンドの設計とフロントエンドのレイアウトを担当しています。先にWebサイトのデザイン画を載せておきます、甲の「商業秘密」に関わるのでモザイクをかけておきます:

この記事は主に今回のプロジェクトや今回の段階についてのまとめです。私が読んだいくつかのフロントエンドの本や私の経験なので、あまり多くの設計図は投稿しません。プロジェクト全体のデザイン画は、初期 UI でホームページのドラフトの雰囲気を決定しました。残りのインターフェイスのほとんどは、ホームページのドラフトに基づいて作成されました。これについては、機会があればお話しします。 PS: ただし、ブログ ガーデンには、js に加えて、フロントエンドの記事が「コピー アンド ペースト」されたソース コードの記事でいっぱいになっています。未来。

ウェブサイト全体にはすでに 3,40 個の単一インターフェイス (バックエンドを除く) があり、10 個を超える CSS ファイルが蓄積されています (これについては後ほど詳しく説明します。これが私のプロジェクトで最も失敗した部分です)。このブログを書いています）。

それぞれの質問について私の理解を一つずつ話していきます。もし何か間違っていることがあれば、交換を歓迎します:

1. CSS の構造は何ですか?なぜ建築をするのか？

小規模なブログ Web サイトや小規模な CMS を構築している場合は、CSS ファイルの数が非常に少なく、インターフェイスの数も合計 10 未満であるため、多くの場合 CSS アーキテクチャを考慮する必要はありません。 CSS ファイルをシールするだけでは、大量の作業は必要ありません。ただし、数十または数百のインターフェイスを備えた大規模な Web サイトに切り替える場合は、CSS アーキテクチャが非常に必要になります。さらに、優れたアーキテクチャはチームの共同開発に役立ちます。インターフェイスが 3 つあり、1 人あたり 12 個以上あるとは言えません。非効率すぎてスタイルの競合が発生しやすく、スタイルが上書きされてしまう可能性があるため、全員が一生懸命にコードを書き終えました。その後、バックエンドが統合された後、スタイルがすべて混乱していることが判明しました。変更には数日かかり、書くよりも時間がかかりました。

適切な CSS 構造は、開発者がコードの量を削減し、共同開発プロセス中にフロントエンド開発チームがより良く連携できるようにするのに役立ちます。同時に、フロントエンドの全体的な構造を最適化することもできます。適切な CSS アーキテクチャにより、CSS ファイルの数と CSS ファイルの合計サイズが削減され、サーバーへのアクセス負荷が軽減されます。

フロントエンドコードの再利用を大幅に改善し、コードのメンテナンスコストを削減することもできます。インターフェースを 1 時間ごとに変更したいという種類の当事者にとって、適切な CSS 構造を持たないのはおかしいでしょう。たとえば、各ページにタイトル バーがあり、各ページが個別の CSS であるとします。ある日突然、パーティー A の Shen Jingbing が「スタイルを変更したい」と言いました。現時点では、選択肢は 2 つだけです。ハグ 2. 静かにコンピュータの電源を入れ、インターフェイスごとに変更を開始します。ここを見て、開発経験のある多くの同志なら、このタイトル部分を抽出して統一CSSファイルに記述し、各インターフェースで参照するだけで済むことが分かるはずです。それ。 。これは最も単純なモジュール化ですが、モジュール化プロセス中に注意する必要がある問題がまだ多くあります。 1. たとえば、3 つのインターフェイスにはタイトル バーがありますが、3 つのインターフェイスの要件が異なる場合はどうすればよいですか。タイトルバーのフォントの色は？上限証拠金要件と下限証拠金要件が異なる場合はどうすればよいですか? 2. 突然タイトルバーが表示されましたが、タイトルバーに追加の背景画像が表示されました。これを解決するにはどうすればよいですか?さらに面倒なのは、タイトルバーに追加の

タブを配置する方法です。モジュール間の差異を解決するというこの問題は、確かに注意深く研究する価値があります。

通常の CSS アーキテクチャ、つまり現在の Web サイトの CSS フレームワークには、ブラウザーのデフォルト スタイルの上書きとリセット、Web サイトの内部モジュールの抽出と抽象化、CSS コード仕様の合意、競合の解決などの機能が含まれています。プロジェクトがブートストラップや yui などの他の成熟したフレームワークを参照している場合、競合することなくスタイルを実装できるように、これらのフレームワークを自分で作成したフレームワークからどのように分離すればよいでしょうか?あとでゆっくり話してください。

CSS 構造を作成する方法、または単純な CSS 構造を実装する方法?

答え：コードを書きましょう！

2. CSS アーキテクチャはどこから始めますか?

プロジェクトを始める前に、設計図を見てすぐに作業を始めるのではなく、まずそれをどのように書くかを考えるべきです。私たちの教師がよく私たちに言うのと同じように、「コードしか書けないなら、あなたはただの平凡なプログラマーです。良いアーキテクチャを作ったり、プロジェクトの開発方法をアレンジしたりできる人がハイエンドのプログラマーです。平凡なプログラマー プログラマーはできる」バナナだけを食べますが、ハイエンドのプログラマーはパイナップルやリンゴなどを食べることもあります。」書き始めると、インターフェイス モジュールのスタイルをコピーして貼り付けたり書き直したりする繰り返し作業を何度も行っていることに気づくでしょう。あるいは、「クソ…スタイルが矛盾している」ということに気づくでしょう。または、書いているうちに自分の書いた内容が間違っていることに気づき、戻って変更したくなり、ファイルを 1 つずつ変更し始める... このような構造のない不器用な CSS の書き方以前書いたプロジェクトはこんな感じで、20個以上のインターフェースを変更して、気が狂いそうになりました…

プロジェクトを始める前に。少なくとも、CSS ファイルがいくつあるか、どの CSS ファイルを最初に修正バージョンで書き出す必要があるか、どの CSS コードが大量に再利用される可能性があるか、どの CSS ファイルが大規模な処理を受ける可能性があるかを考慮する必要があります。スケールが変わります。次に、これらの CSS の詳細な要件に従って最初のバージョンの作成を開始します。

たとえば、上に投稿したスクリーンショットでは、最も直感的なヘッダーバー: はどのインターフェースでも同じです。もちろん、これを実現するためにバックエンドで分散ビュー レイアウトを使用することもできますが、インターフェイス フロントエンド実装の初期段階では、この html、css、および js の部分も抽出する必要があります。そうすることで、バックエンドが最終的に統合されたときに? より高速な場合もあります。クリスマスの場合は、顧客が上記の背景色を青に変更するように指示するため、header.css にアクセスしてスタイルを変更するだけで済み、「手動作業」を行う必要はありません。はい。

したがって、CSS フロントエンド アーキテクチャを設計する最初の方法は、 リージョンに従って分割することです。

ページ内の要素やモジュールの地域的な配置に基づいて、Web サイトはヘッダー、フッター、サイドバー、スローガンなどの多くの領域に分割できます。これらの領域を個別に配置することで、各領域の分散ビューの分割を効果的に実現できます。 has 抽出後は、新しいインターフェイスを作成するときに、その中で共同作業するだけで済みます。私の記憶が正しければ、これはyuiがやったことです。

このオークションサイトのcssはheader.cssとfooter.cssファイルに分けるのは少し冗長だと思うので、CSSファイルの数が増えてコード行数も増えてしまうので、別途抽出しませんでした。各ファイルの数は非常に少ないです。これは特定のコードによって異なります。フッター スタイルに数十行が含まれる場合は、ファイルに分割します。ということで、一般的なCSSファイル：layout.cssの中に、実際にエリア：に沿って書いてみます。下部のナビゲーション スタイルを変更したい場合は、layout.css に移動し、下に検索して変更します。

しかし、インターフェイスを分割した後、ログインボックス、テーブル、テキストボックスなど、繰り返し現れるコードがまだたくさんあることが判明したため、それらを分割する2番目の方法がありました。関数に分割します。

機能による分割とは、インターフェース内の要素の機能に注目し、フォント、カラー、ボタン、フォームなどの特定の機能に従って、同じ機能を持つ要素とモジュールを抽出することです。これは多くの人が採用するはずです。たとえば、これが私のブートストラップの動作です。明らかに、これらはすべて機能モジュールです。すべて統合され圧縮された .css は、実際にはまだ次の構造を内部に持っています。

機能ごとに分割するのは非常にクールです。なぜなら、各機能分割に統一されたプレフィックスを追加でき、コードを記述することができるからです。コードプロンプトを備えたコンパイラは非常に高速です。エリアごとに分かれていると、「あれ、フッターのCSS名は何だったっけ？あ、Xiao Wangが書いたサイドバーのクラス名は何だったんだろう？」とちょっと辛いこともあります。

このプロジェクトのコードでは、実際には最初のメソッドと 2 番目のメソッドの混合モードを使用しました。CSS ファイルの最後のスクリーンショットからわかるように、抽象化した繰り返し領域モジュールのコードを追加しただけではありません。また、コードの再利用性を高めるために、サイドバーやマスクなどの機能モジュールを抽象化して整理しました。

自分のプロジェクトの構造は良いと思っていましたが、書いていくうちに無駄な作業をしていることが多くなり、だんだんイライラしてきました。私が犯した愚かな間違い:

1. モジュールの抽象化には制限があります。たとえば、フォームに特別な要素が欠けている場合、最初に作成したモジュールは使用できなくなり、最初から作成する必要があります。

2. モジュールの抽象化が不完全です。モジュールの抽象化がほぼ完了したと思ったときに、全力で書き始めました。書いているうちに、いくつかのモジュールが忘れられていることに気づき、多くのモジュールを何度も手書きする必要がありました。

3. cssのクラス名が統一されていないのは、結局のところ、モジュールがうまく分割されていないということです。これまで、この Web サイトに名前を付けるには言葉が足りませんでした。ショッピング カートに追加、お気に入りリストに追加、ショッピング カートの表示、支払いの確認、確認注文への記入、固定価格での支払いなど、多くのインターフェイスがあります。英語の基礎が十分にないので、なんとも悪夢です... したがって、中国語の名前を翻訳して、キャメルケースの命名方法である AddCart を使用することしかできません。実際、キャメル ケースの名前付け方法の最大の利点は、他のことを考慮せずに非常に直感的に名前を付けることができることですが、キャメル ケースの名前付け方法は、サブクラスに長い単語を次々と名前を付けるときにさらに面倒になります。 ...別の命名方法の 1 つは、トラブルを避けるために、ダッシュ add_cart の代わりにアンダースコアを直接使用することです。これについては、次の数章で説明します。

---------------以下----------------この記事の核心です---------- -

以下はこの記事の【核心】です T^T の最近のプロジェクトの妨害と書きかけの状況についての私の悲しい反省でもあるので、フロントエンドのコード仕様と Web サイトのフロントエンド開発をいくつか読みました。この本を要約し、新しい構造手法を発見しました。読み終わった後、とても気分が悪くなりました。この本「高品質なコードの書き方 - Web フロントエンド開発の実践方法」をお勧めします

もう 1 つの推奨される CSS アーキテクチャ方法は、インターフェイスの機能に応じて分割することです。ここでは、Web サイトのフロントエンド全体がソフトウェアに抽象化されています。またはプロジェクトの場合、この時点で考慮しなければならないのは、プロジェクトの最下層とは何か、そしてプロジェクトのプレゼンテーション層とは何かということです。よく言われる MVC の考え方と同様、フロントエンド アーキテクチャです。も mvc と同じように分割されており、すべての css ファイルは 3 つのクラスに要約できます:

1. 基本クラス 2. 共通クラス 3. ページクラス

これら 3 つのカテゴリは、地域アーキテクチャと機能アーキテクチャのように並列して動作するモデルではありません代わりに、基本クラスを最下層として使用し、層ごとに影響を与え、カスケード効果を与えます。

実際、このピラミッド構造と同様に、各クラスの機能を以下に詳しく紹介します。

[1.base class]

名前のとおり、base は、CSS アーキテクチャ全体の最も基本的な部分です。ブラウザのデフォルト スタイルのリセットと基本的な機能の実装を提供します。 Base での基本的な関数の実装に関しては、主に、非常に小さなスコープと高度な抽象化を伴うアトミック レベルの関数クラスの実装を指します。たとえば、最も一般的な .f12{font-size:12px;}、.mt30{margin-top:30px;} の各アトミック クラスは 1 つの関数の実装のみを担当し、特定のページ UI にはまったく関与しません。いくつかの層がアトミック機能を提供し、特定のモジュールの実装はこれらのアトミック クラスを組み合わせることによって実現されます。もちろん、基本クラスはブラウザのデフォルト スタイルのリセットも担当します。現在、多くの Web サイトの は太字ではないため、これをリセット セクションに記述する必要があります。あらかじめ。

基本クラスは CSS アーキテクチャ全体の基盤です。すべてのインターフェイスはファイル全体を参照します。これにより、このファイルの要件が次のように規定されます。 1. ファイル サイズは大きすぎてはいけません。2. ファイルは信頼性が高くなければなりません。 3. 作成後は、メンテナンスの頻度を最小限にするか、メンテナンスを避けるようにしてください。さらに、基本クラスは特定の UI スタイルを含まず、移植性が高いため、さまざまな Web サイトの基本クラスを共有できます。

具体的なベースファイルが何かを追跡します、これについては次回に話します、今日は時間がありません。

[2.common class]

css基本クラスを使用して実装された基本モジュールのcssファイルであるcommonクラスは、インターフェース全体からテキスト、マージン、色などのアトミックエンジニアリングを抽出しました。現在の Web サイト用にカスタマイズされたモジュールが必要です。

デザイン原則の「統一原則」では、同じウェブサイトは一貫したスタイルを維持する必要があります。リストページに入ると、ハイライト、ハイライトのWeb2.0スタイルのページになります。シャドウとクールなフラッシュ。したがって、ほとんどの場合、同じ Web サイト内の検索ボックス、テキスト ボックス、ボタン、リストは同じスタイルを持つため、これらの繰り返しモジュールを MVC と同様の共通クラスに抽出する機会が得られます。内部のモデルも次のとおりです。上で説明したアーキテクチャ機能部門の特定の機能ファイルと同様です。可能な限り再利用性と柔軟な使用を確保するには、これらのモジュールを完全にカプセル化する必要があります。

2つの方法を考えました。1つは、LESSなどの言語を使用してスタイルインターフェイスをモジュールに予約し、設定ファイルを直接変更して、CSSファイルを動的に出力する方法です。 2. bgcolor や border などのモジュールの UI 属性を最小限に抑えます。これらは空白のままにすることができ、実際の使用時に必要に応じてアトミック クラスと組み合わせることができます。ただし、このメソッドにはアトミック クラスの要件があり、ベース ファイルに影響を与える可能性があるため、私は自分で「分子クラス」という言葉を作りました。これは明らかに、モジュールに大規模なアトミック クラスのカスタマイズを提供し、各モジュールの専用の項目をカスタマイズします。クラスと共通レイヤーは、モジュール スタイルをカスタマイズする必要がある場合にのみ相互に組み合わせる必要があります。次の記事で実証するものを書きます。

[3.pageクラス]

pageクラスは、写真からもわかるようにピラミッドの頂点にあり、その動作範囲も最も小さく、つまり、すべてのページに1つのcssではなく、すべてのページです。ページですが、それは正しいです。ページ クラスは、ページ レベルのスタイルを提供する責任があります。ページ CSS はいくつかの厄介な問題を引き起こす可能性があります。 1. ページが多すぎるため、ページ CSS の単一ファイルが多すぎます。各ファイルは http リクエストです。サーバーはそれに耐えることができますか。 2. ページCSSの数を減らすために、1つのpage.cssに統合しましたが、名前はどうすればよいですか？たとえば、.part、.one、.main、.theme... 頻繁に発生するクラス名のマージ競合をどうすればよいでしょうか?

２番目の問題は、命名範囲を制限することで解決できます。

最初の質問については、単一の css ファイルをマージできます。その後、2 番目の質問の答えを見ることができます。

分散ビュー、実際にはページ全体がいくつかの小さなインターフェイスで構成されているため、競合を回避するにはどうすればよいでしょうか?スタイルの上書きを回避するにはどうすればよいですか?それについては後で詳しく説明します。

_(:з ∠)_文字数が多くて疲れたので、今日はこれだけ書きます。次の記事でお会いしましょう~~ [私とコミュニケーションをとり、マスターに文句を言わずにいくつかの推論を持ってくるように依頼してください...]

次の記事では、ベースの CSS ファイルと私自身の再構築について詳しく話しますプロジェクトのCSS。最後に、私が言いたいのは↓↓