Haml: 기능 요청: 폴더 가져오기

나는 이것의 유용성에 회의적이다. 모든 관련 파일을 수동으로 나열해야 하는 것이 그렇게 부담스러운 일은 아니라고 생각합니다. 또한 존재한다고 예상하는 파일이 없을 때 실제 컴파일 오류가 발생하지 않을 위험이 있는 것처럼 보입니다. 대신 스타일이 임의로 사라집니다.

나는 당신의 주장을 이해하지만 이것이 필요한 다른 유형의 상황을 보고 있다고 생각하지 않습니다. 현재 60개 이상의 Sass 파일이 있는 폴더가 있습니다. @import 폴더 기능이 없으면 각 파일을 개별적으로 가져오는 파일을 유지 관리해야 합니다.

각 파일을 개별적으로 포함하는 데에는 많은 문제가 있습니다. 첫째, 파일을 포함하는 것을 잊은 경우 경고가 표시되지 않습니다. 다음으로 Sass에서 작업하는 개발자 팀이 있는 경우 폴더에 파일을 만든 후 수동으로 파일을 가져와야 한다는 점을 기억해야 합니다. 사람들이 옳은 일을 하느냐에 따라 결국 무너질 것입니다.

또한 폴더를 가져오는 것이 "좋은 것"이라는 우선 순위가 있습니다. Java의 import 문을 사용하면 전체 패키지 또는 해당 패키지의 특정 클래스를 가져올 수 있습니다.

동일한 가중치의 셀렉터가 문서 순서에 따라 결정되기 때문에 일반적인 경우 수입 순서가 중요합니다. 글로빙은 파일을 추가하면 선택기의 전역 해상도 순서가 예기치 않게 변경될 수 있음을 의미합니다.

이러한 순서 문제는 코드에 없으며 루비와 같은 위치에는 그러한 기능이 없습니다.

Sass 코어 가져오기 메커니즘을 변경하지 않고 Sass에서 이 작업을 수행할 수 있는 방법이 있는지 알고 싶습니다. 이렇게 하면 sass를 사용하는 프레임워크와 개인이 적절하다고 생각하는 대로 자체 글로빙 시스템을 개발할 수 있습니다. 예를 들어:

<strong i="8">@import</strong> file-list("foo/*.sass");

우리는 @import 대한 특수 구문 분석 논리를 사용하여 이를 방지했지만 더 이상 사용하지 않습니다.

진정한 동적 가져오기(예: 함수를 통한)를 허용할 때의 문제는 문서의 종속성 구조를 동적으로 파악하는 것이 불가능해진다는 것입니다. 이것은 캐싱과 선택적 컴파일이 훨씬 덜 유용하다는 것을 의미합니다.

순서 문제의 경우 항상 파일을 알파벳순으로 정렬하거나 결정적(임의적이긴 하지만) 순서를 제시할 수 있습니다. 그러나 파일 이름이 변경되면 순서가 변경되고 기능이 중단될 수 있다는 문제가 여전히 존재합니다.

아마도 globbing을 통한 이러한 접근 방식은 이러한 문제를 방지하기 위해 중첩 선택기를 사용함을 의미합니다.

제 생각에는 파일의 전체 디렉토리 트리를 가져오는 것은 명시적 가져오기 접근 방식보다 약간만 유용하며 사용자가 우선 순위 문제를 고려하도록 권장합니다. 이러한 기능을 추가한다면 디렉토리 수준에서보다 더 일반적인 용도로 사용하고 싶습니다.

마지막으로, 종속성 그래프 외부에 있고 sass 엔진에 대한 단일 가져오기로 나타나는 glob을 도입하는 것은 glob과 일치하는 새 종속성이 나타날 때 파일을 무효화하는 것이 더 어렵다는 것을 의미한다고 생각합니다.

폴더를 가져오면 가져오는 파일의 순서가 모호하다는 데 동의합니다. 그러나 그것이 올바른 것인지 여부는 사용자가 결정해야 합니다. 일부 상황에는 적합하지만 다른 상황에는 적합하지 않습니다. 폴더의 내용이 동일한 요소를 대상으로 하지 않는 시스템을 상상하는 것은 확실히 가능합니다(내 것은 그렇지 않음).

특정 파일을 가져오는 것처럼 작동합니다. 일부 상황에는 적합하지만 다른 상황에는 적합하지 않습니다.

선택은 개발자에게 달려 있습니다.

