bebusl 님의 상세페이지 ＞ [2팀 이진희] Chapter 1-1. 프레임워크 없이 SPA 만들기

[2팀 이진희] Chapter 1-1. 프레임워크 없이 SPA 만들기

by bebusl2025. 7. 7.

과제 체크포인트

배포 링크

기본과제

상품목록

상품 목록 로딩

  • 페이지 접속 시 로딩 상태가 표시된다
  • 데이터 로드 완료 후 상품 목록이 렌더링된다
  • 로딩 실패 시 에러 상태가 표시된다
  • 에러 발생 시 재시도 버튼이 제공된다

상품 목록 조회

  • 각 상품의 기본 정보(이미지, 상품명, 가격)가 카드 형태로 표시된다

한 페이지에 보여질 상품 수 선택

  • 드롭다운에서 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로 다시 구현한다.
  • 이 과정에서 직접 가공하는 것은 최대한 지양한다.

과제 셀프회고

렌더링 / 라우터를 어떻게 짜야할까 고민하다가 갈아엎는 과정을 반복했습니다. 처음부터 설계를 좀 완벽하게 해보고 싶어서 그 시간을 많이 썼는데 결국, 설계도 실패하고 요구사항을 하나도 지키지 못하게 돼서 매우 아쉽습니다. 데드라인을 지키는 일도 매우 중요하니 할 수 있는 선에서 과제를 마무리할 수 있도록 계획을 세워봐야 할 것 같습니다. 다음 과제부터는 과제 통과하는데 좀 더 집중해보려고 합니다.ㅠㅅㅠ 매우 아쉽네요

기술적 성장

클로져/옵저버/pub-sub패턴 등 오랜만에 복습하면서 더 제대로 학습할 수 있었던 것 같습니다. DOM 조작에 좀 더 능숙해진 것 같습니다.

개선이 필요하다고 생각하는 코드

React처럼 DOM 엘리먼트를 손쉽게 조작하고 싶었는데, 하지만 기존 코드 구조에서는 특정 컴포넌트의 자식 컴포넌트를 삽입하거나 교체하기 어렵게 구현되어 있습니다.

구조를 더 유연하게 리팩토링하고 싶습니다.

학습 효과 분석

선언적 프로그래밍의 위대함을 깨달았습니다. 그리고 성급한 추상화를 하지 않도록 주의해야겠다는 생각이 들었습니다.

과제 피드백

리뷰 받고 싶은 내용

https://github.com/bebusl/front_6th_chapter1-1/blob/main/src/utils/createViewcomponent.js 현재 React처럼 컴포넌트 단위로 view를 관리하고자 하는 의도로 renderViewComponent라는 유틸을 만들었습니다. 하지만 몇 가지 불확실한 부분이나 개선 가능성이 있어서 아래 내용을 중심으로 리뷰를 받고 싶습니다:

  1. 컴포넌트 구조 변경/업데이트 흐름이 적절한지

    • updateComponent 호출 후 render()를 호출해야 하는 구조인데, 이게 직관적인지 확신이 없습니다.
    • 혹은 내부에서 자동으로 재렌더링까지 유도하는 게 좋을지 고민입니다.

  2. currentView 관리 방식이 괜찮은지

    • let currentView로 DOM 요소를 참조하고 replaceChild 하는 방식이 명확하고 안전한지,
    • 더 좋은 방식이나 패턴이 있을지 궁금합니다.

과제 피드백

안녕하세요 이진희님, 수고하셨습니다. 이번 과제는 프레임워크 없이 SPA를 구현하면서 React와 같은 프레임워크가 해결하는 문제들을 직접 경험해보는 것이 목표였습니다.

코드를 보니 컴포넌트 분리와 구조화에 신경을 많이 쓰신 점이 인상적입니다. 특히 renderViewComponent를 통해 React의 컴포넌트 시스템을 구현하려 시도하신 점이 좋았습니다. DOM 조작을 추상화하고 컴포넌트 단위로 관리하려는 접근은 올바른 방향이었습니다.

다만 완성도 면에서 많이 아쉽네요. 짧지 않은 기간인지라 잘 만들어 질수도 있었겠지만 저희가 요구했던 CI 테스트가 모두 실패하고 있기에 '불합격'을 드릴 수 밖에 없습니다.

개발에게 있어서 80%는 되었는데 20%는 한건 사실 안한 것과 다를게 없죠. 99%를 해도 1%의 버그때문에 서비스의 평점이 낮아지는게 개발자인 만큼 좋은 코드 이전에는 마감과 딜리버리가 최우선 역량입니다.

설계에 너무 많은 시간을 투자하셨다고 하셨는데, 잘하고 싶은 마음에 많은 개발자들이 겪는 문제죠. 그렇기에 더더욱 앞으로는 먼저 동작하는 최소한의 구현을 만들고, 점진적으로 개선하는 접근으로 나아갈 수 있기를 바랍니다.

언제나 마감과 딜리버리가 좋은 코드보다 중요하는거 기억해주세요!

Q) renderViewComponent의 구조와 업데이트 흐름에 대해

=> 현재 구조는 명시적이어서 나쁘지 않습니다. 그러나 이 프레임워크를 쓰는 사람에게 명시적으로 호출하라고 하는 건 아니겠죠? 지금 구조만으로는 내부에서 자동으로 해줄 것인지 외부 사용자에게 명시적으로 쓰게 해주게 할지 확실치 않네요.

=> 선언적이다라는 것은 내가 원하는 것만 적어주면 내부에서 알아서 한다이므로 내부에서는 이를 한번에 렌더링을 유도하는게 올바른 구조라고 생각합니다. 확신히 안 들때에는 현재 어떤 구조로 되어 있는지 한번 생각해보세요

=> replaceChild는 지금으로썬 괜찮다 생각합니다. 사실 DOM을 전체 교체하는 것은 상당히 비효율적이기에 많은 프레임워크들이 변해야하는 코드만 변하도록 하는게 기술인데 1주차 과제에 그것까지 해주기를 바라는건 너무 큰 욕심이겠죠? (웃음)

수고하셨습니다. 다음 과제에서는 먼저 테스트를 통과시키는 것을 목표로 하시고, 그 다음에 리팩토링을 진행하시길 추천드립니다. 화이팅입니다! :)