프론트엔드 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 웹사이트에서는 컴포넌트 예제 상단의 배너가 다음을 나타냅니다:

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

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

GitLab은 적합한 컴포넌트가 존재하는 경우 항상 <gl-*> 컴포넌트를 사용하도록 요청합니다. 이는 코드베이스를 통일하고 앞으로 유지보수/리팩토링을 더 편리하게 만듭니다.

Product Designer가 머지 리퀘스트 리뷰의 일부로 비준수 컴포넌트 사용을 검토하도록 하세요. 후속 이슈를 생성하고 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. 프로덕션 빌드를 로컬에서 테스트하는 방법은?#

프론트엔드 프로덕션 빌드 결과를 로컬에서 테스트해야 할 때가 있습니다. 그 방법은 다음과 같습니다:

• webpack 중지: gdk stop webpack.

• gitlab/config 폴더에 있는 gitlab.yaml을 열고 webpack 섹션으로 스크롤하여 dev_server를 enabled: false로 변경합니다.

• yarn webpack-prod && gdk restart rails-web을 실행합니다.

프로덕션 빌드가 완료되는 데 몇 분이 걸립니다. 이 시점에서 코드 변경 사항은 위의 3번 항목을 다시 실행한 후에만 반영됩니다.

표준 개발 모드로 돌아가려면:

• gitlab 설치 폴더에 있는 gitlab.yaml을 열고 webpack 섹션으로 스크롤하여 dev_server를 enabled: true로 되돌립니다.

• yarn clean을 실행하여 프로덕션 에셋을 제거하고 공간을 확보합니다(선택 사항).

• webpack을 다시 시작합니다: gdk start webpack.

• GDK를 재시작합니다: gdk restart rails-web.

7. Babel 폴리필#

GitLab은 Babel preset-env 옵션인 useBuiltIns: 'usage'를 활성화했습니다. 이를 통해 타깃 브라우저가 지원하지 않는 각 JavaScript 기능에 대해 적절한 core-js 폴리필이 한 번씩 추가됩니다. core-js 폴리필을 수동으로 추가할 필요가 없습니다.

GitLab은 브라우저 기능을 확장하기 위한 비core-js 폴리필을 추가합니다(예: GitLab SVG 폴리필). 이를 통해 <use xlink:href>를 사용하여 SVG를 참조할 수 있습니다. 이러한 폴리필은 반드시 app/assets/javascripts/commons/polyfills.js에 추가하세요.

사용 중인 폴리필을 확인하려면:

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

• 머지 리퀘스트 제목 아래의 보조 메뉴에서 Pipelines를 선택한 후, 보고자 하는 파이프라인을 선택하면 해당 파이프라인의 job이 표시됩니다.

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

• 오른쪽 사이드바에서 Job Artifacts로 스크롤하고 Browse를 선택합니다.

• webpack-report 폴더를 선택하여 열고 index.html을 선택합니다.

• 페이지 왼쪽 상단 모서리에서 오른쪽 화살표(chevron-lg-right)를 선택하면 탐색기가 표시됩니다.

• Search modules 필드에 gitlab/node_modules/core-js를 입력하면 어떤 폴리필이 어디서 로드되고 있는지 확인할 수 있습니다:

[

](/19.1/development/fe_guide/img/webpack_report_v12_8.png)

8. 다크 모드에서 페이지가 깨지는 이유는?#

다크 모드 문서를 참고하세요.

9. GitLab 맛 마크다운(GitLab-flavored Markdown)을 렌더링하는 방법은?#

GitLab-flavored Markdown을 렌더링해야 하는 경우 두 가지가 필요합니다:

• Vue 컴포넌트 내 div HTML 엘리먼트에 v-safe-html 디렉티브와 함께 GLFM 콘텐츠를 전달합니다.

• 루트 div에 md 클래스를 추가하면 적절한 CSS 스타일링이 적용됩니다.