[ HINES ] 프로젝트 소개
우리 팀은 오늘의 집 서비스를 클론코딩 하기로 결정했고, 오늘의 집에서 뻗어나가 ‘몇십년 후의 집’ 이라고 초기 컨셉을 잡게 되었다.
몇십년 후의 집을 영어로 해서 House in decades, 줄여서 '하인즈'로 프로젝트 이름을 정하게 되었다!
우리 팀은 몇십년 후의 집은 어떤 모습일지 고민하다가 우주 컨셉이 떠올라서 우주 컨셉의 인테리어 가구나 이동도구, 우주복 등 스토어쪽으로 구현해보는 것으로 목표를 잡았다.
( 오늘의 집의 커뮤니티 기능은 프로젝트 기간상 시간이 부족할 것 같아 제외하게 되었다. )
[ 프로젝트 목표 ]
- 그동안 학습했던 지식들을 2주 간의 팀 프로젝트에 활용
- 스타일컴포넌트를 이용한 초기 세팅부터 전부 실제 사용할 수 있는 서비스 수준으로 기획 및 배포까지 구현
[ 개발 기간과 팀 구성 ]
2021.12.13 ~ 2021.12.24
- Back-end 3명: 이유진 장도원 제갈창민
https://github.com/wecode-bootcamp-korea/27-2nd-Hines-backend
- Front-end 3명 : 이지현 홍정빈 황주영
https://github.com/wecode-bootcamp-korea/27-2nd-Hines-frontend
[ 사용된 기술 ]
Back-End: Python, Django, MySQL, Miniconda, AWS
Front-End: React.js, Styled-Component, React-router-dom.
Common : Git, Github, Slack, Trello, Notion
[ 구현 기능 소개 ]
[Front-End]
구현기능
- 상단바
- 소셜로그인(카카오)
- 제품 리스트 페이지
- 제품 상세 페이지
- 장바구니 페이지
- 구매 내역 페이지
※ 필자가 한 부분은 파란색으로 표시하여 두었습니다.
상단바 (header/nav)
- 스크롤시 카테고리부분이 고정
소셜로그인(카카오)
- 아이디, 패스워드가 일치해야 로그인 성공
- 로그인 성공시 sessionStorage에 토큰 발행
- 존재하지 않는 아이디로 로그인 시도시, 경고창 반환
- 존재하지 않는 패스워드로 로그인 시도시, 경고창 반환
제품 리스트 페이지
- 상세 리스트가 메인 화면이기 때문에 quary로 해당 부분을 관리
- 대분류, 중분류
- 대분류가 클릭 됐을 때 중분류 전체보기
- 상품 부분 클릭 시 상세 페이지로 이동
제품 상세 페이지
- useParams를 사용하여 백엔드로 부터 데이터를 받아 제품 표시
- 상품 개수 입력과 버튼으로 조절 가능
- 토큰 여부를 판단하여 구매버튼 클릭시 백엔드와 통신하여 장바구니로 담기
- query parameter 를 이용해 리뷰 부분을 페이지네이션으로 구성
장바구니 페이지
- 수량 입력
- 버튼으로 1단위 변화, 수량 직접 입력 가능
- 0, 빈칸 -> 수량을 1이 되도록 만듦
- 로그인하지 않았을 때 fetch를 하지 않게 하여 No Token 에러 없앰
- 전체, 부분 선택 가능
- 전체, 부분, 1개 삭제 가능
- 총금액은 체크된 상품만 계산
- 냉장, 상온 2개로 상품을 분류하여 소비자가 보기 편리하게 구성
- 분류별 토글 버튼을 만들어 해당 리스트 펼치거나 접을 수 있게 함
구매 내역 페이지
- 최신순으로 주문서 보여줌
[ 프로젝트 구현 영상 ]
https://www.youtube.com/watch?v=Z4Hw1AQc_og
[ 프로젝트 회고 - 프론트엔드 팀 ]
2차 프로젝트를 마치면서 프론트엔드팀, 백엔드팀과 전체적인 회고 시간을 가졌고 전체적인 소감의 결론은 백엔드팀과 많이 소통했다고 생각했는데 중간중간 변경되는 키 값에 대해서 더 소통하지 않아 통신하는 부분에서 수많은 에러를 발생시킨 점이 아쉬웠다고 얘기를 나누었다.
그리고 따로 프론트엔드 팀원들끼리 프로젝트에 대해 회고하는 시간을 가졌다. 회고 내용은 다음과 같다.
배운점
1. fetch를 통한 서버와의 통신 방법을 알게 되었습니다.
2. 비동기처리에 대하여 이해할 수 있게 되었습니다.
3. styled component 사용법에 대하여 이해하게 되었습니다.
4. 백엔드와 소통의 중요성을 알게 되었고, 서로의 언어를 일정부분 이해해야 한다고 생각했습니다.
5. 커스텀 훅의 사용법을 익혔습니다.
6. git rebase 사용하여 커밋을 깔끔하게 관리할 수 있었습니다.
느낀점
1. 팀 단위의 프로젝트를 통해 의사소통 능력 향상 및 협업의 중요성과 이해도를 향상 시키는 계기가 되었습니다.
2. 백엔드와 실질적인 통신을 해봄으로써, API에 대한 전반적인 이해도가 향상 되었습니다.
3. styled component, git rebase 등 새로운 기술을 적용해보면서 새로운 기술을 빠르게 적용하는 능력이 필요하다고 느꼈습니다.
4. 팀 프로젝트 진행 시 개인의 체력관리와 전체일정관리가 무엇보다 중요하다고 느꼈습니다.
아쉬운점
1. 적극적으로 프론트끼리의 소통이 더욱 필요했던 것 같고, 프, 백 간에도 작업중간중간 소통을 더욱 했으면 좋았던 것 같습니다.
2. 기능 구현에 초점을 맞춰서 사용자 중심의 UI를 고려하지 못했다. 그에 따라 CSS의 완성도가 부족했던 것 같습니다.
3. 첫 주의 협업 툴의 사용시에 있어서 업무 세분화가 체계적으로 안되어 아쉬웠지만, 2주차 때 checklist 활용을 통해서 업무를 분배하고 진행습니다.
[ 개인적인 회고록 ]
1차 프로젝트에서는 장바구니 기능을 맡으면서 REST API 의 중요성과 다양한 메서드들(GET, POST, PATCH, DELETE)에 대해서 배웠었다. 개인적으로 2차 프로젝트에서는 장바구니 같은 한 부분에 치중된 기능 말고 페이지를 전체적으로 다루고 싶은 마음과 최대한 많은 기능을 다뤄보고 싶다는 욕심이 났었고.. 그래서 소셜로그인과 path parameter, query parameter 를 다루는 로그인, 상세페이지를 맡게 되었다.
카카오 소셜 로그인
카카오소셜 로그인을 처음 해보면서 공식문서를 읽어야 했고 당연히 처음이라 공식 문서만 보고는 소셜로그인의 원리가 잘 이해가지 않았었다. 마침 나와 같이 통신하는 백엔드 분께서 소셜 로그인의 원리에 대해서 자세히 설명해주었고 그 후 어떤 흐름으로 돌아가는지 이해할 수 있게 되었다!
나는 카카오 소셜 로그인을 javascript 고급 팝업 방식으로 구현하였는데 카카오 로그인 동의화면을 클라이언트단에서 팝업 형태로 띄우는 형태이다. 로그인 버튼에서 클릭이벤트 핸들러로 Kakao.Auth.login 함수를 호출했고 동의를 완료하면 토큰이 발급완료 된다. 그럼 이제 그 토큰을 백엔드에게 전송하고, 백엔드는 그 토큰을 유저 정보만 빼서 재가공하여 다시 프론트에게 전달한다. 이때 나의 실수가 있었는데 동의항목을 따로 추가해야 되는지 몰라서 백엔드분과 몇시간 동안 헤맸었다. 그래도 이 경험으로 인해 카카오 소셜 로그인을 이해하게 되었달까....
상세 페이지
지난번 1차 프로젝트에서는 장바구니 기능에 너무 치중해서 (물론 얻은 건 많았다..) 모든 페이지의 연결이 어떻게 이루어지는지 몰랐는데 이번 2차 프로젝트를 해보면서 그 연결 원리를 알게 된 것 같다. (동적 라우팅, 페이지네이션)
1. 동적 라우팅
useParams 를 사용해 id 값을 알아내고 그 id 값을 백엔드에게 보내어 데이터를 받아 제품의 상세 정보를 표시하였다.
2. 상품 개수 입력과 버튼으로 조절 가능
이때 난항을 겪은 것이 플러스 버튼을 누르면 이벤트를 걸어주어 이벤트 핸들러 함수 안에서 상품 개수를 조작하도록 하였는데 이 함수 안에 setQuantity(quantity => quantity + 1) 과 같이 작성하였음에도 불구하고 콘솔 시 quantity 값이 증가하지 않았다. 하지만 전역에서 콘솔할 시, quantity 값이 제대로 작동되었다. 개발하면서 이게 대체 왜그런 것인지 너무나 궁금했고 골치가 아팠는데 옆에 동료분께서 이것은 리액트의 비동기 특성이라고 알려주셨다.
↓
setState 메서드는 비동기로 동작하기 때문이다. setState를 이벤트 핸들러 안에서 호출한다면. 호출되는 setState에 의해서 업데이트가 요청되는 state의 count의 값은 호출 이후 즉각적으로 반영되지 않는다. setState는 이벤트 핸들러 안에서 현재 state의 값에 대한 변화를 요청하기만 하는 것이고, 그 요청사항은 이벤트 핸들러가 종료되고 react에 의해서 효율적으로 상태가 갱신된다.
click = () => {
this.add(1); // count를 1 증가시켜줘 라고 react에게 요청한 상태
this.add(2); // count를 2 증가시켜줘 라고 react에게 요청한 상태
this.add(3); // count를 3 증가시켜줘 라고 react에게 요청한 상태
// ... 혹시 있을지모를 다른 행동을 모두 마친후
// 이벤트 핸들러가 종료되기 직전인 이곳에서 3가지 setState요청사항을 한번에 효율적으로 처리한다. 이후 렌더링 전에 update를 한다.
};
3. query parameter 를 이용해 리뷰 부분을 페이지네이션으로 구성
오늘의 집에서는 상품에 대한 리뷰가 페이지네이션 형태로 구성되어 있는데 나도 이 기능에 대해서 욕심이 생겼었다.
나는 특히 한 화면에 표시되는 리뷰 갯수는 5개로 제한하면서 리뷰 갯수가 15개면 버튼이 3개, 리뷰 갯수가 20개면 버튼이 4개... 이렇게 유동적으로 버튼을 만들고 싶었다. 그래서 그 로직까진 만들었는데 실제로 통신해보니 버튼이 계속 한개만 만들어져서 골머리를 앓았다. 알고보니 내가 백엔드분한테 리뷰를 5개씩 받아왔기 때문에 버튼이 1개만 계속 만들어졌었던 거였다. 그래서 백엔드분한테 내가 따로 리뷰 총 개수를 따로 받아야 버튼이 유동적으로 갯수가 만들어졌다. 그리고 이것이 실제로 구현되었을 때 너무 기뻤고 신기했던 것 같다.
총평
이번 2차 프로젝트에서는 리액트의 전체적인 기능을 맡게 되면서 리액트의 기초 개념에 대해서 다시 생각해보게 된 것 같다. 여기에 다 적지 못했지만 바보같이 기초 개념에 대해 간과해서 수많은 에러가 떴었다. 에러화면을 많이 마주친 그런 프로젝트로 기억이 남게 된 것 같다. 그래서 이번 프로젝트를 바탕으로 리액트의 특성에 대해서 다시 공부해보고 다시 내가 짠 코드에 대해서 생각해보는 시간을 갖기로 다짐했다.
'👯♀️ 프로젝트' 카테고리의 다른 글
| [개인 프로젝트] 푸시 알림 (0) | 2022.10.25 |
|---|