[4팀 이예인] Chapter2-1. 프레임워크 없이 SPA 만들기 #49
Conversation
- import.meta.env 타입 에러 발생하여 types 옵션 추가
- ignores에 template 파일 추가
- productStore: 옵저버 패턴 기반 상태관리 store - fetchProducts: API 호출 및 상태 업데이트 처리
- SearchForm을 SearchInput과 FilterOptions로 분리 - 필터 옵션 상수화 및 동적 렌더링 구현 - 필터 변경 시 자동으로 상품 목록 재조회 기능 추가 - productStore에 pagination 정보 추가 - 전체 상품 개수 표시 기능 구현
feat: 옵저버 패턴 기반 상태 관리 store 구현 및 필터 기능 추가
JunilHwang
left a comment
JunilHwang
left a comment
There was a problem hiding this comment.
이 피드백은 n8n + ai (gpt-5-mini)를 활용하여 자동으로 생성된 내용입니다.
전체 요약
- 현재 구조는 컴포넌트화된 App 구조와 상태/라우터 분리를 도입해 기본적인 SPA 흐름을 만들었으나, 에러 핸들링, 검색/필터 기능, 카테고리/브레드크럼, 장바구니 데이터 연결 등 여러 기본 요구사항이 UI에 반영되지 않았습니다. 또한
fetchProducts에서 상품을 누적하지 않아 무한 스크롤 요건에 불리합니다. - 추후 기능을 추가할 때는 store가
products와params를 책임지고, 라우터는 동적 세그먼트와 404를 처리하며, 개별 컴포넌트는 실제 API 데이터에 기반한 이벤트를 바인딩하도록 확장해야 합니다.
설계 피드백
- 데이터 페칭 로직(
fetchProducts)과 렌더링 흐름(App → ProductListPage 등)이 비동기 상태와 DOM 업데이트를 분리하고 있어 좋은 시도이나, 추가 요구사항(에러/로드/무한 스크롤/URL 공유 등)을 만족하려면 상태 기반 렌더링과 데이터 누적 전략을 조금 더 정교하게 다듬는 것이 필요합니다. - 카테고리나 검색 필터는 단순한 정적 HTML이 아니라
productStore의params와 완전하게 연동되어야 하고, 라우터는 그 상태를 URL로 노출해야 향후 공유/재방문 시에도 일관된 UX를 제공할 수 있습니다.
질문에대한 답변
지난 주차 내용을 따라잡기 위한 추천 학습 로드맵
- 자바스크립트 언어의 기초 개념
- 변수/함수/객체/클로저/프로토타입 등 기본 문법을 숙지하는 것이 모듈화된 SPA를 이해하는 첫걸음입니다.
- MDN JavaScript 가이드를 읽어보세요.
- DOM 조작과 이벤트 처리
- 현재 프로젝트는 순수 JS로 DOM을 업데이트하므로
querySelector,addEventListener,innerHTML같은 API에 익숙해지는 것이 중요합니다.
- 현재 프로젝트는 순수 JS로 DOM을 업데이트하므로
- 모듈 번들러와 빌드 도구의 개념
- Vite로 개발 중이니
ESM,import,npm script,pnpm등의 개념을 익히면 신규 파일 구조를 빨리 이해할 수 있습니다.
- Vite로 개발 중이니
- 비동기 처리와 상태 관리
fetch,async/await와 간단한 관찰자 패턴(productStore)을 공부하여 API 호출과 상태 업데이트 흐름을 따라가 보세요.
- SPA 라우터와 URL 관리
- 해시 라우터가 어떻게 작동하는지,
history/hashchange이벤트를 실습해보면 App.ts → router.ts 흐름을 더 쉽게 따라갈 수 있습니다.
- 해시 라우터가 어떻게 작동하는지,
- 기존 과제 코드 리뷰와 디버깅
- 지금까지 제출하거나 리뷰한 과제를 다시 읽으며
왜 이렇게 짰을까를 분석해보면 빠르게 감을 잡을 수 있습니다.
- 지금까지 제출하거나 리뷰한 과제를 다시 읽으며
팁
- 작은 예제부터 따라하며 엔드투엔드로 한 화면을 뚝딱 구현해보면 전체 흐름을 파악하기 쉽습니다.
- 이해되지 않는 개념이 있다면 관련된 소스 코드(예:
App.ts,productStore.ts,fetchProducts.ts)를 직접 실행하고 console.log를 찍어보면서 혼자 디버깅해보세요.
필요하다면 다음 과제를 시작하기 전에 어떤 개념이 약한지 짚어보고 그 부분을 먼저 보충하는 방식으로 진도를 맞추는 것도 좋습니다. 언제든지 질문해 주세요!
| import { ProductState } from "@/store/products-list/productStore"; | ||
|
|
||
| function ProductListPage(state: ProductState) { | ||
| const { loading, products, params, pagination } = state; |
There was a problem hiding this comment.
문제 상황
앱이 API 호출에 실패하면 사용자 입장에서는 아무 피드백도 받을 수 없고 재시도도 불가능합니다. 기본 과제(상품 목록 로딩)에서 에러 상태를 보여주고 재시도 버튼을 제공해야 합니다.
현재 코드의 한계
productStore에서 에러 정보를 가지고 있지만 이 페이지에서는state.error를 전혀 사용하지 않음- 에러가 나도 로딩 UI에서 계속 깜빡이기만 하고 유저가 다음 행동을 취할 수 없음
개선 구조
state.error가 있다면 에러 메시지 + "다시 시도" 버튼을 보여주고, 버튼 클릭 시fetchProducts(state.params)를 다시 호출- 에러와 로딩을 분리하여 각 상태를 명확하게 렌더링
// ❌ 현재 방식
return `${SearchForm(...)} ${loading ? Loading : ProductList(...)}`;
// ✅ 개선된 방식
if (state.error) {
return `${SearchForm(...)} <div class="text-red-600">${state.error}</div> <button id="retry">다시 시도</button>`;
}이렇게 하면 에러 발생 시 유저가 뭘 잘못했는지 알 수 있고, 재시도 인터랙션도 제공할 수 있습니다.
| @@ -0,0 +1,14 @@ | |||
| export const SearchInput = /* html */ ` | |||
There was a problem hiding this comment.
문제 상황
검색어 입력 필드가 존재하지만 Enter 키나 버튼으로 실제 검색을 수행하지 않아서 검색 기능을 지원하지 못합니다. 과제에서 요구하는 상품명 기반 검색 인터랙션이 동작하지 않습니다.
현재 코드의 한계
<input id="search-input">만 렌더링하고 이벤트 핸들러가 전혀 연결되지 않음- 검색어를 활용할 수 있는 상태/스토어 업데이트 로직도 없음
개선 구조
keydown이벤트를 붙여 Enter 키가 눌리면fetchProducts({ search: value, page: 1 })를 호출- 검색어 값을
productStore의params.search에 기록하고, URL 쿼리로도 싱크시키면 심화 과제에도 대비 가능
// ✅ 개선 예시
const handleSearch = (value: string) => {
fetchProducts({ search: value, page: 1 });
};추가로 setupFilterEventHandlers와 같은 헬퍼에 search-input 이벤트를 등록하면 전체 UI 구조를 유지하면서 검색을 확장할 수 있습니다.
| <!-- 필터 옵션 --> | ||
| <div class="space-y-3"> | ||
| <!-- 카테고리 필터 --> | ||
| <div class="space-y-2"> |
There was a problem hiding this comment.
문제 상황
현재 카테고리 버튼들은 HTML만 존재하고 클릭하면 아무런 상태도 업데이트되지 않습니다. 향후 1depth/2depth 카테고리 선택이나 브레드크럼을 구현하려면 실제 데이터를 productStore와 연동해야 합니다.
현재 코드의 한계
loading과params외에는 어떤 상태 변경도 드러나 있지 않음- 버튼에 이벤트 핸들러가 없어서 클릭해도 아무 반응 없음
- 카테고리 데이터가 하드코딩되어 있어 백엔드에서 내려오는 값을 반영할 수 없음
개선 구조
- 카테고리 데이터를 API에서 받아와
params에 바인딩하고, 선택 시fetchProducts를 호출하여filters.category1, category2를 업데이트 - 카테고리 브레드크럼도
state.params를 기준으로 렌더링하여 현재 경로를 표시
// ✅ 개선 방향 (pseudo)
<button data-category="${category.name}" class="..." data-depth="1" onclick="applyCategory(category)">...</button>카테고리 UI를 상태 기반으로 렌더링하면 향후 새로운 카테고리 또는 브레드크럼 요건이 생겨도 유지보수가 쉬워집니다.
| : /*html */ ` | ||
| <!-- 1depth 카테고리 --> | ||
| <div class="flex flex-wrap gap-2"> | ||
| <button data-category1="생활/건강" class="category1-filter-btn text-left px-3 py-2 text-sm rounded-md border transition-colors |
There was a problem hiding this comment.
문제 상황
필터 영역에서 카테고리를 로딩할 때 Loading 컴포넌트를 재사용하고 있는데, 이 컴포넌트는 상품 그리드와 스켈레톤을 렌더링하기 때문에 필터 UI에 불필요한 마크업이 삽입됩니다. 향후 로딩 UX를 조정하거나 경량화할 때 유지보수성이 떨어지게 됩니다.
현재 코드의 한계
Loading은 상품 리스트 전체를 감싸는 구조 (grid + spinner)를 렌더링함- 필터에서 이 컴포넌트를 쓰면 필터 섹션 안에 상품 스켈레톤이 들어옴
개선 구조
- 필터 전용 로딩 UI를 분리하여 단순한 텍스트/스피너만 렌더링
- 상품 리스트에서는 기존
Loading을 그대로 사용
// ✅ 개선 예시
const FilterLoading = `<div class="text-sm text-gray-500 italic">카테고리 로딩 중...</div>`;이렇게 하면 컴포넌트별 책임이 명확해지고 DOM 구조도 예측 가능합니다.
| <p class="text-lg font-bold text-gray-900"> | ||
| ${parseInt(product.lprice).toLocaleString()}원 | ||
| </p> | ||
| </div> |
There was a problem hiding this comment.
문제 상황
카드 내부의 "장바구니 담기" 버튼에 data-product-id가 하드코딩되어 있어서 모든 상품에 대해 동일한 id(85067212996)가 붙습니다. 따라서 어떤 상품을 추가하려고 해도 올바른 ID를 전달할 수 없어 장바구니 기능을 제대로 구현할 수 없습니다.
현재 코드의 한계
- 버튼의 id가
data-product-id="85067212996"으로 고정되어 있음 product객체의productId값을 사용하지 않음
개선 구조
- 템플릿 안에서
${product.productId}를 사용하도록 바꾸고, 클릭 핸들러에서event.target.dataset.productId를 통해 실제 상품을 식별
<button ... data-product-id="${product.productId}">장바구니 담기</button>이렇게 하면 나중에 장바구니 API/상태 관리자에 실제 상품 정보를 넘기는 로직을 추가할 수 있습니다.
| interface ProductListProps { | ||
| products: ProductItem[]; | ||
| total: number; | ||
| } |
There was a problem hiding this comment.
문제 상황
개발 중 남은 console.log가 렌더링마다 실행되고 있어 제품 리스트가 렌더링될 때마다 불필요하게 콘솔이 채워집니다. 또한 로그가 있는 상태에서 무한 스크롤이나 프로덕션 빌드가 진행되면 성능/보안에 영향을 줄 수 있습니다.
현재 코드의 한계
console.log("ProductList: ", products);가 매 렌더링마다 호출- 실제 기능에는 아무 영향을 주지 않으면서 로그가 쌓임
개선 구조
- 개발용 정보는
logger헬퍼로 감싸거나import.meta.env.MODE === 'development'체크 후 출력 - 또는 완전히 제거하여 렌더링 루프가 깨끗하도록 유지
if (import.meta.env.DEV) {
console.debug("ProductList", products);
}불필요한 로그는 유지보수성과 퍼포먼스 측면에서 항상 제거하는 게 좋습니다.
|
|
||
| // 5) 성공 시 상품 목록 + 페이지네이션/필터 반영 | ||
| productStore.setState({ | ||
| loading: false, |
There was a problem hiding this comment.
문제 상황
현재 fetchProducts는 API 응답을 받을 때마다 products 배열을 새 값으로 덮어쓰기 때문에, 무한 스크롤(추가 페이지 데이터를 쌓는) 요구사항을 만족하지 못합니다. 추가 페이지를 로드할 때 기존 상품이 사라지는 문제가 발생합니다.
현재 코드의 한계
productStore.setState({ products: res.products, ... })로products를 덮어씀pagination.page를 관리하지만products는 누적되지 않음
개선 구조
state.pagination.page보다 큰 페이지를 로드할 때는products: [...prev.products, ...res.products]형태로 누적params에page인자를 넣고 다음 페이지 요청 시fetchProducts({ page: prev.pagination.page + 1 })를 호출
const nextProducts = params.page && params.page > prev.pagination?.page ? [...prev.products, ...res.products] : res.products;이렇게 하면 유저가 하단에 도달할 때마다 새로운 데이터를 append할 수 있어 현실적인 infinite scroll 요구사항을 만족할 수 있습니다.
| @@ -0,0 +1,49 @@ | |||
| /** | |||
There was a problem hiding this comment.
문제 상황
예정된 심화 과제에서는 /product/{productId}와 같은 디테일 페이지, 404 페이지, 그리고 쿼리 기반 라우팅이 필요합니다. 현재 라우터는 해시 전체 문자열과 딱 맞는 라우트만 찾기 때문에 동적 세그먼트나 unknown path 처리에 취약합니다.
현재 코드의 한계
routes.find(route.fragment === window.location.hash)로 정확히 일치하는 경우만 지원/product/123을 표현할 수 없고, 매칭 실패 시 404 처리를 할 수 없음
개선 구조
- 정규식 기반 패턴 매칭(예:
#/product/:id)을 지원하거나startsWith/match방식으로 유연하게 구성 - 라우트가 없는 경우 404 콜백을 호출하고,
router.addRoute('*', ...)방식으로 홈으로 리다이렉트
const matched = routes.find((route) => new RegExp(route.fragment).test(currentHash));이런 구조를 갖추면 SPA 내에서 URL을 공유/복원할 때도 안정적으로 처리할 수 있습니다.
| import { AppContents, ProductListPage } from "./pages"; | ||
| import createRouter from "./router"; | ||
| import { fetchProducts } from "./store/products-list/fetchProducts"; | ||
| import { ProductState, productStore } from "./store/products-list/productStore"; |
There was a problem hiding this comment.
문제 상황
App 컴포넌트가 document.querySelector("#root")으로 루트 노드를 가져오지만, null 체크가 없어서 DOM에 해당 아이디가 없거나 아직 렌더링되지 않은 경우 runtime 에러가 발생할 수 있습니다. 다른 환경에서 앱을 띄울 때 깨질 위험이 있습니다.
현재 코드의 한계
$root가 null이면 이후innerHTML접근에서 예외가 발생- DOM 준비 여부를 확인하지 않고 바로 쿼리함
개선 구조
const $root = document.querySelector<HTMLDivElement>('#root'); if (!$root) throw new Error('루트 요소를 찾을 수 없습니다.');- 또는
if (!$root) return;방식으로 실패를 방지하고 메시지를 남김
if (!$root) {
console.error("#root가 존재하지 않아 App을 마운트할 수 없습니다.");
return;
}간단한 가드 하나로 예측 불가능한 실패를 막을 수 있습니다.
| @@ -0,0 +1,1112 @@ | |||
| const 상품목록_레이아웃_로딩 = ` | |||
There was a problem hiding this comment.
문제 상황
src/template.ts에 오래된 전체 페이지 템플릿이 여전히 남아 있는데, 현재 App 구조에서는 전혀 임포트되지 않고 있습니다. 이 파일이 너무 방대하여 코드베이스를 헤매게 만들고 유지보수성을 저하시킵니다.
현재 코드의 한계
- 전체 마크업이 1,112줄 이상 존재하지만 어떠한 모듈에서도 사용되지 않음
- 추후 팀원들이 어느 템플릿이 실제 렌더링에 쓰이는지 구분하기 어려움
개선 구조
- 사용하지 않는 템플릿은 제거하고, 필요하다면 문서로 정리
- 재사용하는 컴포넌트는 현재
pages/와components/하위에 분리된 구조를 따르도록 리팩터
이 파일을 정리하면 프로젝트의 인지 부하가 줄고, App.ts 기반 SPA 흐름과 혼동되지 않게 됩니다.
devchaeyoung
left a comment
devchaeyoung
left a comment
There was a problem hiding this comment.
이 피드백은 n8n + ai (gpt-5-mini)를 활용하여 자동으로 생성된 내용입니다.
이번 PR에서는 상태 관리(store)와 컴포넌트 분리에 신경쓴 점이 인상적입니다. productStore에서 옵저버 패턴을 직접 구현하고 fetchProducts에서 API 연동 및 상태 변경 처리를 잘 분리하셨습니다. UI 컴포넌트들도 모듈화하여 관리한 점도 긍정적입니다. 👍 <추가질문>에서 예인님이 언급하신 바와 같이 순수 JS와 웹 API의 세부 동작 원리를 체감하며 리액트 추상화와의 차이를 깨달은 점이 이번 과제의 큰 수확으로 보입니다. 질문하신 "학습해야 할 개념"에 대해선, 웹 프론트엔드 깊은 이해를 위해서는 DOM, 이벤트, 상태관리, 모듈화, SPA 라우팅, 비동기 처리 등 기초 개념을 먼저 튼튼히 하는 것이 좋고, 이후 디자인 패턴(옵저버, 퍼블리셔/서브스크라이버 등)과 모듈 분리, 테스트 가능한 코드 작성 등에 착안해보면 좋을 것 같아요. 현재 프로젝트는 관심사 분리 기반으로 구성되어 있지만, UI 렌더링과 상태관리의 의존성이 일부 남아있어 앞으로 더 명확한 모듈화 및 SPA 핸들링 구조 개선을 고민해보면 확장성과 유지보수에 도움이 될 것 같습니다.
질문에대한 답변
1. 질문 요약
예인님께서는 이번 과제를 수행하면서 순수 자바스크립트, 웹 API, DOM 조작 등 리액트 없이 프론트엔드 기능을 직접 다뤄 보는 경험을 통해 기존 리액트의 추상화와의 차이를 깊이 체감하셨고, 아직 부족함을 느끼면서도 이를 보완할 학습 방향에 대해 문의하셨습니다.
2. 현재 선택의 장단점
- 장점: 순수 JS로 직접 상태관리(옵저버 패턴), DOM 렌더링, 이벤트 핸들링을 구현하며 근본적인 동작 원리를 체득중입니다.
- 단점: 이런 구조는 초기 진입장벽이 크고 복잡도가 빠르게 증가하여 시간 부족과 구현 난이도가 높습니다. 또한 SPA 내 동적 URL 관리, 상태와 UI 분리 등이 미흡해 확장이나 유지보수가 어렵습니다.
3. 실무에서라면 이렇게 설계할 것 같아요
- 기초 개념 숙지: Web API(DOM, 이벤트, fetch 등), ES 모듈, 비동기 처리(Promise, async/await), 기본 자료구조를 체계적으로 반복 학습합니다.
- 디자인 패턴 학습: 옵저버 패턴, MVP/MVC, 퍼블리셔-서브스크라이버 등 상태와 이벤트 관리를 어떻게 구조화할지 학습합니다.
- 모듈화와 관심사의 분리: UI 컴포넌트, 상태관리, 라우팅, API 호출 등 관심사를 명확히 나누는 방법을 익힙니다.
- 라이브러리 활용 경험: React를 포함해 Vue, Svelte 등 SPA 라이브러리에 대한 개념적 이해를 차츰 키우면서, 추상화로 무엇을 편하게 하고 무엇을 숨기는지 이해합니다.
- 점진적 마이그레이션: 순수 JS로 먼저 개념을 익힌 뒤 React로 이전하여 생산성을 높이고, 그 과정에서 두 영역의 교차점과 차별점을 명확히 잡으면 좋습니다.
4. 앞으로 구조를 잡을 때 참고하면 좋은 포인트
- 상태와 UI 렌더링 로직을 완전히 분리해보세요 (예: 상태만 바뀌면 렌더링 함수만 호출)
- 라우팅은 URL 변화를 기반으로 화면을 바꾸는 역할만 하도록 하고, 화면 렌더링은 컴포넌트에서 담당하도록 설계해보세요.
- 이벤트 핸들링은 UI 컴포넌트에 바인딩하되, 핸들러 내부에서 상태를 변경하거나 API를 호출하는 함수만 호출하는 방식이 좋습니다.
- 점진적으로 타입스크립트, 테스트 도입을 통해 런타임 안정성과 유지보수성을 높이지요.
예인님, 꾸준한 반복과 실습이 가장 중요하니, 너무 조급하게 생각하지 말고 매 과제마다 새로운 개념을 하나씩 체득해 나가시면 꽤 큰 발전이 있을 거예요. 필요하면 추가 질문 주세요!
|
|
||
| export type ProductState = { | ||
| loading: boolean; | ||
| products: ProductItem[]; |
There was a problem hiding this comment.
예인님, productStore의 옵저버 패턴 구현 부분은 상태 변화에 따른 화면 업데이트가 잘 분리되어 있어서 구조가 깔끔해 보입니다. 👍 다만 현재 옵저버 배열을 배열 원본 그대로 관리하는데, 추후 메모리 누수 방지나 성능 최적화를 위해 구독 취소 시 옵저버 객체를 Set으로 관리해보면 어떨까 생각해볼 수 있습니다.
| const prev = productStore.getState(); | ||
|
|
||
| // 2) 기존 params + 새로 들어온 params 덮어쓰기 | ||
| const params: GetProductsParams = { |
There was a problem hiding this comment.
fetchProducts 함수가 API 호출과 상태 관리를 적절히 분리하여 작성된 점이 좋습니다. 👍 하지만 에러 발생시 재시도 기능(요구사항) 구현 여부가 확인되지 않는데, 사용자 경험을 위해 재시도 버튼 UI 및 관련 로직을 추가해보면 좋겠습니다.
| */ | ||
| export function setupFilterEventHandlers() { | ||
| // 기존 리스너 제거를 위해 클론하여 새로 등록 | ||
| const limitSelect = document.getElementById("limit-select"); |
There was a problem hiding this comment.
이벤트 핸들러를 별도 모듈로 분리한 점은 관심사 분리 관점에서 바람직합니다. 👍 다만 동일한 요소에 이벤트 리스너를 추가/제거하는 로직이 있는데, 이 부분을 위임(delegate) 방식으로 전환하면 성능과 유지보수 측면에서 유리할 수 있어요.
| import { ProductState, productStore } from "./store/products-list/productStore"; | ||
| import { setupFilterEventHandlers } from "./components/SearchForm/filterEventHandlers"; | ||
|
|
||
| export default function App() { |
There was a problem hiding this comment.
App 컴포넌트 내에 라우터와 렌더링 로직이 적절히 분리되어 있습니다. 👍 다만 App 내부가 HTML 문자열 렌더링과 상태 구독 로직을 섞고 있어, 향후 React 또는 상태 관리 라이브러리로 마이그레이션 시 이 부분을 UI 컴포넌트와 상태 로직으로 더 명확히 분리해보면 좋겠습니다.
|
|
||
| export const ProductCard = (product: ProductItem) => { | ||
| return /* html */ ` | ||
| <div class="bg-white rounded-lg shadow-sm border border-gray-200 overflow-hidden product-card" |
There was a problem hiding this comment.
ProductCard 컴포넌트가 단일 책임 원칙에 맞게 구성되어 있습니다. 👍 다만 data-product-id가 버튼에 하드코딩된 값(85067212996)으로 보이는데, prop에서 받아 활용하도록 수정하면 재사용성과 버그 예방에 도움이 될 것 같아요.
| <!-- 카테고리 필터 --> | ||
| <div class="space-y-2"> | ||
| <div class="flex items-center gap-2"> | ||
| <label class="text-sm text-gray-600">카테고리:</label> |
There was a problem hiding this comment.
필터 옵션 UI가 깔끔하게 구성되어 있고 로딩 상태도 고려되어 있습니다. 👍 다만 2depth 카테고리 UI 렌더링이 하드코딩되어 있어, 실제 동적인 카테고리 정보를 받아 렌더링하는 구조로 변경하면 확장성에 더 좋을 것 같아요.
| * URL 해시 변경을 감지하여 해당 경로의 컴포넌트를 실행한다. | ||
| * | ||
| * @method start | ||
| * @fires window#hashchange |
There was a problem hiding this comment.
커스텀 라우터 구현이 적절합니다. 👍 다만 현재 라우트 구분이 정확한 해시 문자열 매칭 기반이라, 동적 라우팅(상품 상세페이지 ID 파싱 등)에는 확장하기 어렵습니다. 다음 과제에서 SPA 네비게이션 및 URL 쿼리 관리에 대비해 정규표현식 또는 파라미터 매칭이 가능한 라우터 구조를 고민해보면 좋겠습니다.
| export const Loading = /* html */ ` | ||
| <div> | ||
| <div class="grid grid-cols-2 gap-4 mb-6" id="products-grid"> | ||
| ${Skeleton.repeat(8)} |
There was a problem hiding this comment.
로딩 컴포넌트를 별도 모듈로 분리한 점이 좋습니다. 👍 다만 HTML 템플릿을 문자열로 반복 사용하는 방식은 유지보수성이 떨어질 수 있어서, 추후에는 컴포넌트 단위 함수 또는 라이브러리 활용을 고려해보면 좋겠습니다.
| @@ -0,0 +1,1112 @@ | |||
| const 상품목록_레이아웃_로딩 = ` | |||
There was a problem hiding this comment.
현재 HTML 템플릿이 길고 복잡하게 한곳에 몰려있는데, 이 구조는 유지보수와 확장성 측면에서 한계가 있습니다. 앞으로 컴포넌트별 분리, 템플릿 함수화, 또는 React / Vue 같은 라이브러리 적용을 고민해보면 좋겠습니다.
| @@ -0,0 +1,10 @@ | |||
| import { defineConfig } from "vite"; | |||
| import tsconfigPaths from "vite-tsconfig-paths"; | |||
|
|
|||
There was a problem hiding this comment.
vite-tsconfig-paths 플러그인을 통해 src 경로 절대경로 설정을 해둔 점이 좋습니다. 👍 이 부분을 활용해 프로젝트 내 모듈 import 시 상대경로 의존성을 줄여보시면 좋겠습니다.
3 participants
과제 체크포인트
배포 링크
기본과제
상품목록
상품 목록 로딩
상품 목록 조회
한 페이지에 보여질 상품 수 선택
상품 정렬 기능
무한 스크롤 페이지네이션
상품을 장바구니에 담기
상품 검색
카테고리 선택
카테고리 네비게이션
현재 상품 수 표시
장바구니
장바구니 모달
장바구니 수량 조절
장바구니 삭제
장바구니 선택 삭제
장바구니 전체 선택
장바구니 비우기
상품 상세
상품 클릭시 상세 페이지 이동
/product/{productId}형태로 변경된다상품 상세 페이지 기능
상품 상세 - 장바구니 담기
관련 상품 기능
상품 상세 페이지 내 네비게이션
사용자 피드백 시스템
토스트 메시지
심화과제
SPA 네비게이션 및 URL 관리
페이지 이동
상품 목록 - URL 쿼리 반영
상품 목록 - 새로고침 시 상태 유지
장바구니 - 새로고침 시 데이터 유지
상품 상세 - URL에 ID 반영
/product/{productId})상품 상세 - 새로고침시 유지
404 페이지
AI로 한 번 더 구현하기
과제 셀프회고
이번 주도 역시 과제를 완성하지 못함. 기초 지식 부족으로 구현 과정 하나하나를 따라가는 데 시간이 필요하지만 늘 그렇듯 가용한 시간이 많지 않았음. AI를 적극적으로 사용해서 과제를 완성하려고는 했지만, AI를 사용하는 것이 나의 성장에 큰 도움이 되는가에 대한 의문을 항상 남아있음. 한 줄씩 뜯어보고 이해하고 적용하느라 시간이 오래 걸림.
배운 점
리액트를 사용할 줄 아는 것과 웹 프론트엔드를 이해하는 것은 완전히 다른 차원이라는 것을 깨달았음. 그동안은 리액트의 추상화 덕분에 몰라도 사용하는 데 큰 문제가 없었던 브라우저 렌더링 과정, 웹API, 라우팅 처리 방식 등을 이번 과제를 하면서 처음 제대로 접하고 다뤄봄
아직 완전히 내 것이 되지는 않았지만 반복해서 손으로 구현해보면 익숙해지지 않을까 (제발)
어려웠던 점
리뷰 받고 싶은 내용