-
Notifications
You must be signed in to change notification settings - Fork 2
[FitLink‐FE] 개발 컨벤션
📌 가능하면 최대한 Eslint, Prettier로 설정
줄임말은 쓰지 않는다. ex) e(이벤트 객체) → event
페이지와 컴포넌트 선언 Function 키워드를 사용하여 선언
핸들러/util 함수는 컴포넌트 내부에서 선언을 하고 const 키워드(arrow function)를 사용한다.
세미콜론을 필수적으로 작성 (prettier로 관리)
리터럴 값은 상수로 만들어서 사용합니다. 상수는 Snake Case를 사용합니다. ex) BASE_URL
변수명은 camelCase로 작성합니다.
라우트(폴더)명은 kebab-case를 사용합니다. ex) todo, user-info
컴포넌트명은 PascalCase를 사용합니다. ex) TodoList.tsx
alias를 이용해서 파일 절대 경로로 import, export 사용합니다
import a from './a'; ✅ 단일 레벨(뎁스)까지만 상대경로 가능 & 모두 동의 ✅ export 할때 barrel export 방식을 사용하지 않습니다.
-
타입을 분리할 경우(2군데 이상에서 사용할 경우) types 디렉토리에 관리한다.
컴포넌트의 Props는 컴포넌트를 선언한 파일내에 interface로 관리한다.
DTO 타입은 API 관련 디렉토리 내부의 types 디렉토리에 관리한다.
최대한 코드에 대한 설명 주석은 적지 않습니다. 이름만 읽어도 무슨 일을 하는 함수인지 알 수 있어야합니다.
-
이벤트 핸들러를 정의할때 handle + 이벤트명 + 대상로 정의합니다. ex. handleCopyLink
인라인 함수는 사용하지 않습니다.
on 접두사가 붙은 경우, 이 Prop에 실제 이벤트가 연결되어 있다는 걸 뜻하고, handle 접두사가 붙은 경우, 이벤트가 발생했을 때 호출되는 실제 Function을 의미합니다.
컴포넌트 props 지정 방식
type CommentListItemProps {...}
const CommentListItem = ({ id, author, loginId, createdAt, comment, isMyComment }: CommentListItemProps) => { ... }
컴포넌트 props 네이밍은 컴포넌트 네이밍 + Props로 지정한다.
asset 파일은 케밥 케이스를 사용하여 네이밍한다.
route 네이밍은 케밥 케이스 사용하여 네이밍
만약 주석이 필요한 경우 // TODO: 해야 할 일 혹은 한 일을 날짜와 함께 적어줍니다. ex) TODO: 2022.09.01
변수명이나 함수명이 길어도 좋으니 한눈에 봐도 알아볼 수 있는 최대한 명시적인 변수명을 정해줍니다. 단, 의미없거나 불필요한 접두사나 접미사가 붙는 것은 지양합니다. ex) currentTodoListData X ⇒ todoList O
선언부, 구현부 사이에는 줄 간격 해줍니다. 이외에 의미가 서로 다른 부분이라면 줄 간격 필수.
후위 연산자 사용하지 않습니다. ++, --
tsx를 반환하지 않는 ts 파일의 경우에는 함수 네이밍 + Parameters로 타입 이름을 생성한다.
페이지와 컴포넌트, 커스텀훅은 선언과 동시에 export default로 선언
children 타입은 ReactNode
h1, h2,…헤딩 태그들을 스타일용으로 사용하지말자. 접근성 위배
Fragment는 <> </>로 간단하게 선언
테스트 파일은 co-location하게 테스트를 진행할 파일과 같은 뎁스에 둔다
├─ packages
│ ├─ ui
│ │ ├─ stories
│ ├─ utils
│ ├─ tailwind-config
│ ├─ typescript-config
│ ├─ eslint-config
├─ apps
│ ├─ trainer // fonts 보류
│ │ ├— services // api 작업
│ │ ├— app // 페이지 단위마다 _components 추가
│ │ │ ├— page.tsx
│ │ │ ├— layout.tsx
│ │ │ ├— globals.css
│ │ ├— components // 에러바운더리, fallback UI, 스토리북 포함
│ │ ├— constants
│ │ ├— hooks
│ │ │ ├— queries // 이 안에서 API 별 관심사 나누어 작성
│ │ ├— public
│ │ ├— assets
│ │ ├— tests
│ │ ├— types
│ │ ├— utils
│ ├─ user
│ │ ├— services // api 작업
│ │ ├— app // 페이지 단위마다 _components 추가
│ │ │ ├— page.tsx
│ │ │ ├— layout.tsx
│ │ │ ├— globals.css
│ │ ├— components // 에러바운더리, fallback UI, 스토리북 포함,
│ │ ├— constants
│ │ ├— hooks
│ │ │ ├— queries // 이 안에서 API 별 관심사 나누어 작성
│ │ ├— public
│ │ ├— assets
│ │ ├— tests
│ │ ├— types
│ │ ├— utilsGit Flow 전략 사용
-
브랜치 네이밍 → prefix/#이슈번호/작업패키지
-
작업패키지
root, ui, trainer, user, config-eslint, config-typescript, config-tailwind
-
브랜치는 이슈 단위 브랜치
feature → dev 스쿼시 머지
release → main 레귤러 머지 + tag
release → dev 레귤러 머지
hotfix → main OR develop 레귤러 머지 + tag(마스터 머지시에만)
dev → main 레귤러 머지 + tag
| 태그 이름 | 설명 |
|---|---|
| feat | 새로운 기능 추가 |
| fix | 버그를 고친 경우 |
| style | CSS 등 사용자 UI 디자인 변경 |
| refactor | 기능 추가에 해당되지 않는 코드 리팩토링 |
| docs | 문서를 수정한 경우 |
| test | 테스트 관련 변경사항 |
| ci | CI 환경설정과 스크립트에 변화가 있는 경우 |
| chore | 자잘한 변경사항 + 외부 의존성 설치나 빌드 시스템에 영향을 주는 변경사항 |
| rename | 디렉토리 구조 변경, 함수 이름 및 파일 이름 변경 |
| merge | pull 과정 중 현재 커밋과 자동 병합이 일어날 때 필수적으로 적어줘야하는 커밋에 적어줌 |
# pr 제목은 아래와 같이 작성해주세요.
[#이슈 번호/작업 패키지] Commit Type: pr 제목
// 작업 패키지: root, ui, trainer, user, config-eslint, config-typescript, config-tailwind
📝 작업 내용
> 이번 PR에서 작업한 내용을 간략히 설명해주세요(이미지 첨부 가능)
📷 스크린샷 (선택)
💬 리뷰 요구사항(선택)
> 리뷰어가 특별히 봐주었으면 하는 부분이 있다면 작성해주세요
> ex) 메서드 XXX의 이름을 더 잘 짓고 싶은데 혹시 좋은 명칭이 있을까요?
close #이슈번호
이슈 생성은 작업을 진행할 작업 패키지(root, ui, trainer, user, config-eslint, config-typescript, config-tailwind)를 접두사로 사용 → Ex) [trainer] 트레이너 공통 컴포넌트 구현
## 🔨 설명
작업할 내용에 대해 상세하게 설명해주세요.commit(유의미한 작업 별로 쪼개서 자주 커밋)
Feat: commit 내용
바디 (좀 더 상세한 커밋 내용)
ex. Feat: make-home-page 컴포넌트 구현
- 컴포넌트 구현 완료(상세하게)
해당 이슈와 관련없는 커밋은 하지 않습니다. 관련없는 커밋이 필요하다면 새로운 이슈를 작성하고 브랜치를 변경해주세요. 첫 글자는 대문자로 적어주세요