
인테리어 관련 물품을 쇼핑할수 있는 사이트입니다.
가구 부터 생활용품까지 다양한 카테고리와 필터 검색, 장바구니 등의 쇼핑기능을 제공합니다.
리액트는 가상 돔을 이용해 현재의 돔과 이전의 돔구조를 비교한 뒤 변화한 부분에 대해서만 실제 돔에 반영하는 특징이 있습니다. 이 원리를 이용해 반복되는 UI를 다시 그리지 않고 재사용 해 성능을 최적화 할 수 있는 장점이 있고 내일의집 프로젝트 같은 경우에도 헤더나 푸터, 카테고리의 사이드바와 같은 반복되는 UI에 대해 불필요한 렌더링을 최소화할수 있었습니다.
이전에 했던 devpost 프로젝트에서는 redux-saga를 적용했는데 ajax 요청을 하는 로직에 있어서 try catch 로직이 반복되며 길어진다는 점, 제너레이터 문법을 알아야하는 러닝커브 등의 단점이 있었습니다. redux-toolkit은 미들웨어 처리를 위해 제너레이터 문법을 사용할 필요도 없고, 기존에 리덕스를 프로젝트에서 사용하기 위해 redux-thunk등의 미들웨어, reducer 코드를 가독성 있게 작성하기 위한 immer, 디버깅을 위한 redux-devtools 등의 기능을 하나의 설치로 사용할 수 있는 점이 장점이었습니다.
필터기능을 구현하는 과정에서 2가지 방식을 구현했습니다.
URL에 쿼리스트링을 추가하고 페이지를 이동하는 방식
카테고리 페이지, 검색 페이지는 조건별로 필터를 적용해 상품을 찾아보는 용도의 페이지입니다. 따라서 브라우저의 뒤로가기나 앞으로 가기를 통해 필터의 특정 조건을 기억하고 되돌아갈 수 있는 방식으로 구현을 하는것이 사용자가 좀 더 편하게 페이지를 이용하는 방법이라고 생각했습니다. 카테고리 페이지에서는 필터를 적용하면 기존 도메인에 필터속성이 포함된 쿼리스트링을 추가하고 페이지를 이동시킵니다. 이동된 페이지는 초기에 쿼리스트링을 해석해 필터가 적용된 상품을 로드합니다.
페이지를 이동하지 않고 비동기 요청만 하는 방식
메인 페이지의 경우 간단하게 필터를 적용하고 둘러보는 용도로 구성했기 때문에 단순하게 비동기 요청을 통해 상품을 다시 로드 하도록 구현했습니다.
버튼필터 구현 시 패널UI에 문제가 있었습니다. 패널 UI 중 브랜드목록에 대한 UI는 브랜드 목록이 길어지면서 스크롤이 생기게 됩니다. 체크박스를 눌러 필터를 업데이트 하는 과정에서 리렌더링이 진행되고 기존에 움직였던 패널의 스크롤 부분이 초기화가 되는 문제가 있었습니다. 이 부분을 해결하기 위해 스크롤 위치를 기억하는 상태변수를 만들고 스크롤 이벤트를 통해 스크롤값을 기억하도록 했습니다. 그 다음 페이지를 이동했을 때, 기억했던 스크롤값으로 초기화를 하는 방식으로 스크롤 위치를 유지했습니다.
장바구니와 검색기록에 대한 데이터를 localstorage에 넣어 보관했습니다. 장바구니 같은 경우 상품 하나당 하나의 객체로 데이터를 생성하고 그 안에 속성으로 옵션데이터를 넣어 구성하였습니다. 장바구니 수량을 추가하거나 제거할때마다 localstorage에 있는 데이터를 가져와 수정한뒤 다시 localstorage를 업데이트 하는 방식으로 구현했습니다.
검색기록은 localstorage에 배열을 저장해놓고 검색창에 키워드를 입력해 검색 할 때 마다 로컬스토리지에 해당 키워드를 localstorage에 저장한 배열에 추가해서 업데이트하는 방식으로 구현했습니다.
제품 상세 페이지의 탭메뉴, 기획전 페이지(리퍼마켓, 빠른배송, 셀프인테리어)에서의 판매상품 보러가기 기능은 클릭했을 때, 특정 요소에 대한 스크롤 위치값을 계산해서 이동시키는 기능을 가지고 있습니다. 이 기능을 구현하기 위해 탭메뉴와 위치할 요소에 useRef를 생성해 연결하고 getBoundingClientRect().top - 184px 을 ScrollBy() 인자로 넣어 호출했습니다. 여기서 getBoundingClientRect().top 은 화면을 기준으로 하는 요소의 y축 값을 의미하고 184px은 헤더의 높이입니다. 그리고 이 값은 화면을 기준으로한 상대적인 값이기 때문에 ScrollTo() 가 아닌 상대적인 값으로 스크롤을 이동시키는 ScrollBy()를 사용했습니다.
리뷰, 문의글을 작성,수정,업데이트 하는 과정에서 목록을 어떻게 갱신할것인지에 대한 고민이 있었습니다. 처음에는 각 CRUD 기능의 백엔드 요청이 성공했을 시 데이터의 세부속성만 하는 수정하는 방식으로 구현을 했었습니다. 하지만 나 뿐 만 아니라 다른 유저의 수정사항도 목록을 업데이트 하면서 반영하는 것이 자연스럽다고 판단해 useEffect를 이용해 C,U,D요청이 성공할 때마다 목록을 새롭게 받아오는 dispatch 요청을 추가했습니다.
장점
1. 중첩방식(css nesting)으로 단순하고 가독성있게 css 코드 작성가능
2. @include 나 @fucntion 등의 문법으로 반복되는 css코드의 생산성 향상
3. scss 파일을 단위별로 폴더에 나누고, main.scss 에 전부 import하는 방식이 체계적이다.
단점
1. 자칫하면 classname 이 길어길 수 있는 단점이 있다.
2. @include @function 등의 문법을 너무 많이 사용하면 해당 문법을 확인하기위해 구조가 더 복잡해질 수 있다.
3. 중첩된 css 코드는 classname 을 수정할 때 아래에 있는 코드들도 전부 수정해야할 수도 있다.