코드리뷰 정리 - 리액트 장바구니

컴포넌트

• 1 - 컴포넌트는 사용자가 쉽게 사용할 수 있도록 구현하는 것이 중요하다. 내가 직접 구현하고 내가 사용할 땐 구현하는 사람과 사용하는 사람이 일치하기 때문에 와닿지 않을 수 있는데, 내가 구현한 컴포넌트를 1년 후에 다시 사용한다고 생각해보자. 그러면 props로 어떤 값이 들어와야 하는지 잘 알지 못할 것이고, 그로 인해 내부 구현을 봐야 할 것이다. 내부 구현을 봤는데 여러 컴포넌트가 얽혀서 파악하기도 힘들고, 그렇게 되면 수정 사항이 생겼을 때, 수정하기도 힘들 것이다. 따라서 컴포넌트를 설계할 땐 수정하기도 쉽고, 사용자가 사용하기도 쉽게 설계하는 것이 중요하다.
• 2 - 프로젝트에서 디자인이 같다고 해서 한 컴포넌트에서 props로 스타일을 조정해서 사용하는 것은 좋지 않다. 왜냐하면 디자인이 같다고 해서 항상 같은 역할을 하는 것은 아니기 때문이다. 해당 미션에서는 장바구니 페이지와 주문 결제 페이지의 디자인이 같아서 한 컴포넌트에서 style만 변경해서 사용했었는데, 사실 장바구니와 주문 결제 페이지는 역할이 너무나도 다른 페이지이다. 그래서 디자인은 언제든지 변경될 수 있고, 만약 디자인이 변경된다면 해당 로직이 모두 바뀌어야 할 것이다. 이러한 불상사를 막기 위해 컴포넌트를 구성할 때 역할을 먼저 나누고, 디자인을 생각하는 것이 더 좋을 것 같다.

에러 바운더리

• 1 - 에러 바운더리는 화면 자체를 해당 컴포넌트로 바꿔버리기 때문에 사용자 경험 측면에서 좋지 않을 수 있다. 따라서 에러 바운더리는 해당 페이지를 찾을 수 없는 상황과 같이 큰 에러인 경우에만 사용하고, 일반적인 API 호출에 의한 에러 처리는 스넥바와 같은 것으로 사용자 경험을 해치지 않도록 하자.

리덕스

• 1 - 리덕스에서 액션 객체를 만들거나 함수를 만들 때, 데이터를 payload로 받기로 결정했다면, payload는 객체로 받는 것이 좋다. 왜냐하면 reducer에서 사용할 때, 모두 action.payload로 들어가기 때문에 현재 payload에 어떤 값이 담겨 있는지 확인할 수도 없고, 객체로 전달하게 되면 수정하는 것도 편리하기 때문이다. 이건 개발을 하면서 많이 느꼈던 부분이라서 공감이 되고, payload보다는 애초에 id면 id로 받는 것이 더 좋은 것 같다.

기타

• 기본 값 - localStorage와 같은 이미 만들어져 있는 api를 가지고 커스텀하게 함수를 만들 때에는 기본 값으로 해당 api의 스펙을 그대로 따라가도록 하자. localStorage의 스펙은 string | null을 리턴하기 때문에 기본 값으로 ""보다는 null을 지정하는 것이 옳다.
• 구조와 표현의 분리 - Flex 컴포넌트를 만들어서 인라인으로 css 속성을 주는 경우가 생기는데, 이 경우 구조와 표현의 분리가 되지 않는다는 측면으로 다시 생각해 볼 필요가 있다. 인라인으로 css를 주게 되면 구조인 HTML과 표현인 css가 한 군데로 섞이게 된다. 그렇게 되면 구조를 한 눈에 파악하기가 힘들어지고, 해당 css를 10군데에서 사용한다고 해도 10군데 각각에 인라인으로 css를 줘야 한다. 재사용이 전혀 되지 않는 것이다. 따라서 구조와 표현의 분리를 하는 것이 중요하다. 인라인으로 스타일을 주기 보다는 Flex 컴포넌트 내에서 스타일을 정의해두고 props로 받아서 사용하는 것이 더 좋아보인다.
• date-fns - 날짜 관련 라이브러리는 직접 구현하기보다는 라이브러리를 사용하는 것이 기능도 더 많고, 경량화도 잘 되어 있기 때문에 좋다. 추천하는 라이브러리는 date-fns이다.