RARRIT

기억을 너무 믿지 말자

:ledger: [5차] 스파르타 최종 프로젝트 - 공통 컴포넌트 제작

스파르타 코딩클럽 부트캠프 리액트 6기 최종 프로젝트 입니다.

:one: 공통 컴포넌트

이번 프로젝트에서 맡은 공통 컴포넌트는 아래와 같다.

  1. Modal
  2. Slide
  3. Pagination
  4. Card (캠핑 카드, 모임 카드, 후기 카드)

일반적으로 자주 사용되는 1~3번과 다른 파트 담당자들이 데이터를 패칭 후 해당 데이터에 맞게 보여지는 카드 ui를 제작해야 했는데, 1~3번에서 어려움이 많았다. 아무래도 내가 만든 컴포넌트를 가지고 자유롭게 커스텀도 가능해야하고, 필요한 최소한의 기능들이 구동되록 적용해야하기에, 작업하면서 고민과 문제가 정말 많았다.

또한 와이어 프레임이 없거나, 선행단계(데이터 패칭)가 없으면 대기해야하는 부분이 있어서 일정을 고려했을 때 기다리기만 하는 것 보다 더미데이터를 생성하여 진행하는 것이 맞다고 판단되었다.

:two: Modal

첫 작업을 공통 모달로 진행했는데, 생각보다 고려해야할 부분이 많았다. 모달의 타입도 어떤 유형이 들어올 지 몰랐고(와이어 프레임이 없음) 버튼도 x 버튼인지, 컨펌 타입인지, 이러한 부분을 고려하다보니 작업을 바로 시작하기보다 생각하는 시간이 많아졌고 처음 기능을 구현했을 때 문제가 많았다.

모달을 만들고 글을 작성하고 튜터님께도 피드백을 받았는데, 내용은 아래와 같았다.

  1. class로 사용하기 위한 용도인데 modalType이라는 이름의 props로 받아오는게 조금 어색해보여요ㅠ className을 받기 위한 용도라면 className으로 받는게 낫지 않을까요?? 아니라면 modalType이라는 이름으로 설정하신 특별한 이유가 있는걸까요??
  2. 공통 컴포넌트에 들어가는 props의 naming은 명확하게 적는게 좋습니다! wid -> width
  3. 닫기 버튼으로 모달을 닫아 모달을 닫아주는거 이외에 바깥쪽을 클릭 했을 때 닫을 수 있게 만들어주는게 좋아요! dimmed 라는 키워드로 검색해보시면 좋을거 같습니다:)
  4. 모달이 켜져있을 때, 모달 뒤 쪽 컨텐츠에 상호작용이 안되도록 추가적인 처리가 이루어지면 더 좋을거 같아요!

나름 생각하고 제작을 했다고 생각하지만, 코드리뷰 후 피드백을 보니 고려해야될 게 이렇게 있다니.. 그래도 이런 피드백은 언제나 환영이다. 이후에 리팩토링 기간에서 피드백 반영 및 추가적으로 업그레이드 할 예정이다.

:three: Slide

두번째 작업으로 슬라이드를 만들었는데, 이전에 자바스크립트로 슬라이드를 구현했기에 이번에도 직접 구현해보려했지만 기획단계 이후 기능 분배할 때 생각보다 일정이 많이 타이트하다 느껴져서 라이브러리를 사용해서 구현하기로 했다.

기본적인 옵션을 정의하고, 슬라이드 부분에서는 가장 먼저 사용한게 “나” 여가지고 문제점을 가장 먼저 알 수 있었다. 모달과는 다르게, 사용하기 어려움이 있어 1차 리팩토링을 진행했다. 변경된 PR 내용은 아래와 같다.

  • Slide.tsx
    • 기존: swiper 기본 옵션만을 사용해서 출력되게 되어있음
    • 문제발생: 슬라이드 안쪽 컨텐츠를 자유롭게 적용이 불가능함 (컴포넌트 내에서 지정한 컨텐츠만 노출됨)
    • 수정: 공통으로 사용하기 위해 children 으로 변경해주고, 데이터가 1개일 때 한개의 데이터만 노출될 수 있도록 조건부 처리해줌

위와 같이 수정하니, 팀원 분들께서 사용하면서 불편함은 없었는지 PR에 좋은 댓글을 달아줘서 뿌듯했다.

:four: Card

공통 카드 컴포넌트는 가장 쉽게 생각했으나, 이후에 수정을 했던 컴포넌트였다. 처음에 더미데이터를 활용해서 ui를 출력해주었는데, 1차 와이어프레임을 확인하고 카드 또한 유형이 다르게 들어간다는 것을 알게되었고, 이러한 부분에서 조건처리를 어떻게 하면 좋을지 고민을 하며 수정했다. 진행한 순서는 아래와 같다.

  1. 1차 카드 컴포넌트 제작
  2. 와이어프레임 확인 후 디자이너분께 타입이 몇가지가 있는지 확실히 체크
  3. 각 카드의 props를 통해 타입을 전달받을 수 있게 적용 후 조건부 렌더링 처리

위와 같이 진행했는데, 캠프 카드가 타입이 3가지여서 현재 2개의 타입만 처리가 되었는데.. 마지막 1개의 타입은 지도 부분까지 있어서 비즈니스 로직도 들어갈 것 같아서 걱정이 있다. 사실 이러한 부분에서 의문은 카드 컴포넌트 내에서 여러 타입을 조건부 처리하는 것이 맞는지? 아니면 컴포넌트를 추가해서 따로 제작하는 것이 맞는지 고민이 되었다. 현재는 1차로 작업 하고 각 파트 담당자에게 넘긴 상태인데, 캠프 카드의 타입 부분은 조금 더 고민하고 상급자에게 의견을 들은 후 리팩토링을 진행해봐야겠다.

:five: Pagination

개인적으로 가장 시간이 많이 걸렸던 공통 컴포넌트이다.. Next.js의 렌더링 방식도 고려해야 하고 어떤 데이터든 페이징 처리가 될 수 있게 제작되어야하는데, 이 부분은 작업 내용이 길었어서 이후에 글을 작성해보려한다.

:fire: 회고

이번 프로젝트에서 공통 컴포넌트 제작은 특히 팀원 간의 데이터 처리 방식, 다양한 유형의 UI 구현, 그리고 공통 컴포넌트의 재사용성 등 여러 경험을 할 수 있었다. 기능을 구현하면서 코드가 복잡하지 않고, 확장성과 사용성이 좋게 만드는 것이 정말 어려운 것 같다. 이전부터 라이브러리에 관심이 많았는데, 이번 경험을 통해 어떤 고민을 하게되었는지와 문제점은 어떤 것들이 있었는지 알 수 있게된 좋은 경험이었다.

참고