KREAM 클론 팀프로젝트 회고

팀프로젝트

우리가 사용할 API는 사용자가 제품 구매, 결제를 하고 관리자는 제품 등록, 관리를 할 수 있게 만들어져있다. 그리고 디자인보다는 우리가 공부하고있는 개발에만 집중하기 위해 디자인이 완성되어있는 크림 사이트를 클론하기로 했다.

Stacks

• Vite
• Vue3
• Vue-router
• Pinia
• Axios
• Eslint
• Swiper
• Sass
• Bootstrap

팀원

나를 포함한 총 4명

• 프로젝트 총괄, 사용자 로그인, 메인페이지
• 사용자 정보 수정, 계좌 설정, 구매 내역
• 사용자 검색, 구매
• 관리자 페이지

나는 사용자 검색 및 구매를 담당했다.

작업기

사용자 검색과 구매는 API만 보면 데이터 응답받아서 그냥 출력시켜주고 전송해주고 큰 어려움은 없어보였다. 그런데 우리는 완성된 디자인을 클론 하고있었다. 같은 디자인과 동일한 기능을 구현해야했다.

검색 페이지

검색 기능 구현 중 가장 힘들었던 건 하나의 버튼이 여러 컴포넌트와 연동되어있는 것이다.

신발 x 신발 x 신발이 보인다. 그리고 숫자가 보인다.
카테고리는 중복이 안되고 한가지만 선택이 가능하다. 만약 사용자가 다른 카테고리를 선택하고서 버튼을 클릭했다면? 사용자 입장에서 기존에 선택했던 카테고리는 자동으로 꺼졌으면 할거다. 근데 카테고리는 너~무 많다..대분류, 중분류까지 있는데 전부 API에 전송해여할 갔이다. 모두 데이터화하기 난잡할거 같아 정리된 코딩을 하기위해 정말 오래 고민했다.

만족스럽지 못한 방법으로 모든 카테고리를 하나하나 데이터화 했다. 다뤄야하는 데이터가 많아서 조건문도 길고 for문도 적지않게 쓰인거같다. 그래서 머리아팠다...왠지 아직도 이 기능을 구현하는 간결한 코드가 존재할거라 믿는다.

크림을 따라하기 때문에 정말 똑같이 따라하지 않으면 퀄리티가 떨어져보여서 이런 UX는 놓치기 싫었다. 사용하는 API를 최대한 사용해서 따라해보려했고 카테고리 코드 양은 아쉽지만 결과는 만족스럽다.

필터 버튼 동작과 함께 데이터 요청도 보내서 응답 값을 화면에 출력했다. 응답 데이터 양도 꽤 되기 때문에 스토어에서 바로 가져와서 코드양을 줄였다.

제품 상세페이지

데이터 타입에러가 지속적으로 발생했다. 돔이 형성 전에 미리 데이터를 응답 받아놓고 돔에서 데이터 바인딩을 통해 값을 출력하는 구조인데 데이터를 부르는 시기를 보면 에러가 발생하는 원인이 감도 안잡혔다. 왜냐면 타입에러가 떠도 값이 잘 불러졌다. 그러면 돔이 형성되고 바인딩된 데이터를 가져올때 에러가 한번 뜨고 다시 가져올때에 값이 나오는 경우니까 에러가 안뜨게 더 빨리 불러야하나? 싶었지만 created에서 불러오고 있어서 beforeCreate가 해법이 될 수 없었다.

타입에러는 언디파인드를 뱉고 있어서 불만이였다. 그래서 타입스크립트 타입 명시같이 데이터 초기화 값을 할당해줬다.

productInfo: {
  title: '',
  description: '',
  price: '',
  tags: []
}

바인딩되는 시기가 아니라 인내심이 문제였다. element에서 출력될 수 있는 데이터가 와야하는데 언디파인드가 뜨니까 참지못하고 "언디파인드가 오면 안돼!"라고 한거다. 그래서 언디파인드가 아니고 이런 타입이라고 알려줘서 인내심을 기르게 해줬다.😂

상세 페이지에는 완전히 따라하지는 못했다. 마감일이 다가오고있었고 우리의 목표는 API를 활용해 사용자가 주요 서비스를 사용할 수 있어야 했다. API가 제공하는 제품 데이터만 출력하고 디자인 구조를 위해 몇몇 요소를 더 추가하는 방식으로 진행했다. 그러면서 UX를 해치지 않도록 기존 크림에서처럼 필요한 UX, UI도 반영했다.