사용자가 순서에 의존하고 그것을 알지 못하는 스타일시트를 갖는 것은 너무 쉽습니다. 무엇이든 재정렬을 유발하고 추적하기 매우 어려운 레이아웃 버그를 생성할 수 있습니다. 그리고 디렉토리를 가져오면 누군가가 그러한 문제에 노출될 것이라는 점은 충분히 명확하지 않습니다. 파일 이름을 통한 주문은 이에 대한 충분한 해결책이 될 수 있으므로 심각한 장애는 아닙니다.

내가 고려하는 확장은 표준 파일 글로브를 허용할 것입니다 -- 아마도 Dir.glob 지원하는 것입니다. 이것은 컴파일 타임에 해결할 수 있으며 합리적인 수준의 능력을 제공합니다.

나는 여전히 유틸리티에 대해 확신하는 방법입니다.

Dir.glob 를 통한 주문은 파일 시스템에 따라 다르며 플랫폼에 따라 변경될 수 있다는 점을 고려하는 것이 중요합니다. 저는 실제로 Mac과 Linux의 이러한 차이점에 푹 빠져 있었습니다. 따라서 이러한 기능을 구현하게 되면 잘 문서화되고 쉽게 이해할 수 있는 접근 방식(예: downcased 정렬)에 따라 목록을 정렬하는 것이 중요합니다.

나는 또한 여전히 이 기능에 대해 약간의 기대를 갖고 있습니다. 나침반이 사용하는 수입 방식은 실제로 유지 관리 부담이 되지 않았습니다. 그러나 확실히 일반적으로 요청되는 기능입니다. 메일링 리스트와 트위터에 4~5번 정도 올라온 것 같아요.

우리는 확실히 어떻게든 파일을 결정적으로 정렬할 것입니다. Upcased vs. downcased 정렬은 흥미로운 질문입니다... 우리는 아마도 downcased를 upcased로 결정해야 할 것입니다(대소문자를 구분하는 파일 시스템에 대한 연결을 허용하기 때문에).

나는 동의한다. Dir.glob에 직접 매개변수를 전달할 수 있는 것에 반대합니다. 정말 불필요한 기능 같습니다. 당신은 그 정도의 통제력을 갖는 것이 유리한 시나리오를 생각해 낼 수 있습니까?

다음 두 가지 옵션으로 충분할 것 같습니다.
- @import를 사용하여 체리 선택 파일
- @import folder_name을 사용하여 전체 디렉토리 가져오기

또한 알파벳순이 잘 작동할 것이라고 생각합니다. 문서화되었는지 확인하기만 하면 됩니다.

<strong i="5">@import</strong> dir 를 통해 디렉토리를 가져오는 것은 개별 파일을 가져오기에 너무 모호합니다. 최소한 * 글로브를 추가해야 합니다.

그래도 확신이 서지 않습니다.

페이지에 대해 다른 "스타일"이 있는 경우 유용합니다. 예시:
일반/ (여기에 xx sass 파일)
style1/ (여기에 일반 스타일에 스타일을 추가/덮어쓰는 xx sass 파일)
style2/ (여기에 일반 스타일에 스타일을 추가/덮어쓰는 xx sass 파일)
style1.sass (간단히: @import generic/_, style1/_)
style2.sass (간단히: @import generic/_, style2/_)

일반 디렉토리의 모든 것을 가져오는 _generic.sass를 가질 수 없는 이유는 무엇입니까?

나는 그들이 해야 하는 만큼 할 수 있는 것과 할 수 없는 것에 관한 것이 아니라고 생각합니다. 궁극적으로 스타일시트의 순서는 중요하므로 사용자가 그것에 대해 생각했으면 합니다. 그것은 단지 유지 mixin과 변수를 정의 라이브러리 스타일 시트를 범위하는 등의 순서와 무관 것은 사실입니다 -하지만 잘못 사용되는 일반적인 기능을 제공에 대해 우려하고있다.

"범위가 지정된 스타일시트"를 정의하시겠습니까?

대부분 또는 모든 선택기를 중첩하는 스타일시트입니다. 예: body.foo

그것들은 순서 독립적이라고 보장되지 않습니다. 다른 곳의 다른 스타일시트는 body.foo ... 또는 더 높은 특이성을 가진 다른 것을 정의할 수 있습니다.

그러면 파일이 올바르게 분리되지 않았기 때문에 실제로 작동하는 프레임워크가 없는 것입니다.

사람들이 CSS를 망칠 수 있는 방법은 많습니다. 우리는 그들에게 이 솔루션을 제공하고 개별 파일을 가져오는 것보다 언제 사용해야 하는지 설명할 수 있습니다.

