과제 체크포인트
배포 링크
https://yeongseoyoon-hanghae.github.io/front_6th_chapter1-1/
기본과제
상품목록
상품 목록 로딩
- 페이지 접속 시 로딩 상태가 표시된다
- 데이터 로드 완료 후 상품 목록이 렌더링된다
- 로딩 실패 시 에러 상태가 표시된다
- 에러 발생 시 재시도 버튼이 제공된다
상품 목록 조회
- 각 상품의 기본 정보(이미지, 상품명, 가격)가 카드 형태로 표시된다
한 페이지에 보여질 상품 수 선택
- 드롭다운에서 10, 20, 50, 100개 중 선택할 수 있으며 기본 값은 20개 이다.
- 선택 변경 시 즉시 목록에 반영된다
상품 정렬 기능
- 상품을 가격순/인기순으로 오름차순/내림차순 정렬을 할 수 있다.
- 드롭다운을 통해 정렬 기준을 선택할 수 있다
- 정렬 변경 시 즉시 목록에 반영된다
무한 스크롤 페이지네이션
- 페이지 하단 근처 도달 시 다음 페이지 데이터가 자동 로드된다
- 스크롤에 따라 계속해서 새로운 상품들이 목록에 추가된다
- 새 데이터 로드 중일 때 로딩 인디케이터와 스켈레톤 UI가 표시된다
- 홈 페이지에서만 무한 스크롤이 활성화된다
상품을 장바구니에 담기
- 각 상품에 장바구니 추가 버튼이 있다
- 버튼 클릭 시 해당 상품이 장바구니에 추가된다
- 추가 완료 시 사용자에게 알림이 표시된다
상품 검색
- 상품명 기반 검색을 위한 텍스트 입력 필드가 있다
- 검색 버튼 클릭으로 검색이 수행된다
- Enter 키로 검색이 수행된다
- 검색어와 일치하는 상품들만 목록에 표시된다
카테고리 선택
- 사용 가능한 카테고리들을 선택할 수 있는 UI가 제공된다
- 선택된 카테고리에 해당하는 상품들만 표시된다
- 전체 상품 보기로 돌아갈 수 있다
- 2단계 카테고리 구조를 지원한다 (1depth, 2depth)
카테고리 네비게이션
- 현재 선택된 카테고리 경로가 브레드크럼으로 표시된다
- 브레드크럼의 각 단계를 클릭하여 상위 카테고리로 이동할 수 있다
- "전체" > "1depth 카테고리" > "2depth 카테고리" 형태로 표시된다
현재 상품 수 표시
- 현재 조건에서 조회된 총 상품 수가 화면에 표시된다
- 검색이나 필터 적용 시 상품 수가 실시간으로 업데이트된다
장바구니
장바구니 모달
- 장바구니 아이콘 클릭 시 모달 형태로 장바구니가 열린다
- X 버튼이나 배경 클릭으로 모달을 닫을 수 있다
- ESC 키로 모달을 닫을 수 있다
- 모달에서 장바구니의 모든 기능을 사용할 수 있다
장바구니 수량 조절
- 각 장바구니 상품의 수량을 증가할 수 있다
- 각 장바구니 상품의 수량을 감소할 수 있다
- 수량 변경 시 총 금액이 실시간으로 업데이트된다
장바구니 삭제
- 각 상품에 삭제 버튼이 배치되어 있다
- 삭제 버튼 클릭 시 해당 상품이 장바구니에서 제거된다
장바구니 선택 삭제
- 각 상품에 선택을 위한 체크박스가 제공된다
- 선택 삭제 버튼이 있다
- 체크된 상품들만 일괄 삭제된다
장바구니 전체 선택
- 모든 상품을 한 번에 선택할 수 있는 마스터 체크박스가 있다
- 전체 선택 시 모든 상품의 체크박스가 선택된다
- 전체 해제 시 모든 상품의 체크박스가 해제된다
장바구니 비우기
- 장바구니에 있는 모든 상품을 한 번에 삭제할 수 있다
상품 상세
상품 클릭시 상세 페이지 이동
- 상품 목록에서 상품 이미지나 상품 정보 클릭 시 상세 페이지로 이동한다
- URL이
/product/{productId}
형태로 변경된다 - 상품의 자세한 정보가 전용 페이지에서 표시된다
상품 상세 페이지 기능
- 상품 이미지, 설명, 가격 등의 상세 정보가 표시된다
- 전체 화면을 활용한 상세 정보 레이아웃이 제공된다
상품 상세 - 장바구니 담기
- 상품 상세 페이지에서 해당 상품을 장바구니에 추가할 수 있다
- 페이지 내에서 수량을 선택하여 장바구니에 추가할 수 있다
- 수량 증가/감소 버튼이 제공된다
관련 상품 기능
- 상품 상세 페이지에서 관련 상품들이 표시된다
- 같은 카테고리(category2)의 다른 상품들이 관련 상품으로 표시된다
- 관련 상품 클릭 시 해당 상품의 상세 페이지로 이동한다
- 현재 보고 있는 상품은 관련 상품에서 제외된다
상품 상세 페이지 내 네비게이션
- 상품 상세에서 상품 목록으로 돌아가는 버튼이 제공된다
- 브레드크럼을 통해 카테고리별 상품 목록으로 이동할 수 있다
- SPA 방식으로 페이지 간 이동이 부드럽게 처리된다
사용자 피드백 시스템
토스트 메시지
- 장바구니 추가 시 성공 메시지가 토스트로 표시된다
- 장바구니 삭제, 선택 삭제, 전체 삭제 시 알림 메시지가 표시된다
- 토스트는 3초 후 자동으로 사라진다
- 토스트에 닫기 버튼이 제공된다
- 토스트 타입별로 다른 스타일이 적용된다 (success, info, error)
심화과제
SPA 네비게이션 및 URL 관리
페이지 이동
- 어플리케이션 내의 모든 페이지 이동(뒤로가기/앞으로가기를 포함)은 하여 새로고침이 발생하지 않아야 한다.
상품 목록 - URL 쿼리 반영
- 검색어가 URL 쿼리 파라미터에 저장된다
- 카테고리 선택이 URL 쿼리 파라미터에 저장된다
- 상품 옵션이 URL 쿼리 파라미터에 저장된다
- 정렬 조건이 URL 쿼리 파라미터에 저장된다
- 조건 변경 시 URL이 자동으로 업데이트된다
- URL을 통해 현재 검색/필터 상태를 공유할 수 있다
상품 목록 - 새로고침 시 상태 유지
- 새로고침 후 URL 쿼리에서 검색어가 복원된다
- 새로고침 후 URL 쿼리에서 카테고리가 복원된다
- 새로고침 후 URL 쿼리에서 옵션 설정이 복원된다
- 새로고침 후 URL 쿼리에서 정렬 조건이 복원된다
- 복원된 조건에 맞는 상품 데이터가 다시 로드된다
장바구니 - 새로고침 시 데이터 유지
- 장바구니 내용이 브라우저에 저장된다
- 새로고침 후에도 이전 장바구니 내용이 유지된다
- 장바구니의 선택 상태도 함께 유지된다
상품 상세 - URL에 ID 반영
- 상품 상세 페이지 이동 시 상품 ID가 URL 경로에 포함된다 (
/product/{productId}
) - URL로 직접 접근 시 해당 상품의 상세 페이지가 자동으로 로드된다
상품 상세 - 새로고침시 유지
- 새로고침 후에도 URL의 상품 ID를 읽어서 해당 상품 상세 페이지가 유지된다
404 페이지
- 존재하지 않는 경로 접근 시 404 에러 페이지가 표시된다
- 홈으로 돌아가기 버튼이 제공된다
AI로 한 번 더 구현하기
- 기존에 구현한 기능을 AI로 다시 구현한다.
- 이 과정에서 직접 가공하는 것은 최대한 지양한다.
과제 셀프회고
이번 과제를 통해 SPA의 구조적 설계와 상태 관리의 중요성을 깊이 알 수 있었습니다. 특히 "어떻게 구현할 것인가"에 대한 고민이 더 중요하다는 것을 깨달았습니다. 초기에는 빠르게 기능을 만드는 데 집중했지만, 테스트가 깨지고 코드가 복잡해지면서 근본적인 구조 개선의 필요성을 느꼈습니다. 또 과제를 진행하면서 여태까지는 SPA를 사용하지만 그에 대한 명확한 이해가 없이 실무를 하고 있었다는 느낌이 들었습니다. 이번에 과제를 진행하면서 생각보다 테스트코드나, 전반적인 SPA관련된 구조를 짜는 것에 있어서 쉽지 않았고 기능을 구현하더라도 테스트 코드가 깨지면 과제가 fail된다는 생각에 테스트 코드를 신경쓰며 진행하다보니 약간의 병목이 있었던것같습니다.(그래도 그 과정을 해결하면서 테스트 코드의 의미를 생각해보게 된 것 같아 재미있었습니다 ㅎㅎ)
기술적 성장
새로 학습한 개념
-
createComponent 패턴 컴포넌트의 라이프사이클(mount/unmount)을 체계적으로 관리하는 방법을 학습했습니다. 단순히 HTML을 반환하는 함수에서 상태와 이벤트까지 관리하는 구조화된 컴포넌트로 발전시킬 수 있었습니다.
-
관심사 분리의 실제 적용 이벤트 핸들러가 DOM을 직접 조작하는 것이 왜 문제인지 실제로 경험했습니다. updateCartIcon() 같은 함수들이 상태 변경과 DOM 조작을 동시에 하면서 코드 흐름을 예측하기 어렵게 만든다는 것을 깨달았습니다.
-
상태 기반 렌더링 React의 원리를 바닐라 JS로 구현하면서 왜 상태가 변경되면 UI가 자동으로 업데이트되어야 하는 좀 더 깊게 이해할 수 있었습니다.
-
단방향 데이터 흐름 이벤트 → 상태 변경 → 템플릿 렌더링의 흐름을 정리하면서 코드의 예측 가능성이 올라감을 느꼈습니다.
-
Layout Shift 문제 GitHub Pages 배포물을 확인했을때 초기 로딩 시 JavaScript 로드 전후의 화면이 완전히 달라 사용자 경험이 나빴던 문제를 해결했습니다. index.html을 실제 앱 구조와 동일하게 구성하여 스켈레톤 UI로 자연스러운 전환을 구현했습니다.
자랑하고 싶은 코드
에러 발생시 구현 부분
테스트에는 없지만 체크박스에는 존재하여 에러가 발생하는 경우에 error토스트 메시지를 발생시키고, 다시 시도를 하는 영역이 노출되도록 구현하였습니다.
https://github.com/user-attachments/assets/0e5dd34a-0ab8-410f-8f24-c696f18ac8d2
관심사 분리를 통한 코드 개선
// Before: 이벤트 핸들러에서 DOM 직접 조작
const updateCartIcon = () => {
const { itemCount } = cartStore.getState();
const cartIconBtn = document.querySelector("#cart-icon-btn");
if (cartIconBtn) {
const countSpan = cartIconBtn.querySelector("span");
if (itemCount > 0) {
if (!countSpan) {
const span = document.createElement("span");
span.className =
"absolute -top-1 -right-1 bg-red-500 text-white text-xs rounded-full h-5 w-5 flex items-center justify-center";
cartIconBtn.appendChild(span);
}
cartIconBtn.querySelector("span").textContent = itemCount;
} else {
if (countSpan) {
countSpan.remove();
}
}
}
};
기존에 이벤트 핸들러에서 DOM을 직접적으로 조작하고 있었는데, 이것은 이벤트 핸들러의 관심사가 아니라고 생각이 들었습니다. 따라서 이벤트 핸들러에서는 상태의 값을 가져와 상태만 변경하고, 렌더링 시키도록 리팩토링했습니다.
createComponent 패턴 적용
사실 이부분은 준일님의 코드에서 영감을 받았습니다. 수요일에 멘토링을 받으면서 다음과 같은 질문을 드렸었는데요,
처음에는 클래스로 구현하려고 했는데, 클래스가 익숙하지 않아서 함수 형태로 구현하게 되었습니다. 그런데 함수로 구현하다 보니 클래스보다 코드가 지저분해진 것 같아서 고민이 됩니다. 제가 생각하기로는 클래스는 상속을 통해서 속성을 받을 수 있고 패턴을 좀 더 강제할 수 있는 것 같은데, 함수는 자유도가 높은 대신 패턴을 강제하기가 어려운 것 같습니다. 함수형 방식에서도 어떻게 하면 일관된 패턴을 강제할 수 있을까요? 준일님은 함수로 코드 작성을 하신것으로 알고있는데…이부분에 대해서는 어떻게 처리하셨는지도 궁금합니다
준일님께서는 createComponent와 같이 팩토리 함수 패턴을 활용하면 함수형 방식에서도 일관된 구조를 강제할 수 있다고 조언해주셨습니다. 그러나 createComponent를 그대로 바로 사용하게 되면 제 코드로 온전하게 구현해보지 못할것같아 일단 기능을 모두 구현하고나서 리팩토링 하기로 결정했습니다.
이전 코드는 다음과 같았습니다.
const MyFunction = () => "hello";
MyFunction.onMount = () => { /* 뭔가 이상함 */ };
Javascript를 사용하면서 타입 추론이 되지 않는 상황에서 억지로 onMount를 붙이고, render함수에서 onMount 속성을 가지고 있는지에 따라서
리팩토링한 코드는 241ed18커밋 이전과 이후로 확인해보실 수 있습니다.
// 요런 느낌
const HeaderComponent = createComponent(
renderHeader,
{ title: "쇼핑몰", showBackButton: false },
{
mount: () => {
addEvent("click", "#cart-icon-btn", handleCartIconClick);
},
},
);
팩토리 함수 패턴을 실제로 적용해보니 모든 컴포넌트가 동일한 형태를 갖게 되어 좀 더 일관된 형태를 가지게 되었습니다. 클래스의 상속이 주는 구조적 이점을 함수형 방식에서도 얻을 수 있었고, 동시에 함수형의 간결함도 유지할 수 있었다고 생각합니다.
Pub-Sub 패턴 기반의 상태 관리 구조
Pub-Sub(발행-구독) 패턴을 활용하여 상태를 관리하도록 설계하였습니다. 각각의 상태는 구독 기능을 제공하며, 상태가 변경될 때마다 구독자(컴포넌트, 렌더 함수 등)에게 변경 사실을 알리고, 구독자는 이에 따라 UI를 갱신하거나 필요한 동작을 수행합니다.
이를통해 상태 변경시 모든 구독자에게 알림이 가고, 구독자는 UI를 갱신하거나 필요한 동작을 수행하여 좀 더 예측할 수 있는 단방향 플로우로 구현되었다고 생각합니다.
사용한 유틸 함수들
-
createObserver와 createState Pub-Sub 패턴 구현을 위한 기반 유틸들입니다. createObserver를 통해 기본적인 구독-알림 패턴을 구현하고, 역할과 책임의 분리를 위하여 createObserver의 함수를 사용하여 createState를 구현해 상태를 관리하고 업데이트하도록 했습니다.
-
무한스크롤 관련 유틸들 처음에는 Intersection Observer API를 통해 무한스크롤을 구현하고 싶었으나 jsdom에서 Intersection Observer API를 지원하지 않아 폴리필이 필요하다고 판단하였고, 과제를 진행함에 있어 병목이 일어날 것이라고 판단하였습니다. 때문에 Intersection Observer API를 미지원할때의 일반적인 방식인 스크롤 위치 기반 방식으로 진행하였습니다. 스크롤이 하단의 어느 위치에 위치해있는지를 판단하는데 이때 쓰로틀링을 통하여 너무 자주 발생하는 것을 막도록 했습니다.
- updateElement: 요소의 내용을 교체할때 좀 더 선언적으로 작성하고 싶어 구현한 유틸입니다. 특정 영역의 UI를 빠르게 갱신할 때 사용합니다.
- createElement: HTML 문자열(템플릿)을 실제 DOM 요소로 변환합니다. createComponent는 위에서도 언급되는 내용이라 넘어가겠습니다.
개선이 필요하다고 생각하는 코드
이번에 상태 변경시에 리렌더를 진행하면 DOM을 다시 그리면서 새롭게 돔을 가져오게 되는데, 그러면서 2. 장바구니 수량 조절
에서 난항이 있었습니다. document.querySelector를 통해 요소를 찾고 변수에 담아놓으니 이전의 DOM객체를 참조하고 있어 새롭게 DOM을 가져왔는데도 이전 DOM 요소의 value를 찾고있다보니 값의 변경이 없는 것처럼 보이는 이슈였는데요.
이 부분에 대해서 준일님이 상태가 변경될때 돔을 다시 그리는것이 아니라 변경된 값만 다시 변경하면 이슈가 없을 것이라고 말씀주셨고...사실 알고는 있었는데 이미 설계가 그러한 방식으로 되지 않은 상황이라 시간 관계상 테스트 상에서 매번 새로 DOM을 찾아서 참조하는 방식으로 해결했습니다.
const quantityInput = document.querySelector(".quantity-input");
expect(quantityInput.value).toBe("2");
await userEvent.click(decreaseButton);
// 수량이 감소했는지 확인
expect(document.querySelector(".quantity-input").value).toBe("1"); // 여기서 document.querySelector(".quantity-input") 이렇게 새롭게 호출
또한 처음에는 react router dom의 형태와 비스무리하게 구조를 가져가고 싶어서
export const useLocation = () => {
return {
pathname: getAppPath(),
state: window.history.state,
};
};
위와 같은 함수를 만들었었는데, 이런 유틸함수들을 미사용했던 것도 아쉬움이 남는 것 같습니다.
학습 효과 분석
배포를 진행하면서 다른분들을 도와드리고 gh-pages를 통한 spa 배포에 대한 이해가 높아진 것 같습니다...ㅎㅎ;; 이렇게 다양한 에러를 접하게 될 줄은...
과제 피드백
사실 과제에서의 기능 구현에 대해서는 너무 재밌었다고 생각이 드는데, 이전에도 말씀드렸던 것과 같이 좀 더 명확한 요구사항이 있으면 좋을 것 같습니다. 요컨데 지금은 카테고리와 상품을 동시에 불러야한다는 요구사항이 없고, 테스트 코드상에서 다음과 같이 상품은 findByText를 통해 찾고 카테고리는 getByText를 통해서 찾게되어 '동시에 불러야한다는'의미가 조금 모호하지 않나라는 생각이 들었습니다. 차라리 요구사항에 언급하고, 테스트는 느슨하게 둔다거나하면 준일님께 문의가 좀 줄지 않을까...🥹 하는 생각이..(ㅋㅋㅋㅋ)
await screen.findByText(/총 의 상품/i);
const target = screen.getByText("생활/건강");
그리고 RTL의 내장함수들을 사용하는것이 아닌 querySelector를 사용하는 코드가 많았는데 테스트가 불안정하고, 디버깅도 어렵다는 생각이 들었습니다. 요 부분도 다음 기수에 반영이 되면 어떨까...하는 생각이 들었습니다 ㅎㅎ...
AI 활용 경험 공유하기
커서를 사용했고 보통적으로 귀찮은 일들에 대해서는 커서한테 전반적으로 위임했습니다...ㅎㅎ 예를들어 컴포넌트를 분리해달라거나 기존의 준일님께서 주신 템플릿과 현재 제 코드의 스타일이 다른 부분이 있으면 찾아달라거나, 혹은 spa관련 코드를 작성하고나서 좀 더 깔끔하게 정리해줄수는 없을지를 묻는다거나...
사실 AI를 사용함에 있어서 그렇게까지 잘 사용하고있는지는 모르겠고, 좀 더 제가 처해있는 상황을 설명하려고 하면 말을 잘 알아듣는 느낌이었습니다. (요건 프롬프트 엔지니어링을 잘 몰라 그럴 수도 있겠습니다만) 빠르게 컴포넌트를 분리하는 과정에서 디자인등이 누락되는것들이 있었는데, 그 이전에 디자인을 누락하지 않고 그대로 분리해달라고 좀 더 자세히 명세를 하면 제가 의도한 바와 동일하게 작성해주는것 같았습니다.
한계점이 있다면 전체적인 아키텍처 설계나 근본적인 문제 해결은 여전히 사람이 판단해야 했습니다. AI가 제안한 코드도 결국 테스트를 통해 검증하는 과정이 필요했습니다
리뷰 받고 싶은 내용
저는 장바구니 스토어를 클라이언트+로컬 스토리지의 조합으로 사용중에 있는데요, 테스트에서 현재처럼 명시적으로 로컬스토리지를 클리어해주는 경우(클라이언트+로컬스토리지를 비워주는 래핑함수가 아닌경우) 어떻게하면 클라이언트 상태를 비워줄 수 있을지를 고민하다 테스트코드에 추가하여 초기화했습니다. (beforeEach에서 초기화 하는것이 바람직하다고 생각하긴하지만 그건 넘어가겠습니다)
이렇게 로컬스토리지를 명시적으로 초기화하는경우에 어떻게하면 클라이언트에서도 상태가 비워짐을 알 수 있을까요?
어제 갑자기 생각나서 해본 방법은 storage+CustomEvent를 통해서 스토리지 이벤트를 현재탭, 다른 탭에서도 구독하게하고 이를 동기화해주는 방식인데 제대로 안돼서 여쭤봅니다..! 또 다른 방법으로는 setInterval으로 계속 주기적으로 값을 확인하는 방법이 있을거같긴한데, 요건 너무 야매같아서요 아니면 제가 코드를 잘못 짰을지...🥹(모든 곳에서 계속 로컬스토리지 관련 메소드를 호출하고싶진 않아서 내부 클라이언트 상태를 두었습니다)