프론트엔드 FAQ 규칙#

• 프론트엔드 FAQ를 화제로 삼습니다. 콘텐츠가 오래되었을 때 더 많은 사람이 알아차릴 수 있도록, 해당하는 경우에는 언제든지 링크를 공유합니다.
• 짧고 단순하게 유지합니다. 답변에 두 문장을 넘는 설명이 필요하다면 이 문서에 넣지 않습니다.
• 가능하면 배경을 함께 제공합니다. 관련 소스 코드, 이슈 / 에픽, 그 밖의 문서를 링크하면 답변을 이해하는 데 도움이 됩니다.
• 무언가를 발견하면 조치합니다. 오래된 콘텐츠는 발견하는 즉시 삭제하거나 업데이트합니다.

FAQ#

1. 페이지의 Rails 라우트를 찾는 방법#

'page' 데이터 속성 확인#

가장 쉬운 방법은 해당 페이지를 연 상태에서 브라우저에 다음을 입력하는 것입니다.

document.body.dataset.page

해당 속성을 설정하는 소스 코드를 여기에서 확인합니다.

Rails 라우트#

rails routes 명령으로 애플리케이션에서 사용할 수 있는 모든 라우트를 나열할 수 있습니다. 출력을 grep으로 파이프하면 사용 가능한 라우트 목록에서 검색할 수 있습니다. 출력에는 사용 가능한 요청 유형, 라우트 파라미터, 관련 컨트롤러가 포함됩니다.

bundle exec rails routes | grep "issues"

2. clipboard_button과 simple_copy_button의 차이#

clipboard_button은 페이지 로드 시 초기화되는 copy_to_clipboard.js 동작을 사용합니다. 페이지 로드 시점에 존재하지 않는 Vue 클립보드 버튼 (예: GlModal 안의 버튼)에는 클립보드 패키지와 연결된 클릭 핸들러가 없습니다.

simple_copy_button.vue는 이 동작을 사용하지 않으므로 모달을 비롯한 어디에서나 안전하게 사용할 수 있습니다.

3. Pajamas Design System을 준수하지 않는 gitlab-ui 컴포넌트#

gitlab-ui에 구현된 일부 Pajamas Design System 컴포넌트는 디자인 시스템 사양을 준수하지 않습니다. 계획된 기능 일부가 아직 없거나 스타일이 아직 올바르게 적용되지 않았기 때문입니다. Pajamas 웹사이트에서는 컴포넌트 예제 상단의 배너가 다음을 알립니다.

이 컴포넌트는 GitLab 디자인 시스템에 정의된 올바른 스타일을 아직 준수하지 않습니다. 이 컴포넌트의 시각 요소를 참조할 때는 디자인 시스템 문서를 참고합니다.

예를 들어 이 문서를 작성하는 시점에 이러한 유형의 경고는 checkbox 같은 모든 폼 컴포넌트에서 확인할 수 있습니다. 다만 이것이 해당 컴포넌트를 사용하지 말아야 한다는 뜻은 아닙니다.

GitLab은 적합한 컴포넌트가 존재하는 경우 항상 <gl-*> 컴포넌트를 사용하도록 요청합니다. 이렇게 하면 코드베이스가 통일되고 이후 유지 보수와 리팩터링이 수월해집니다.

Product Designer가 MR 리뷰의 일부로 비준수 컴포넌트의 사용을 검토하도록 합니다. 후속 이슈를 생성하고 Components of Pajamas Design System epic에 있는 컴포넌트 구현 에픽에 연결합니다.

4. 폼 제출 버튼이 제출 후 비활성화되는 현상#

폼 안의 Submit 버튼은 폼 엘리먼트에 onSubmit 이벤트 리스너를 연결합니다. 이 코드는 폼이 제출될 때 submit 버튼에 disabled 클래스 선택자를 추가합니다. 이 동작을 피하려면 버튼에 js-no-auto-disable 클래스를 추가합니다.

5. 프론트엔드에서 URL 또는 경로를 참조하는 방법#

