한마디로 요약하면 내가 작성한 코드를 다른사람들도 쉽게 이해할 수 있게 가독성 있는 코드를 작성하는법에 대한 규칙이다.
code convention 의 궁극적인 목표는 다른 팀이 나의 코드를 fix할 수 있어야 한다고 생각합니다!
타입관리
interface vs Type alias: Type 선언은 각자 자유도를 가지고 선언
→ interface: 확장 가능
→ type: 확장 불가능
→ typescript는 type의 기능이 많고 강력한데 interface로 보수적으로 사용가능하다.
네이밍
- 줄임말 지양 (btn → button)
- 사전에 있는 줄임말은 허용(지양)
→줄임말 쓰면 내가아닌 다른 개발자가 줄임말을 봤을때 의미를 한번에 알아보기가 힘듬
- 함수
- 함수 이름만 보고 무슨 역할을 하는지 알 수 있도록 작성
→함수 이름이 난해하면 해당 함수가 어떤 역할을 하는지 함수 내부로직을 확인해야함
- 이벤트 핸들러
- 현재 컴포넌트 이벤트 핸들러 - on + eventName : onChangeInputValue
- props로 받는 이벤트 핸들러 - handle~ : handleChangeInputValue
생각하지 못했던 관점
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/Avatar2' => import { Avatar, Avatar2 } ffrom 'components/Avatar'
Avatar ㄴAvatar.jsx ㄴindex.js
폴더명
- 컴포넌트 폴더만 대문자로 시작