Vision
home
CLASS101 Vision
home
◼️

프론트엔드 코드 리뷰 가이드라인

목차
페이지 이동에는 항상 useGetUrl<PageLink />를 사용하세요.
Page 컴포넌트에는 로직을 작성하지 마세요.
새로 추가되는 코드에는 항상 최신 도구를 사용하세요.
컴포넌트에서 연산을 하지 마세요.
컴포넌트에서 필요한 데이터는 항상 훅에서 가져오세요.
훅을 재사용하지 않습니다.
인증이 필요한 경우 각 컴포넌트에서 별도로 처리하고, 스켈레톤을 표시하세요.
GraphQL 쿼리는 명사로 시작해야 합니다.
GraphQL 쿼리의 결과를 한번 더 가공하지 말고, 쿼리를 뷰에 맞추세요.
GraphQL 쿼리를 작성할 때, 모든 오브젝트에서 캐시 업데이트를 고려하세요.
useQuery의 skip 옵션을 적극적으로 사용하세요.
되도록이면 Mutation 후 아폴로 클라이언트의 캐시를 직접 조작하지 마세요.
Mutation의 성공 / 실패 이후 처리는 useMutation을 사용할 때 하면 좋습니다.
재사용이 가능해 보이는 코드는 항상 shared에 추가하려고 노력해 주세요.
코드는 만들어진 의도에 맞게 사용해야 합니다.
스토리북으로 컴포넌트의 실 사용 예시를 확인할 수 있도록 하세요.
ModalBottomSheet 컴포넌트를 사용할 때는 가능한 uncontrolled 모드를 사용하세요.
라이브러리의 API를 수정할 때는 코드 오너의 확인을 받으세요.

컴포넌트를 가능한 독립적으로 유지하세요.

컴포넌트가 다른 컴포넌트로부터 받는 속성이 많을수록(=다른 컴포넌트에 더 의존적일수록) 해당 속성이 어떻게 만들어진 것인지 확인해야 할 때 계속 부모 컴포넌트로 타고 올라가야 하고, 부모 컴포넌트의 로직이 복잡해지게 되며, 컴포넌트 재사용이 어려워집니다.
속성을 추가할 때마다 이 속성을 반드시 부모 컴포넌트로부터 받아와야 하는 것인지 고민해 보세요. 특히 자주 하는 실수가 쿼리의 결과를 자식 컴포넌트로 계속 전달하는 것입니다. 가능하다면 쿼리는 해당 결과를 사용하는 컴포넌트에서 실행하는 게 좋습니다.
예시 1
예시 2
예시 3

한 컴포넌트가 하나의 역할만 담당하게 하세요.

즉, 컴포넌트를 작게 만드세요. 작은 컴포넌트는 수정하거나 재활용하기 쉽습니다. 컴포넌트가 둘 이상의 역할을 하지는 않는지 항상 고민하세요. 한 컴포넌트가 받는 속성이 6개 이상이라면 이 컴포넌트가 둘 이상의 역할을 하지 않는지 의심해볼 수 있습니다.

가능하다면 항상 List 컴포넌트와 Item 컴포넌트를 분리하세요.

사실 위와 같은 내용입니다. 둘의 역할이 다르기 때문에 컴포넌트를 분리합니다. 또 Item 컴포넌트에서 직접 수행할 수 있는 동작을 List 컴포넌트에서 정의한 뒤 내려주지 않도록 합니다.
예시 1

함수의 이름으로 동작을 유추할 수 있도록 작명하세요.

특히 콜백 함수를 정의할 때, handleClick이나 handleChange 등의 이름을 종종 사용합니다. 이렇게 되면 컴포넌트의 특정 이벤트가 어떤 동작을 만들어 내는지 알기 어렵습니다.
예시 1

컴포넌트에 상하좌우 여백을 주지 마세요.

컴포넌트의 최상위 컨테이너에 margin을 주지 마세요. 테두리가 없는 경우라면 padding도 주지 마세요. 컴포넌트의 재사용이 어려워집니다.
예시 1

컴포넌트 사이에 간격이 필요하다면 되도록 spacing 속성을 사용하세요.

컴포넌트를 한번 더 Stack으로 감싸 margin을 주게 되면 불필요한 중첩이 생기게 됩니다.
예시 1

불필요한 Stack을 사용하지 마세요.

코드를 작성하며 구조를 변경하다 보면 의미 없는 스택 중첩이 생길 때도 있습니다. 리뷰 단계에서도 잘 걸러 줍시다.
예시 1

컴포넌트의 컨테이너 역할로 Fragment를 사용하지 마세요.

해당 컴포넌트의 배치가 부모 컴포넌트의 종류에 따라 달라질 수 있습니다. 부모 컴포넌트가 VStack이라면 세로 정렬, HStack이라면 가로 정렬이 되겠죠.
예시 1

가능한 emotion, styled-components 대신 OPS 컴포넌트를 사용하세요.

일관적인 디자인과 생산성 측면에서 많은 이득을 보게 됩니다. 디자인 시스템은 all or nothing 입니다. 커스텀 하는 순간 디자인 시스템을 사용하는 의미가 없어집니다.
예시 1

디자인 시스템 컴포넌트를 emotion, styled-components로 커스터마이즈 하지 마세요.

디자인 시안과 디자인 시스템이 다른 경우, 1) 디자인 시안을 디자인 시스템에 맞추거나 2) 디자인 시스템에 새로운 변형을 추가하고 해당 변형을 사용하세요.

되도록 React Element를 사용하지 마세요.

대신 OPS 컴포넌트를 사용하세요. 멀티 플랫폼 지원에도 유리합니다.
예시 1
더 궁금하다면, 바로 지원해서 문서 확인하고, 함께 코드리뷰 문화를 만들어나가는건 어떠실까요? 아래 채용공고 참고해주세요:)