프론트엔드 FAQ

프론트엔드 FAQ 규칙

프론트엔드 FAQ에 대해 이야기합니다. 해당 내용이 구식이 될 때마다 더 많은 사람들이 볼 수 있도록 링크를 공유하세요.
간결하고 명료하게 유지하세요. 답변이 두 문장 이상 필요한 경우 여기에 포함되지 않습니다.
가능한 경우 배경을 제공하세요. 관련 소스 코드, 이슈/에픽 또는 기타 문서에 링크하는 것이 답변을 이해하는 데 도움이 됩니다.
무엇인가 보이면 무언가를 하세요. 구식인 내용은 발견 즉시 업데이트하거나 제거하세요.

FAQ

1. 레일즈 페이지의 루트를 찾는 방법은 무엇인가요?

‘page’ 데이터 속성 확인

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

document.body.dataset.page

속성을 설정하는 소스 코드를 여기에서 찾을 수 있습니다.

레일즈 루트

rails routes 명령어를 사용하여 애플리케이션의 모든 경로를 나열할 수 있습니다. 출력을 grep으로 파이핑하여 사용 가능한 경로 목록을 검색할 수 있습니다. 출력에는 사용 가능한 요청 유형, 경로 매개변수 및 관련 컨트롤러가 포함됩니다.

bundle exec rails routes | grep "issues"

2. `modal_copy_button` vs `clipboard_button`

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

modal_copy_button은 해당 컴포넌트의 인스턴스에 특화된 clipboard 플러그인의 인스턴스를 관리합니다. 이렇게 하면 클립보드 이벤트가 마운트되고 해당 버튼이 파괴됩니다. 또한 위의 문제를 완화하는데에 적합한 특정 컨테이너 또는 모달 ID의 바인딩이 있습니다. 이는 우리의 GlModal이 생성하는 포커스 트랩과 함께 작동할 수 있습니다.

3. `gitlab-ui` 컴포넌트가 Pajamas 디자인 시스템에 부합하지 않음

gitlab-ui에 구현된 일부 Pajamas Design System 컴포넌트가 디자인 시스템 사양과 부합하지 않습니다. 이는 일부 계획된 기능이 부족하거나 올바르게 스타일이 지정되지 않았기 때문입니다. Pajamas 웹사이트에서 컴포넌트 예시 위에 배너를 통해 다음과 같이 나타납니다:

이 컴포넌트는 아직 디자인 시스템에 정의된 올바른 스타일과 부합하지 않습니다. 이 컴포넌트의 시각적인 참조 시 디자인 시스템 문서를 참조하세요.

예를 들어, 기록된 시점에서 이러한 유형의 경고가 체크박스와 같은 모든 폼 컴포넌트에 대해 관찰될 수 있습니다. 그러나 이는 컴포넌트를 사용하면 안 되는 것을 의미하지는 않습니다.

GitLab은 항상 적합한 컴포넌트가 존재하는 경우 <gl-*> 컴포넌트를 사용할 것을 요청합니다. 이는 코드베이스를 통일시키고 미래에 유지/리팩터링이 더 편리하도록 만듭니다.

비부합 컴포넌트의 사용은 MR(Merge Request) 검토의 일환으로 제품 디자이너에 의해 검토되어야 합니다. 이는 Pajamas Design System epic에서 컴포넌트 구현 에픽을 찾아 팔로업 이슈를 만들고 해당 이슈를 첨부해야 합니다.

4. 제출 양식 버튼이 제출 후 비활성화되는 이유는 무엇인가요?

양식 내부의 제출 버튼은 양식 요소에 onSubmit 이벤트 리스너를 부착합니다. 이 코드는 양식이 제출되면 제출 버튼에 disabled 클래스 선택기를 추가합니다. 이 동작을 피하려면 버튼에 js-no-auto-disable 클래스를 추가하세요.

5. 백엔드 엔드포인트를 참조할 때 완전한 URL 또는 전체 경로를 사용해야 하나요?