제품 구매

저 버튼에는 부트스트랩 모달창이 숨어있다. 그래서 제품 상세페이지가 렌더될때 모달창 컴포넌트도 렌더되는데 그 안에 데이터 에러가 발생했다. ref 이름이 중복됐나? 자바스크립트로 DOM 접근을 해야하나? 문제는 v-if였다. v-if와 v-show에 차이를 알고있었지만 전혀 문제일거라고 상상도 안해봐서 계속 다른곳에서 문제를 찾고있었다. 코딩하면서 스스로에게 어이없던 적이 한번씩은 생기는거 같다.😂 v-if는 트루값을 주기 전까지는 DOM이 형성되지 않기 때문에 데이터 에러가 발생했던거다.

구매에서는 내가 짜놓은 구조에서 API로는 라우터 인증을 사용할 수 없었다. 그래서 직접 조건문을 넣어줬다. 사용자가 구매하기 위해서 계좌 데이터가 있어야한다. 그래서 계좌 데이터로 로그인 상태 검사를 했다. 로그인 계정만 있고 계좌를 만들지 않아도 빈 배열이 생성되기 때문에 null값의 조건을 걸었다. 제품 구매를 위해서는 3가지 검사를 통과해야 한다.

1. 로그인 인증
   
2. 연결 계좌 검사
   
3. 잔액 검사
   

만들고 보니 살짝 구매 인증 단계가 부실한거 같기도 하다. 다음에는 더 탄탄하게 구조를 짜봐야겠다는 생각이 든다. 연결된 계좌가 없을 때에 더 뚜렷한 안내라던가 구매가 이뤄지지 않을때 어떤 문제인지 분류해 안내해주는 방식도 생각해볼 수 있다.

헤더 검색

root에 위치하는 header이다. 검색어를 프론트단에서 주고받고서 검색페이지에서 서버로 전송 해야했다. 헤더에서 검색을 하면 검색페이지 이동이 되서 검색어 데이터가 초기화되는 현상을 해결해야하는 방법이 필요했다. 컴포넌트에 종속되지 않는 데이터는 브라우저 스토리지라고 생각했다.

검색어는 헤더에서 출발해서 검색페이지를 이루는 2개의 컴포넌트로 전달되어야 했다. 그래서 로컬스토리지를 활용했다. 세션스토리지를 쓰지 않은 이유는 1개 데이터를 부르는 한가지 방식으로 두가지 활용을 하고싶었다.

1. 검색어 전달
2. 최근 검색어

사용자 입장에서는 다음에 들어왔을 때도 최근 검색어가 필요한 경우가 있을테니까 로컬스토리지가 좋겠다는 생각을 했다. 잘 구현하고 동작 시켜보니 헤더로 검색하지 않고 바로 검색페이지로 접근해도 최근 검색어로 검색된 제품들을 보여줬다. 그래서 세션스토리지를 활용해서 헤더 검색에서 왔는지를 검사하는 코드도 짰다.

이렇게 해서 내가 담당한 파트는 완성이 됐다. 더 많은 어려움들이 새롭게 겪었고 내 부족함이 많이 느껴졌던 프로젝트이다. 완전하지 않은 API를 쓰면서 백엔드와 협업도 생각해보고 팀 프로젝트하면서 git-flow를 꽤 좋게 사용하기도했다. 예상보다 깃플로우가 팀 협업을 많이 편하게 해줬다. 서로 소통하며 빌드하는 과정도 좋았고 팀플이라는 용어에 좋은 기억이 덮어진거 같아 팀원분들께 고맙다.

얻은 것, 깨달은 것

1. vue 활용도 상승
2. pinia 활용도 상승
3. 디자인만 보고도 구조가 떠오른다.
4. vite에서 이미지를 동적으로 불러오는 법
5. 라우터 children의 쓰임과 라우터에서 dynamic import는 추천하지 않는다.
6. 데이터 객체화
7. 데이터 초기화의 중요성
8. 컴포넌트간에 데이터 바인딩
9. 라이프사이클 활용성
10. 여러 store로부터 데이터 가져오기
11. 백엔드 필요성

최종 작업물

KREAM 클론