이 기능을 구현하지 않음으로써 이 작업을 수행하려는 개발자에게 범위가 지정된 스타일시트를 구현하는 데 다음 두 가지 선택권이 주어집니다.
1) 수동)이 자신의 당신이 파일을 놓친 때 당신에게하지 않기 때문에 오류가 발생할 수있다 (각각 독립적으로 파일을 가져옵니다
2) 이러한 파일을 동적으로 추가하는 빌드 시스템을 구현합니다(동일한 것을 구현하는 여러 사람이 있기 때문에 낭비입니다).

범위가 지정된 스타일시트의 모든 순서 종속성이 문제 분리가 제대로 이루어지지 않았기 때문에 발생하는 것은 아닙니다. 고려하다:

body.foo .baz {
  color: blue; }

body.bar .baz {
  color: red; }

이 스타일시트는 잘 구분되어 있지만 여전히 순서에 따라 다릅니다.

어쨌든 이 기능을 사용하는 모든 사람이 위험을 이해하기를 기대할 수 있다는 생각은 잘못된 것입니다. 모든 사람이 스타일시트를 가져올 순서를 이해하도록 하는 유일한 방법은 명시적으로 지정하는 것입니다.

대체로 범위가 지정된 스타일시트는 순서에 구애받지 않지만 관심사가 올바르게 분리된 경우에도 순서가 중요한 경우가 될 수 있습니다.

찾을 수 없는 가져오기를 조용히 무시하는 것은 sass3에서 더 이상 문제가 되지 않습니다. CSS 가져오기만 자동으로 무시됩니다.

약 60개의 다른 파일을 가져오는 하나의 sass 파일이 있습니다. 파일을 추가하거나 삭제할 때 변경하고 할 때 항상 순서를 생각합니다. 나에게 부담으로 다가온 적은 한 번도 없었다. 오히려 꼭 필요한 단계였다.

내 가져오기를 찾을 수 없으면(나는 항상 가져오기에 대해 .sass를 지정함) 테스트가 실패합니다.

속담이 있습니다. 가능한 한 간단하고 단순하지 않습니다.

내 직감은 이것이 일을 너무 단순하게 만들고 한 번의 디버깅 세션으로 인해 모든 시간 절약이 손실된다고 말합니다. 나는 우리가 이것을 당분간 제쳐 두는 것에 투표합니다. 누군가 이 기능을 제공하는 sass 플러그인을 만들고 싶다면 해당 사용자에게 어떻게 작동하는지 보고 싶습니다.

Richard의 요점은 부분이 생성되지만 가져오기가 추가되지 않을 때 오류가 없다는 것입니다. 사용하지 않은 부분을 찾고 경고를 인쇄하면 이것이 완화될 수 있다고 생각합니다.

나는 이것을 계속하고 닫을 것이다.

이런, 짜증난다... 내 레일즈 앱 자산에 page_specific/이라는 폴더가 있습니다...
이것들은 모두 큰 자산 blob으로 컴파일되어야 하며, 각각은 다음으로 완전히 래핑됩니다.
body#page1 {}, body#page2 {} 등...

그것들이 순서에 의존할 가능성은 전혀 없으며 솔직히 이 전체가 "당신은 그것을 놓치게 될 것입니다! 아니!!!!!!" 똥은 모욕입니다.

이 기능의 사용자가 순서가 중요하다는 것을 발견하면 명시적인 순서로 파일을 가져오거나 순서에 종속되지 않도록 스타일을 리팩터링할 수 있습니다... 모두가 이 누락된 기능을 수동으로 해결하도록 강요하는 것은 가부장적인 쓰레기 >: (

확실히 우리는 이 사소한 주문 문제를 최소화하는 방법을 생각할 수 있습니다. 결정적 순서는 시작입니다. 그것을 @import-dir이라고 부르고 잠재적인 주문 문제에 대한 문서화도 도움이 될 것입니다. rails는 이미 require_tree를 제공하며 거기에 있는 것들이 잘 작동하는 것 같습니다. 한 가지 예외는 파일이 개별적으로 컴파일되어 내 믹스인과 변수를 바닥에 떨어뜨린다는 것입니다. 나는 믹스인이 명시적으로 순서 독립적으로 배치된 한 부분이라는 점에 주목합니다. 그래서 다른 모든 사람에게 작동할 때 이것이 sass에서는 작동하지 않는 이유는 무엇입니까?

https://github.com/chriseppstein/sass-globbing

@chrisepstein 굉장합니다! (그리고 미치광이처럼 떠들어서 죄송합니다 여러분)