3

Rails 3.1プロジェクトで大量の重複を避けるためにSassファイルを構築するのに本当に苦労しています...

次の構造があり、application.css.scss がメイン レイアウトの一部としてインポートされます。

application.css.scss
  - [*= require] main.css.scss
      - [@import] 'variables';
      - [@import]'bootstrap_overrides';
      - [@import]'bootstrap';
      - [@import]'base_elements';
      - [@import]'superstructure';
      - [@import]'modules';

ここまでは順調ですね。これらのファイルはすべて、スプロケットによって 1 つのドキュメントに結合されます。ただし、ページ固有のファイルまたはサイトのリージョン間で共有されるファイルを使用して、Sass をさらにモジュール化したいと考えています。

したがって、私の GalleryResource#show ページでは、追加の Sass ファイルを使用する必要があります。

resource.scss
gallery_resource.scss
badges.scss

そして多分libからのcssファイル：

gallery_lib.scss

これらのファイルは、application.css に既にインポートされている多数のファイルを参照する必要があります。variables.css.scss で定義された変数と、ブートストラップで定義されたミックスインを利用する必要があります。そのため、これらのファイルを使用する各ファイルでこれらのファイルを再インポートする必要があり、大量の重複が発生します。各ページごとにマニフェスト ファイルを作成することもできますが、これはメンテナンス上の悪夢であり、依然として重複と 2 つの css ファイルが発生します。application.css および page_specific.css。

それで、解決策は何ですか？application.css を削除して、そのインポートを各ページ固有のファイルに移動する必要がありますか? したがって、上記の例を使用すると、次のような単一のマニフェスト ファイルになります。

gallery_resource_manifest.css.scss
      - [*= require] gallery_lib.css
      - [*= require] gallery_resource.css.scss
         - [@import] 'variables';
         - [@import]'bootstrap_overrides';
         - [@import]'bootstrap';
         - [@import]'base_elements';
         - [@import]'superstructure';
         - [@import]'modules';
         - [@import]'resource';
         - [@import]'gallery_resource';
         - [@import]'gallery';
         - [@import]'badges';
4

2 に答える 2

9

私はまた、スタイルを整理するときにあなたが言及しているのと同じことをしようとしました。Railsは、コントローラーベースのスタイルシートを常に生成することで、ほぼこの方向に進んでいます。結局、私はすべてをに追加することを選択しましたapplication.sass。この方法の主な利点は、ページの読み込み時に1つのリクエストのみを行い、ユーザーが最後のページでリクエストしたコードを再インポートする必要がないことです。

私の個人的な意見では、CSSをうまく抽象化する場合、最初にスタイルシートに取り込むビュー固有のコードがあまりないため、1つのスタイルシートを使用するだけで済みます。いずれにせよ、代替案（前のページで同じことをしたかもしれないが、ページのニーズに基づいてモジュールをランダムにロードする）は、とにかくその問題を解決しているようには聞こえません。さらに、完全に新しいファイルに対してより多くのリクエストを行っています。

CSSは、整理するのが難しい場合があります。これは、通常、スタイルとスタイルシートディレクトリを整理する方法の例です。このメソッドは、単一の名前空間（アプリケーション）で機能するか、必要に応じて複数の名前空間（つまり、管理者、アプリケーション）で機能するように分割できます。

application.sass

// vendor ----------------------------------------------------------------------

// compass

@import "compass/reset"
@import "compass/css3/box-shadow"
@import "compass/css3/border-radius"
@import "compass/css3/box-sizing"
@import "compass/css3/opacity"
@import "compass/layout/sticky-footer"
@import "compass/utilities"

// grid

@import "susy"



// application -----------------------------------------------------------------


// base

// for mixins, variables and helpers to aid in building
// the application. no styling of actual elements should
// go in base.

@import "base/colors"
@import "base/fonts"
@import "base/mixins"
@import "base/grid"


// layout