공개 REST API#

URL을 직접 생성하지 않습니다. 대신 app/assets/javascripts/api에서 사용할 수 있는 메서드를 확장합니다.

내부 Rails 컨트롤러 API#

Rails 컨트롤러에 JSON 요청을 보낼 때 API URL은 Rails에서 프론트엔드로 전달해야 합니다. 데이터 속성으로 URL 전달을 참고합니다.

페이지 간 라우팅#

프론트엔드에서 라우트를 생성하는 방법에 관한 더 자세한 문서는 GitLab의 URL을 참고합니다.

6. 프로덕션 빌드를 로컬에서 테스트하는 방법#

프론트엔드 프로덕션 빌드의 결과물을 로컬에서 테스트해야 할 때가 있으며, 절차는 다음과 같습니다.

1. webpack을 중지합니다: gdk stop webpack.
2. gitlab/config 폴더에 있는 gitlab.yaml을 열고 webpack 섹션까지 스크롤한 다음 dev_server를 enabled: false로 변경합니다.
3. yarn webpack-prod && gdk restart rails-web을 실행합니다.

프로덕션 빌드는 완료되기까지 몇 분이 걸립니다. 이 시점 이후의 코드 변경 사항은 위 3번 항목을 다시 실행한 뒤에만 표시됩니다.

표준 개발 모드로 돌아가려면 다음과 같이 합니다.

1. gitlab 설치 폴더에 있는 gitlab.yaml을 열고 webpack 섹션까지 스크롤한 다음 dev_server를 다시 enabled: true로 변경합니다.
2. yarn clean을 실행해 프로덕션 에셋을 제거하고 공간을 확보합니다(선택 사항).
3. webpack을 다시 시작합니다: gdk start webpack.
4. GDK를 재시작합니다: gdk restart rails-web.

7. Babel 폴리필#

GitLab은 Babel preset-env 옵션 useBuiltIns: 'usage'를 활성화했습니다. 이 옵션은 GitLab 이 사용하는 JavaScript 기능 중 대상 브라우저가 지원하지 않는 것마다 적절한 core-js 폴리필을 한 번씩 추가합니다. core-js 폴리필을 직접 추가할 필요는 없습니다.

GitLab은 브라우저 기능을 확장하기 위해 core-js가 아닌 폴리필도 추가합니다(예: GitLab SVG 폴리필). 이 덕분에 <use xlink:href>로 SVG를 참조할 수 있습니다. 이러한 폴리필은 app/assets/javascripts/commons/polyfills.js에 추가합니다.

사용 중인 폴리필을 확인하려면 다음과 같이 합니다.

1. 머지 리퀘스트로 이동합니다.

2. 머지 리퀘스트 제목 아래의 보조 메뉴에서 Pipelines를 선택한 다음, 확인하려는 파이프라인을 선택해 해당 파이프라인의 job을 표시합니다.

3. compile-production-assets job을 선택합니다.

4. 오른쪽 사이드바에서 Job Artifacts까지 스크롤한 다음 Browse를 선택합니다.

5. webpack-report 폴더를 선택해 연 다음 index.html을 선택합니다.

6. 페이지 왼쪽 위 모서리에서 오른쪽 화살표([chevron-lg-right])를 선택해 탐색기를 표시합니다.

7. Search modules 필드에 gitlab/node_modules/core-js를 입력해 어떤 폴리필이 어디에서 로드되는지 확인합니다.

   

8. 다크 모드에서 페이지가 깨지는 원인#

다크 모드 문서를 참고합니다.

9. GitLab Flavored Markdown 렌더링 방법#

GitLab Flavored Markdown을 렌더링해야 한다면 두 가지가 필요합니다.

• Vue 컴포넌트 안의 div HTML 엘리먼트에 v-safe-html 디렉티브로 GLFM 콘텐츠를 전달합니다
• 루트 div에 md 클래스를 추가하면 적절한 CSS 스타일이 적용됩니다