전체 경로인 gon.relative_url_root를 사용하는 것이 좋습니다. 완전한 URL(예: gon.gitlab_url과 같은)보다 이유는 GitLab에 구성된 호스트명을 사용하기 때문에 요청과 일치하지 않을 수 있습니다. 이것은 이러한 웹 IDE 예시와 같은 교차출처 리소스 공유(CORS) 문제를 일으킬 수 있습니다.

예시:

// 나쁨 :(
// 만약 gitlab이 호스트명 `0.0.0.0`으로 구성된 경우
// 이것은 `localhost`에서 요청하면 CORS 문제를 일으킵니다
axios.get(joinPaths(gon.gitlab_url, '-', 'foo'))

// 좋음 :)
axios.get(joinPaths(gon.relative_url_root, '-', 'foo'))

또한, 프론트엔드에서 경로를 하드코딩하는 것이 아닌 백엔드에서 받아야 합니다. (다음 섹션 참조) 백엔드 레일즈 경로를 참조할 때는 *_url을 사용하지 말고 대신 *_path를 사용하십시오.

예시:

-# 나쁨 :(
#js-foo{ data: { foo_url: some_rails_foo_url } }

-# 좋음 :)
#js-foo{ data: { foo_path: some_rails_foo_path } }

6. 프론트엔드가 백엔드 경로를 어떻게 참조해야 하나요?

경로를 하드코딩하여 추가적인 커플링을 추가하는 것은 피하는 것을 선호합니다. 가능하다면 이러한 경로를 JavaScript에서 참조되는 DOM 요소의 데이터 속성으로 추가하세요.

예시:

// 나쁨 :(
// 여기에 경로를 하드코딩하는 Vuex 액션입니다 :(
export const fetchFoos = ({ state }) => {
  return axios.get(joinPaths(gon.relative_url_root, '-', 'foo'));
};

// 좋음 :)
function initFoo() {
  const el = document.getElementById('js-foo');

  // 경로는 우리의 루트 요소의 데이터에서 오므로 상태를 초기화하는 데 사용됩니다 :)
  const store = createStore({
    fooPath: el.dataset.fooPath
  });

  Vue.extend({
    store,
    el,
    render(h) {
      return h(Component);
    },
  });
}

// Vuex 액션은 이제 상태에서 경로를 참조할 수 있습니다 :)
export const fetchFoos = ({ state }) => {
  return axios.get(state.settings.fooPath);
};

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

가끔씩 프론트엔드 프로덕션 빌드가 어떤 결과물을 생성하는지 로컬로 테스트할 필요가 있습니다. 이를 위해서 다음 단계를 따릅니다:

웹팩을 중지합니다: 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을 실행합니다.
웹팩을 다시 시작합니다: gdk start webpack.
GDK를 다시 시작합니다: gdk restart rails-web.

8. 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에 추가해야 합니다.

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

병합 요청으로 이동합니다.
제목 아래의 보조 메뉴에서 파이프라인을 선택한 후, 보고 싶은 파이프라인을 선택하여 해당 파이프라인의 작업을 표시합니다.
compile-production-assets 작업을 선택합니다.
오른쪽 사이드바에서 작업 아티팩트로 이동한 후 탐색을 선택합니다.
webpack-report 폴더를 열고 index.html을 선택합니다.
페이지의 왼쪽 상단에서 우측 화살표()를 선택하여 탐색기를 표시합니다.
모듈 검색 필드에 gitlab/node_modules/core-js를 입력하여 로드되고 있는 폴리필을 확인합니다:

9. 다크 모드에서 페이지가 깨지는 이유

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

10. GitLab 특화 마크다운 렌더링 방법

만약 GitLab 특화 마크다운을 렌더링해야 한다면, 다음 두 가지가 필요합니다:

v-safe-html 지시문을 사용하여 Vue 컴포넌트 내부의 div HTML 요소에 GLFM 내용을 전달합니다.
적절한 CSS 스타일을 적용할 수 있도록 루트 div에 md 클래스를 추가합니다.

프론트엔드 FAQ