SCSS 스타일 가이드
유틸리티 클래스
gl-deprecated- 접두어가 있는 유틸리티를 사용하지 마십시오. 대신 Tailwind 유틸리티를 사용하십시오.사이트가 커짐에 따라 CSS를 더 생성하는 것을 줄이기 위해, 새로운 CSS를 추가하는 대신 유틸리티 클래스를 사용하는 것을 선호합니다. 복잡한 경우에는 CSS를 컴포넌트 클래스를 추가하여 처리할 수 있습니다.
Tailwind CSS
우리는 현재 CSS 유틸리티 클래스 설정을 Tailwind CSS로 마이그레이션 중입니다. 동기, 제안 및 구현 세부 정보는 Tailwind CSS blueprint를 참조하십시오.
Tailwind CSS 번들 빌드
GitLab 개발 킷과 함께 Vite 또는 Webpack을 사용할 때, Tailwind CSS는 감지된 유틸리티를 동적으로 빌드하기 위해 파일 변경을 감시합니다.
새로운 Tailwind CSS 번들을 빌드하려면 yarn tailwindcss:build를 실행하십시오. 이 스크립트는 bundle exec rake gitlab:assets:compile로 프로덕션 자산을 빌드할 때 내부적으로 호출되는 스크립트입니다.
그러나 번들이 빌드되는 방식에 상관없이, 출력물은 app/assets/builds/tailwind.css에 저장됩니다.
어디에서 유틸리티 클래스가 정의되어 있나요?
GitLab UI에서 정의된 유틸리티 클래스를 사용하는 것을 선호합니다.
유틸리티 클래스의 쉬운 디렉터리은 Unpkg에서 확인할 수 있습니다.
또는 CSS Class completion과 같은 확장 프로그램을 사용할 수 있습니다.
utilities.scss 및 common.scss의 클래스는 폐지됩니다. 비디자인 시스템 값이 아닌 common.scss의 클래스는 피하십시오. 대신 일치하는 값으로 동일하게 사용하십시오.
부트스트랩의 유틸리티 클래스를 사용하지 마십시오.
ml-1을 gl-ml-2로 변경).언제 새로운 유틸리티 클래스를 추가해야 하나요?
Tailwind로의 마이그레이션 단계에서 이미 필요한 유틸리티 클래스가 사용 가능한 경우가 많습니다. VS Code 플러그인을 위한 인텔리센스를 사용하면 사용 가능한 유틸리티 클래스가 표시됩니다. Tailwind에서 사용할 수 없는 유틸리티 클래스가 필요한 경우, GitLab UI에서 정의된 유틸리티 클래스를 계속 사용하거나 Unpkg에서 확인할 수 있습니다. 여전히 해당 유틸리티 클래스를 찾을 수 없는 경우, Tailwind에 새로운 코어 플러그인을 활성화해야 합니다. 관련 코어 플러그인을 찾아서 tailwind.defaults.js의 corePlugins 배열에 코어 플러그인을 추가하는 MR(Merge Request)을 엽니다.
언제 컴포넌트 클래스를 만들어야 하나요?
“유틸리티 우선” 접근을 권장합니다.
- 유틸리티 클래스로 시작합니다.
- 유틸리티 클래스를 컴포넌트 클래스로 구성하여 코드 중복을 제거하고 명확한 책임을 캡슐화하는 경우, 컴포넌트 클래스로 변환합니다.
이렇게 하면 컴포넌트 클래스가 유기적으로 확장되고 일회용으로 재사용되지 않는 클래스가 생성되는 것을 방지합니다. 또한, “유틸리티 우선”에서 나오는 클래스는 주로 .button, .alert, .card와 같은 디자인 중심적인 클래스인 반면, 도메인 중심적인 클래스(예: .security-report-widget, .commit-header-icon)보다는 디자인 중심적인 경향이 있습니다.
유틸리티 믹스인
우리는 현재 Tailwind로의 마이그레이션 중에 있습니다. 마이그레이션은 유틸리티 믹스인을 제거하므로 새로운 유틸리티 믹스인 사용을 피하십시오. 대신 SCSS 변수와 함께 pre-defined CSS keywords를 사용하십시오.
// 나쁨
.my-class {
@include gl-mt-3;
}
// 매우 나쁨
.my-class {
@include gl-deprecated-mt-3;
}
// 나쁨
.my-class {
margin-top: 0.5rem;
}
// 좋음
.my-class {
margin-top: $gl-spacing-scale-3;
}
명명
파일 이름은 snake_case를 사용해야 합니다.
CSS 클래스는 snake_case나 camelCase 대신 lowercase-hyphenated 형식을 사용해야 합니다.
// 나쁨
.class_name {
color: #fff;
}
// 나쁨
.className {
color: #fff;
}
// 좋음
.class-name {
color: #fff;
SCSS의 & 기능을 사용하여 복합 클래스 이름을 만드는 것은 피해야 합니다. 사용된 곳을 찾기 어렵게 만들며, 제한된 이점을 제공합니다.
// 나쁨
.class {
&-name {
color: orange;
}
}
// 좋음
.class-name {
color: #fff;
태그 이름 선택기 대신 클래스 이름을 사용해야 합니다. 태그 이름 선택기를 사용하는 것은 의도하지 않은 요소에 영향을 줄 수 있기 때문에 권장하지 않습니다.
// 나쁨
ul {
color: #fff;
}
// 좋음
.class-name {
color: #fff;
}
// 가장 좋음
// 기존 스타일을 추가하는 대신 기존 유틸리티 클래스 사용을 선호합니다
클래스 이름은 ID보다 사용하는 것이 좋습니다. ID를 사용하는 규칙은 재사용이 불가능하며 페이지에서 영향을 받는 요소가 하나뿐이기 때문입니다.
// 나쁨
#my-element {
padding: 0;
}
// 좋음
.my-element {
padding: 0;
}
중첩
불필요한 중첩을 피하세요. 래퍼 컴포넌트의 추가적인 구체성은 재정의를 어렵게 만듭니다.
// 나쁨
.component-container {
.component-header {
/* ... */
}
.component-body {
/* ... */
}
}
// 좋음
.component-container {
/* ... */
}
.component-header {
/* ... */
}
.component-body {
/* ... */
}
js- 접두사를 가진 선택자
스타일링 목적으로 js-로 접두사가 지정된 선택자를 사용하지 마십시오. 이러한 선택자들은 스타일링을 깨지 않고 제거하거나 이름을 변경할 수 있도록 JavaScript에서만 사용되도록 의도되어 있습니다.
extend at-rule 사용
extend at-rule의 사용은 메모리 누수로 인해 금지되어 있으며, 규칙이 의도한 대로 작동하지 않습니다.
린트
우리는 스타일 가이드 규정을 확인하기 위해 stylelint를 사용합니다. 이는 프로젝트의 홈 디렉터리에 위치한 .stylelintrc와 우리의 SCSS 구성에서 규칙을 사용합니다.
귀하의 변경 사항에서 어떤 경고가 발생하는지 확인하려면 GitLab 디렉터리에서 yarn lint:stylelint를 실행하세요. 또한 Stylelint는 GitLab CI/CD에서 모든 경고를 잡아냅니다.
Rake 작업에서 이해하기 어려운 경고가 발생하는 경우 SCSS Lint의 문서에 규칙의 전체 디렉터리이 포함되어 있습니다.
도움말