// generic site styles. this includes site chrome styles
// such as the header, footer, flash messages, nav, as well
// as common patterns used around the site like forms, type,
// links, etc. the loose idea is that you could take these
// styles and create a similar "layout" but it wouldn't
// include contextual patterns like books, originals, etc.

@import "layout/buttons"
@import "layout/content"
@import "layout/header"
@import "layout/flash"
@import "layout/forms"
@import "layout/footer"
@import "layout/links"
@import "layout/tooltips"
@import "layout/typography"


// modules

// elements used on multiple pages that are loosely tied
// to our domain and data structure. examples are dependent
// on the needs of your site. as a general guideline, all 
// modules should be used on multiple pages. elements used 
// on a single page should be included in views.

@import "modules/articles"
@import "modules/buttons"
@import "modules/forms"
@import "modules/links"
@import "modules/pagination"
@import "modules/users"
@import "modules/stats"
@import "modules/some_other_domain_specific_styling_unique_to_your_site"


// views

// elements used on a single page. these styles are
// often needed to help put finishing touches on a
// page where modules didn't quite line up perfectly,
// or where a page has completely unique elements.
// these styles could often be abstracted to modules
// but lack a reason to do so. keeping them here helps
// explain their singular usage.

@import "views/welcome/index"
@import "views/settings/all"
@import "views/articles/show"
@import "views/users/show"

この方法でスタイルを整理すると、ファイルごとに単一の責任を作成するのに役立ちます（これも実行しようとしているように見えます）。これにより、CSSの保守性が大幅に向上することがわかりました。また、メディアクエリを追加したり、特定のモジュールを使用して特定のブラウザをターゲットにしたりする必要がある場合は、コードを読みやすく分離したまま、コンテキストに関連する場所を提供します。

上記の例は、名前空間が1つしかない場合に使用されることに注意してください。管理セクション（または他の何か）がある場合は、これらすべてのディレクトリ/ファイルを「アプリケーション」ディレクトリ内に貼り付けて、「admin」に同様の構造を作成できます。これにより、に次の構造が残りますapp/stylesheets。

- admin
- application
- admin.sass
- application.sass

2つの間でアイテムを共有するための構造を作成することもできますが、それが必要な場合と不要な場合があります。重要なのは、あなたがする必要があるかもしれないことは何でもあなたが多くの柔軟性と組織を持っているということです。あなたがそんなに傾いているならば、これと同じ構造はJSにも使うことができます。これにより、モジュールのリロードと新しいリクエストの作成の問題が回避されます。

FWIW、私はページごとに必要なものだけを取り込むための解決策を見つけようとしましたが（あなたの質問）、結局、リクエストの数を増やすと同時に、全体としてより多くのビットを渡すことになりました。YMMV。

これがあなたをあなたの道に連れて行くのに役立つことを願っています！

于 2012-10-19T23:14:51.277 に答える
3

rspec から手がかりを得て、_sass_helper.sassすべての非直接スタイルのインポート (変数、ミックスイン、プレースホルダー) を含むパーシャルを作成することでこれを解決し、それを各ファイルの先頭に含めました。_sass_helper.sassスタイルが含まれている場合、それらは各ファイルに書き込まれるため、非コード ビットは重要です。

これにより、コードを複製することなく、各ファイルに対して同じ「Sass 環境」を効果的に取得できます。

私は自分のツリーを次のように整理しています:

includes/
  _variables.sass
  _mixins.sass
  _extends.sass
posts/
  _post_partial_1.sass
  _post_partial_2.sass
application.sass
posts.sass
_sass_helper.sass

次に、posts.sass のようなものは次のようになります。

@import 'sass_helper'
@import 'posts/post_partial_1'
@import 'posts/post_partial_2'

.some.globally.shared.post
  styles: here

それはうまくいきます。ポスト パーシャルは sass ヘルパーを必要としないため、コントローラーごとに 1 つのマスター ファイル、個々の機能のパーシャル、およびどこでも同じ環境を使用することになります。

于 2012-10-19T23:35:43.667 に答える