페이지 특정 말대꾸 파일과 중복

Question

정말 엄청난 중복을 피하기 위해 레일 3.1 프로젝트의 말대꾸 파일을 구성하기 위해 고군분투하고있다 ... 내 기본 레이아웃 :

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

지금까지 그렇게 좋았습니다. 이 모든 파일은 스프로킷에 의해 하나의 문서로 결합됩니다. 그러나 나는 페이지 특정 파일이나 파일을 내 사이트 영역에서 공유하여 내 Sass를 더 모듈화하려고합니다.

gallery_lib.scss 

이 파일의 숫자를 참조해야합니다

resource.scss 
gallery_resource.scss 
badges.scss 

그리고 lib 디렉토리에서 어쩌면 CSS 파일 :

그래서 내 GalleryResource # 쇼 페이지에서 내가 추가 말대꾸 파일을 사용할 필요가 이미 application.css에서 가져온 파일. 그들은 variables.css.scss에 정의 된 변수와 부트 스트랩에 정의 된 mixins를 사용해야합니다. 그래서 나는 그들을 사용하는 각 파일에서 이러한 파일을 다시 가져와 강제로 대량 복사를하게됩니다. 각 페이지마다 매니페스트 파일을 작성할 수는 있지만 관리상의 악몽이며 여전히 복제 및 두 개의 CSS 파일이 생성됩니다. application.css 및 page_specific.css.

그래서 해결책은 무엇입니까? application.css를 사용하지 않고 각 페이지 별 파일로 가져 오기를 이동해야합니까? 따라서 위의 예를 사용하여 I는 다음과 같습니다 하나의 매니페스트 파일로 끝날 것 :

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'; 

Answer 1

rspec에서 큐를 가져 와서 _sass_helper.sass 부분을 생성했습니다. 여기에는 직접적이지 않은 스타일의 모든 가져 오기 (변수, 믹스 인, 자리 표시 자)가 포함되어 있으며 각 파일의 맨 위에 포함됩니다. _sass_helper.sass에 스타일이 포함되어 있으면 코드가 아닌 비트가 중요하므로 각 파일에 작성됩니다.

이렇게하면 코드 중복없이 각 파일에 대해 동일한 "Sass 환경"을 효과적으로 얻을 수 있습니다.

나는 나의 나무과 같이 조직이 : 그것은 위대한 작품을

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

.some.globally.shared.post 
    styles: here 

: 같은

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 같은 것이 보일 것이다. post 부분은 sass 헬퍼가 필요하지 않으므로 컨트롤러마다 하나의 마스터 파일, 개별 기능의 부분 및 모든 환경이 동일한 마스터 파일로 끝납니다.

Answer 2

나는 또한 스타일을 구성 할 때 언급되는 같은 일을 시도했다. Rails는 컨트롤러 기반 스타일 시트를 지속적으로 생성함으로써 이러한 방향으로 나아갈 것입니다. 결국 나는 모든 것을 application.sass에 추가하기로 선택했습니다. 이 방법의 가장 큰 장점은 페이지로드시 하나의 요청 만하고 마지막 페이지에서 사용자가 요청한 코드를 다시 가져 오지 않아도된다는 것입니다.

개인적인 견해로는 CSS를 잘 추상화하면 스타일 시트를 처음부터 스타일 시트에 가져올보기가 많은 코드가 없기 때문에 하나의 스타일 시트 만 사용하면됩니다. 어느 쪽이든, 대체 방법 (이전 페이지에서 동일한 작업을 수행하는 동안 페이지 필요에 따라 모듈을 무작위로로드)은 문제를 해결하는 것처럼 들리지 않습니다. 또한 완전히 새로운 파일에 대한 추가 요청을하고 있습니다.

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를 훨씬 더 유지 보수 가능하게 만든다는 것을 발견했다. 또한 미디어 쿼리를 추가하거나 특정 모듈과 함께 특정 브라우저를 타겟팅해야하는 경우 코드를 읽기 쉽고 분리 된 상태로 유지하면서 문맥 적으로 관련성이 높은 장소를 제공합니다.

위 예제는 네임 스페이스가 하나만있는 경우에 사용됩니다.관리자 섹션 (또는 다른 것)을 갖고 있다면 "응용 프로그램"디렉토리 안에 이러한 디렉토리/파일을 모두 넣고 "admin"과 비슷한 구조를 만들 수 있습니다. 그러면 app/stylesheets에 다음 구조가 남습니다.

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

두 항목을 공유하는 구조를 만들 수도 있지만 필요하지 않을 수도 있습니다. 요점은 무엇을해야 할지도 모르는 많은 유연성과 조직이 있다는 것입니다. 당신이 그렇게 생각한다면 JS와 같은 구조를 사용할 수도 있습니다. 이렇게하면 모듈을 다시로드하고 새로운 요청을하는 문제를 피할 수 있습니다.

FWIW, 나는 페이지 당 필요한 것 (질문) 만 가져 오는 해결책을 찾으려고했지만 결국에는 요청 수가 늘어나면서 결국 전체 비트를 더 많이 통과하게되었습니다. YMMV.

희망 사항은 도움이 되길 바랍니다.