회의 안건
코드 컨벤션
커밋 컨벤션
기술 스택
기술 스택
- 타입스크립트
- Next.js - v13
- react-query
- recoil (다크 모드, 인증 관련 문제 혹은 궁금증이 생긴다면 비동기적으로 멘토님에게 질문하기)
- MUI / Emotion
- style lint, eslint
- prettier: 디폴트값도 적어주기 → 디폴트값이어도 prettierrc에 적어주지 않으면 vscode 설정을 따라가기 때문에 팀원과 차이가 발생할 수 있다.
- husky
- post css
- yarn
- msw
- nvm (lts: 18.14.0)
- 테스트 코드
이런 것도 있다~
- tsDocs
커밋 컨벤션
Git Commit Message
git commit -m 'feat: 로그인 비활성화 버튼 구현'- 내용 설명은 전부 한국어로 작성
→ 커밋에 사용하는 용어가 일치되지 않아서 혼돈을 일으킬 수 있다.
- 기능 구현 시 가능한 세부적으로 커밋지향 → 자기 상황에 따라서 (작은 이슈 작은 PR)
- 제목:
prefix: 명사형태로 작성
- 본문: 구현한 사항에 대해 간략하게 정리
- 구체적인 설명이 필요하다면 PR 메시지에 작성한다.
Prefix
분류 헷갈리면 팀원에게 질문하기
feat | 새로운 기능을 추가할 경우 |
fix | 버그를 고친 경우 |
rename | 파일 혹은 폴더명을 수정하거나 옮기는 경우 |
remove | 파일을 삭제하는 작업만 수행한 경우 |
design | CSS등 사용자 UI 디자인 변경 |
comment | 필요한 주석 추가/삭제/수정한 경우 |
docs | 문서를 수정한 경우 |
style | 코드 포맷(세미 콜론, prettier) 수정한 경우 |
refactor | 프로덕션 코드 리팩토링(변수명 개선 등) |
chore | 빌드 태스크 업데이트, 패키지 매니저 설정 (실제 production 코드 변경은 없음) ex. package.json 변경, 그외 자잘한 것 |
!HOTFIX | 급하게 치명적인 버그를 고쳐야하는 경우 |
코드 컨벤션
타입관리
interface vs Type alias: Type 선언은 각자 자유도를 가지고 선언
→ interface: 확장 가능
→ type: 확장 불가능
→ typescript는 type의 기능이 많고 강력한데 interface로 보수적으로 사용가능하다.
네이밍
- 줄임말 지양 (btn → button)
- 사전에 있는 줄임말은 허용(지양)
→줄임말 쓰면 내가아닌 다른 개발자가 줄임말을 봤을때 의미를 한번에 알아보기가 힘듬
- 함수
- 함수 이름만 보고 무슨 역할을 하는지 알 수 있도록 작성
→함수 이름이 난해하면 해당 함수가 어떤 역할을 하는지 함수 내부로직을 확인해야함
- 이벤트 핸들러
- 현재 컴포넌트 이벤트 핸들러 - handle~ : handleChangeInputValue
- props로 받는 이벤트 핸들러 - on + eventName : onChangeInputValue
ex)
<button onClick={handleClick}></button> <List onClick={onClick}></List>
생각하지 못했던 관점
react query useQuery 가져올 때 구조 분해 할당을 사용
→ isLoading을 꺼냈다면 이게 어디서 온 isLoading인지 명확하게 알기 어렵다(?)
→ 만일 useQuery가 두 개고 둘 다 구조 분해 할당을 사용했다면 isLoading에 별칭을 붙여야 하는데 굳이 그렇게 하기 보다는 그냥 구조 분해 할당을 사용하지 않는 방법도 있음 (ex. useQueryA.isLoading)
컴포넌트
- 컴포넌트 정의는 함수 표현식으로 사용 (arrow function)
export default function Icon() {} 처럼 export default를 같이 사용할 수 있다. 하지만 이런 장점을 빼고는 이미 다른 부분에서 arrow-function을 사용하는데 일치를 안시킬 이유가 없기때문에 사용
export default 에대한 관점
export를 사용시 “선언된 곳에서 이름이 의미상으로 크게 변경됐는데 사용하는 곳에서는 반영이 자동으로 되지 않으니 문제가 발생한다” 라는 의견이 나왔지만
이경우에는 해당 부분의 이름 설정이 잘못되었다고 생각됨.
따라서 무지성 export default는 비판적인 관점이었음
- 비지니스 로직과 UI 로직을 분리해야 할 정도의 코드 길이 로 분할
→ 관심사를 분리할 수 있다.
- type → component → style 순서
→ 컴포넌트 파일을 눌렀을때 주요 관심사는 style보다는 component의 생김새일 것이다.
따라서 우선순위가 낮은 style을 가장 아래에 쓰자
interface {} const Component = (:Props) => { Container } export default Component const Container = styled.div``
- 폴더 밑에 index.ts 만들고 폴더 안의 컴포넌트들 export
→ import 구문을 간략화 하고 하나의 파일에서 모두 불러오기가 가능하다.
import Avatar from 'components/Avatar/Avatar' import Avatar2 from 'components/Avatar/Avatar' => import { Avatar, Avatar2 } ffrom 'components/Avatar'
Avatar ㄴAvatar.tsx ㄴindex.ts
폴더명
- 컴포넌트 폴더만 대문자로 시작
→ 이거 무슨 얘기였지…