[4팀 박지영] Chapter2-1. 프레임워크 없이 SPA 만들기 #45
Conversation
|
4팀 코드리뷰
|
JunilHwang
left a comment
JunilHwang
left a comment
There was a problem hiding this comment.
이 피드백은 n8n + ai (gpt-5-mini)를 활용하여 자동으로 생성된 내용입니다.
전체적인 리뷰 요약,- 장바구니 로직이 Observer 패턴 기반이라 좋은데, quantity 반영과 선택 상태 영속성 같은 도메인 요구를 아직 완전히 충족하지 못했습니다. 수량 누적과 체크 상태까지 저장하면 UX와 재사용성 모두 개선됩니다.,- DOM 재생성 방식과 main.js의 이벤트 중심 구조가 확장성에서 발목을 잡고 있습니다. DOM을 점진적으로 갱신하고, 도메인별 이벤트 모듈을 분리하면 새로운 기능을 깔끔하게 추가할 기반이 마련됩니다.,- 라우터/캐시 구조도 리팩토링 여지가 있습니다. basePath를 문자열로 슬라이스하는 대신 URL API로 관리하고, productCache를 실질적인 store(상세 페이지, 최근 본 상품 기준)로 확장하면 유지보수성과 성능 모두 향상됩니다.,,### 설계에 대한 피드백,- 기능별(상품, 장바구니, 라우팅)로 상태와 이벤트 구분 → 각 도메인에 store, events, templates를 두면 책임이 명확해짐,- 상태 변경은 로컬 저장소/URL/스토어로 일관되게 흐르게 → 선택/카테고리/수량 상태가 어디에 저장되는지 명확히 정하면 새 요구사항(예: 공유된 URL + 복원)이 추가되어도 대응이 쉬움,- DOM 업데이트는 innerHTML 전환보다 부분적인 DOM 패칭 또는 가벼운 DOM diff로 전환 → 스켈레톤 유지, 스크롤/포커스 보존, 무한 스크롤 트리거 유지가 가능해짐### 추가 질문에 대한 답변
1. main.js 이벤트 핸들러 구조 개선
전역의 단일 핸들러가 모든 도메인을 다루고 있어서, 현재는 규모가 작아도 기능이 늘어나면 if (target.closest(…)) 블록이 너무 길어집니다. 현실적인 기준은 **“도메인 경계를 기준으로 분리”**하는 것입니다. 예: 장바구니 관련, 상품 리스트 관련, 라우팅/네비게이션 관련 등으로 모듈화하면 각 모듈에서 initEvents()를 export하고 main에서는 registerCartEvents()처럼 호출만 하면 됩니다. 이벤트 위임을 유지하되, 각 모듈이 document.body에 하나씩 click을 붙이는 것이 아니라, 메인 핸들러는 공통 위임을 유지한 채 핸들러를 도메인별로 분리된 함수(예: handleCartClick, handleProductClick)로 위임하는 방식도 가능합니다. 이렇게 하면 새 기능이 생겨도 특정 모듈만 수정하면 되고, 단위 테스트나 DDD 단위로 이벤트를 추적하기 용이해집니다.
2. 라우터의 경로 정규화
BASE_URL을 문자열로 슬라이스해서 toAppPath를 만드는 방식은 현재 요구사항에서는 동작하지만, BASE_URL에 중복 슬래시, 쿼리, 또는 history.pushState로 직접 ?를 붙였을 때 실수가 생기기 쉽습니다. 더 간결하게 하려면 new URL(path, window.location.origin)과 .pathname/.search를 활용해 기준 URL을 만들고 나서 appPath = pathname.replace(basePath, "")처럼 처리하면, BASE_PATH가 /, /foo/, /foo/bar/ 등 무엇이든 일관되게 매핑됩니다. 나아가 push()에서 url.search를 수동으로 덧붙이지 않고 new URL(target)을 만들어 history.pushState할 때 그대로 넘기면 중복 문제도 없습니다.
3. 상태 관리 구조 기준
전역 상태(store)가 필요한 데이터는 **“여러 컴포넌트에서 구독/갱신해야 하는 데이터”**와 **“앱 전반의 일관된 상태로서 새로고침/공유가 필요한 데이터”**입니다. 장바구니는 다수 구독자(헤더 아이콘, 모달, 토스트 등)가 있으므로 Observer 패턴이 적절합니다. 반대로, infiniteScrollState처럼 한 화면에서만 쓰는 상태는 단순 객체로 관리해도 무방합니다. 다만 계층화가 필요합니다. 예: 상품 목록/관련 상품/상세에서 모두 쓰는 상품 데이터는 productStore로 추상화해서 캐시와 중복 호출을 줄이고, 상태 변경 시 notify를 통해 UI를 업데이트하면 좋습니다. URL 쿼리는 일종의 사용자 입력이자 공유 가능한 상태이므로 SearchState처럼 캡슐화해도 되고, 현재처럼 URLSearchParams를 기준으로 하되 이 파라미터를 읽는 유틸을 filtersFromQuery()처럼 별도 유틸로 두면 확장성이 늘어납니다. 모달 오픈/클로즈도 “UI 상태”이므로, 나중에 모달이 많아지는 요구사항이 생기면 modalStore처럼 쓸 수 있는 구조로 바꾸면 됩니다.
결론적으로 상태를 store로 통일하되, 사용 범위(전역 vs局部)와 구독 여부를 기준으로 판단하면 됩니다. 장바구니처럼 여러 구독자가 있다면 Observer를 적용하고, 상세 페이지/무한 스크롤처럼 자기 화면에서만 쓰는 상태는 infiniteScrollState를 유지하면서도, 이벤트가 많아지면 상태 변경 함수(setFilters, resetPage, appendProducts)를 추가해서 명시적으로 관리해 주세요.
4. 상품 데이터 API 호출 최적화
현재 productCache는 addToCart에서만 참조되고, 상세 페이지에서는 매번 getProduct(productId)로 가져옵니다. 실제 서비스를 보면 동일한 상품을 여러 경로에서 보는 경우가 많아서, 하나의 productStore를 만들고 getProduct/getProducts가 내부적으로 캐시를 먼저 확인하도록 만들면 중복 요청을 줄이고 빠른 응답을 기대할 수 있습니다. 실제로 데이터가 자주 바뀌지 않는 경우(예: 캐싱 5분)에는 캐시 데이터로 화면을 구성하고, 배경으로 API를 재요청해 lastUpdated 같은 메타를 업데이트하는 전략도 쓸만합니다. productStore를 갖춰 놓으면 “최근 본 상품”, “관련 상품” 등 새 요구사항도 같은 데이터로 확장할 수 있습니다.
| if (existingItem) { | ||
| console.log("장바구니 갯수 추가:", existingItem.productId); | ||
| existingItem.quantity += 1; | ||
| } else { |
There was a problem hiding this comment.
문제 상황
상세 페이지에서 수량을 3개로 선택한 후 장바구니 담기를 누르면, 기대하는 동작은 선택한 수량만큼 장바구니에 쌓이는 것입니다. 그러나 지금은 addToCart 안에서 existingItem이 존재할 경우 항상 quantity += 1로만 증가하기 때문에, 사용자가 입력한 수량은 무시되고 1개씩만 추가됩니다.
현재 코드의 한계
product.quantity속성으로 전달된 값이 반영되지 않습니다.- 상세 페이지에서 여러 개를 한 번에 담을 수 있는 요구사항을 대응할 수 없습니다.
- 수량 조절 UI와 상태가 실질적으로 연결되지 않아 UX가 엇박자납니다.
개선 구조
existingItem이 있다면 product.quantity || 1 만큼 누적하도록 바꾸고, 새로 추가할 때도 명시된 quantity를 사용하면 AS-IS보다 유연합니다.
// ❌ 현재 방식
if (existingItem) {
existingItem.quantity += 1;
}
// ✅ 개선된 방식
const delta = Number(product.quantity) || 1;
if (existingItem) {
existingItem.quantity += delta;
} else {
this.state.cart.push({ ...cartItem, quantity: delta });
}이렇게 하면 상세 페이지의 수량 선택을 제대로 반영할 수 있고, 향후 한 번의 클릭으로 여러 개를 담는 요구사항도 충족시킬 수 있습니다.
| localStorage.setItem(CART_STORAGE_KEY, JSON.stringify(this.state.cart)); | ||
|
|
||
| this.observers.forEach((observerFn) => observerFn(this.state.cart)); | ||
| }, |
There was a problem hiding this comment.
문제 상황
헤더의 장바구니 배지에는 cartStore.getTotalCount() 결과(현재는 state.cart.length)가 쓰이고 있습니다. 상품을 여러 개 담으면 배지의 숫자가 1, 2, 3…처럼 카테고리 개수로만 변하고 실체 수량과 일치하지 않습니다. 사용자는 실제 담은 수량을 확인하기 어렵습니다.
현재 코드의 한계
getTotalCount는 장바구니에 들어있는 서로 다른 상품 수를 반환하고, 각 상품의quantity를 더하지 않습니다.quantity가 늘어나도 UI 숫자가 늘어나지 않기 때문에, 장바구니에 얼마나 담겼는지 파악하기 어렵습니다.
개선 구조
실제 수량을 누적하도록 reduce를 사용하면 배지가 정확해집니다.
// ✅ 개선된 방식
getTotalCount() {
return this.state.cart.reduce((sum, item) => sum + item.quantity, 0);
}이렇게 하면 장바구니 배지가 선택한 수량과 동기화되며, 앞으로 "수량 단위로 카운팅"이 필요한 기능(예: 수량 기반 요금제)도 자연스럽게 대응할 수 있습니다.
|
|
||
| const normalizeProductId = (productId) => { | ||
| if (productId === undefined || productId === null) return ""; | ||
| return String(productId); |
There was a problem hiding this comment.
문제 상황
심화 요구사항에서 언급한 것처럼 장바구니 선택 상태(선택 삭제, 전체 체크)는 새로고침 이후에도 유지되어야 합니다. 그러나 selectedProductIds는 모듈 스코프의 Set으로만 관리되고 있으며, 새로고침하면 빈 집합으로 초기화됩니다.
현재 코드의 한계
selectedProductIds는localStorage등의 영속 계층과 연결되어 있지 않음- 브라우저 새로고침 → 장바구니 데이터를 불러온 뒤에도 체크 상태가 복원되지 않음
- 선택 기반 액션이 많아지면 사용자가 매번 다시 체크해야 해서 UX가 깬다
개선 구조
선택 상태도 cartStore나 별도 스토어(LocalStorage)로 옮기면 상태 영속성이 생깁니다.
cartStore에selection상태를 추가cartStore.notify()시 함께 저장- 초기화 시
localStorage에서 복원하고subscribe로 컴포넌트까지 전달
이렇게 하면 “장바구니의 선택 상태 유지”라는 요구사항을 스토어 중심으로 일관되게 해결할 수 있습니다.
| <span class="text-lg font-bold text-gray-900">총 금액</span> | ||
| <span class="text-xl font-bold text-blue-600">${Number(cartStore.getTotalAmount()).toLocaleString()}원</span> | ||
| </div> | ||
There was a problem hiding this comment.
문제 상황
updateCartListView에서 매번 container.innerHTML = renderCartLayout(...)으로 전체 DOM을 대체합니다. 제품 수가 많거나 선택을 조금씩 바꾸는 경우에도 전체 리스트가 다시 그려지면서 스크롤 위치가 위로 튀고, 체크박스 상태가 잠깐 깜빡이는 등 부정적인 UX가 나타납니다.
현재 코드의 한계
- 선택/수량만 바뀌었는데도
cart-itemDOM 전체를 새로 만듦 - 스크롤 위치, 포커스, 이미지 로딩이 매번 초기화됨
- 장바구니가 커졌다가 다시 작아지는 시나리오에서 눈에 띄게 깜빡임
개선 구조
후속 기능(예: 체크한 항목만 사라지는 애니메이션)이 요구된다면 전체 innerHTML 교체 방식은 한계가 있습니다. 선택 상태만 바꾸는 dataset/classList 업데이트나 DOM 패칭 라이브러리(예: morphdom)를 적용하거나, 최소한 cart-item 단위로 DOM을 찾은 뒤에 필요한 부분만 바꾸는 방향으로 전환하면 다음 요구사항에도 유연하게 대응할 수 있습니다.
| </button>`; | ||
| }; | ||
|
|
There was a problem hiding this comment.
문제 상황
cartStore.subscribe 안에서 cartIconBtn.innerHTML = CartIcon().trim()으로 버튼 전체를 다시 그립니다. 이 동작은 토스트나 접근성 속성을 버튼에 추가하려고 할 때마다 다시 덮어쓰게 되어 확장이 어렵습니다.
현재 코드의 한계
innerHTML전체 재생성으로aria-*,title,data-*속성을 추가해도 다음 notify에서 없어짐- 향후 툴팁, 애니메이션,
focus유지가 필요할 때 이를 유지하기 어렵고, 재사용성도 떨어짐
개선 구조
변경이 필요한 부분(숫자를 표시하는 스팬)만 선택해서 텍스트만 업데이트하면 됩니다.
예를 들어:
const updateBadge = () => {
const badge = document.querySelector("#cart-icon-btn .cart-count-badge");
if (badge) {
badge.textContent = cartStore.getTotalCount();
}
};이렇게 하면 버튼 본체는 최초 렌더링대로 두고, 상태만 붙이는 방식으로 기능을 확장할 때마다 전체 마크업을 덮어쓸 필요가 없어집니다.
| // 장바구니 추가 버튼 클릭 | ||
| const addToCartBtnMain = target.closest(".add-to-cart-btn"); | ||
| const addToCartBtnDetail = target.closest("#add-to-cart-btn"); | ||
| const addToCartBtn = addToCartBtnDetail || addToCartBtnMain; |
There was a problem hiding this comment.
문제 상황
클릭/변경/키보드 이벤트가 document.body.addEventListener 하나에 모두 몰려 있습니다. 새로운 기능(예: 즐겨찾기, 리뷰 모달, 상품 비교 등)이 추가되면 조건문이 계속 늘어나고 실제 도메인 책임도 희석됩니다.
현재 코드의 한계
- 하나의
click핸들러가 장바구니, 상품 리스트, 라우터, 카테고리 필터를 모두 다룸 - 기능별로 분리된 테스트나 재사용이 어렵고,
if/else중첩이 기하급수적으로 늘 것 - 새로운 모듈을 추가할 때마다
main.js만 수정해야 해서 유지보수 비용이 커짐
개선 구조
도메인별로 cartEvents, productEvents, navigationEvents처럼 파일을 나누고 각각에서 init 함수를 만들면 책임 분리가 됩니다. 예:
import { registerCartEvents } from "./events/cart.js";
registerCartEvents();이렇게 하면 기능 추가 시 해당 도메인의 이벤트만 집중해서 수정할 수 있고, 테스트/문서화도 쉬워집니다.
|
|
||
| const enableMocking = () => { | ||
| const workerScriptUrl = `${import.meta.env.BASE_URL ?? "/"}mockServiceWorker.js`; | ||
| return import("./mocks/browser.js").then(({ worker }) => |
There was a problem hiding this comment.
문제 상황
productCache는 addToCart에서만 사용되고 있으며, 상품 상세 페이지나 관련 상품 영역에서는 전혀 활용되지 않습니다. 따라서 동일한 상품을 보러 가거나 다시 목록으로 돌아올 때마다 API를 다시 호출해 중복 요청이 발생합니다.
현재 코드의 한계
productCache에 저장해도 사용처가 제한적- 홈 → 상세 → 뒤로가기 시에도 새로운 API 콜이 트리거되어 성능과 사용자 경험에 악영향
- 및 미래 요구사항(예: “최근 본 상품”, “상세에서 공유된 상태” 등)을 대응하기 어려움
개선 구조
상품 데이터를 중앙 store(예: productStore)로 묶고, getProduct 호출 시 캐시부터 확인하거나, 페이지 전환 시 기존 데이터를 재사용하도록 하면 됩니다. 예를 들어 getProduct 내부에서 먼저 productCache.get(productId)를 확인하면 API 요청을 줄일 수 있고, 관련 상품/재고 업데이트도 한 곳에서 관리할 수 있습니다.
| </div> | ||
| ` | ||
| } | ||
| </div> |
There was a problem hiding this comment.
문제 상황
updateProductListDOM에서 outerHTML을 통째로 바꾸기 때문에 무한 스크롤 트리거(#infinite-scroll-trigger)와 현재 스크롤 위치가 날아가고, requestAnimationFrame이나 Intersection Observer를 붙이기 어려워집니다. 미래 요구사항 중 하나로 “스켈레톤을 유지하면서 새로운 항목만 삽입”이 있다면 현재 구조로는 비효율적입니다.
현재 코드의 한계
- 전체 DOM을 탈착/재생성하여 scroll position, focus, video 재생 등의 상태를 잃음
- 무한 스크롤 진입점(#infinite-scroll-trigger)이 DOM 업데이트 때마다 사라졌다 생기므로 안정성이 떨어짐
개선 구조
React 스타일의 키 기반 패칭이나 morphdom같은 경량 diff 라이브러리를 써서, 새 데이터가 있을 때 기존 그리드에 insertAdjacentHTML 등으로 추가하면 트리거 요소도 계속 유지됩니다. 또는 products-grid 내부만 갱신할 수 있도록 업데이트 함수를 분리하여, 스켈레톤/로딩 애니메이션과 독립적으로 동작하게 설계하면 향후 성능 요구를 수월히 맞출 수 있습니다.
|
|
||
| const toAppPath = (pathname = "/") => { | ||
| const normalized = normalizePath(pathname); | ||
| if (basePath === "/") return normalized; |
There was a problem hiding this comment.
문제 상황
toAppPath/toBrowserPath에서 basePath를 직접 문자열로 제거/조합하는 방식은, /front_7th_chapter2-1/처럼 서브 디렉터리를 사용하는 환경에서는 잘 작동하지만 BASE_URL이 https://host/app//sub/처럼 예기치 않은 슬래시를 포함하거나 쿼리가 섞였을 때 취약합니다. 또한 push에서 url.search를 단순히 toBrowserPath(appPath) 뒤에 붙이므로 path에 이미 ?가 있다면 잘못된 주소가 됩니다.
현재 코드의 한계
- 문자열 스트립 방식을 수작업으로 구현하여 실수하기 쉽고 테스트하기 어려움
push("/?foo=1", { silent: true })같은 호출에서search가 중복될 수 있음
개선 구조
new URL(path, origin)을 활용하면 브라우저 경로를 일관되게 계산할 수 있습니다.
const composeBrowserPath = (appPath, search = "") => {
const url = new URL(basePath, location.origin);
url.pathname = normalizeUrlPath(`${basePath}${appPath === "/" ? "" : appPath}`);
url.search = search;
return url.pathname + url.search;
};이처럼 URL API를 기준으로 하면 BASE_PATH가 무엇이든 정확하게 매핑되고, 쿼리가 중복되거나 슬래시가 무한히 늘어나는 버그를 예방할 수 있습니다.
| } | ||
| // 장바구니 전체 체크박스 | ||
| const cartSelectAllCheckbox = target.closest("#cart-modal-select-all-checkbox"); | ||
| if (cartSelectAllCheckbox) { |
There was a problem hiding this comment.
문제 상황
무한 스크롤을 window.addEventListener("scroll", …)로 구현하면서 throttle/으로 control 하지 않아 스크롤 시마다 loadNextPage 조건이 계속 확인됩니다. header가 붙은 작은 화면에서도 화면을 조금만 움직이면 계속 loadNextPage가 호출되어 브라우저가 바쁘게 됩니다.
현재 코드의 한계
scroll이벤트는 렌더링 프레임마다 발생하므로loadNextPage진입 조건을 여러 번 계산loadNextPage내부에서getProducts요청을isLoading플래그로 막지만, 조건 판단 자체로 CPU 낭비가 발생- 예를 들어 모바일에서 부드럽게 스크롤할 때 프레임 드랍이 생길 수 있음
개선 구조
IntersectionObserver로 트리거 요소(#infinite-scroll-trigger)를 관찰하거나, scroll 핸들러 내부에 requestAnimationFrame/throttle을 적용하면 필요 시점에만 로딩을 트리거할 수 있습니다. 결과적으로 성능이 좋아지고, 추후 “‘무한 스크롤’과 동시에 ‘페이지 끝에 도착했을 때 백그라운드 프리페치’” 같은 확장 요구도 수월해집니다.
devchaeyoung
left a comment
devchaeyoung
left a comment
There was a problem hiding this comment.
이 피드백은 n8n + ai (gpt-5-mini)를 활용하여 자동으로 생성된 내용입니다.
이번 PR은 React 없이 Vanilla JS로 SPA 쇼핑몰 전반 기능을 매우 충실하게 구현한 점이 돋보입니다. 라우팅, 상태관리, 무한 스크롤, URL 쿼리, 캐시, 장바구니 모달 등 요구사항을 체계적으로 맞추어가셨네요. 👍
<추가질문> 요약: 지영님은 SPA 라우팅, 상태 관리, 이벤트 구조, 무한 스크롤 구현에 대해 깊이 고민하시면서 동시에 AI 도움을 받았고, 현재 구조와 앞으로 개선 방향에 대한 문의를 해주셨습니다.
핵심 답변은,
- 이벤트 핸들러는 도메인별로 분리하는 것이 유지보수와 확장성에 유리합니다.
- 라우터 경로 정규화는 주석 보강과 일부 코드 간결화를 시도해볼 수 있습니다.
- 상태 관리는 모두 Observer 패턴으로 통일할 필요는 없으며, 여러 컴포넌트가 공유하거나 빈번히 변경되는 상태에 집중하는 것이 좋습니다. 상품 데이터 캐싱은 필요에 따른 선택이며, 읽기 중심 데이터는 기존 캐시 전략 유지해도 무방합니다.
구조적 총평으로,
이번 구현은 관심사 분리를 충분히 고민하시고 Observer 패턴, History API, URL 상태 관리 등 핵심 아키텍처 개념을 적절히 활용했습니다. 다만 이벤트 처리, 컴포넌트 업데이트, 상태 관리 일관성 부분에서 개선 여지가 있어 다음 단계 학습 주제로 삼기 좋습니다.
질문에대한 답변
1. 질문 요약
지영님은 SPA 라우팅의 History API 사용과 경로 정규화, Observer 패턴을 이용한 상태 관리, 이벤트 위임 및 DOM 조작, URL 기반 상태 관리, 무한 스크롤 구현 과정과 어려움에 대해 자세히 기술해주셨고, 현 구조에 대해 의견 및 개선 방안을 묻고 계십니다.
2. 현재 선택의 장단점
- 라우팅은 History API 활용 및 경로 정규화를 통해 배포환경까지 대비한 견고한 구현이 돋보입니다.
- 상태 관리는 장바구니에 Observer 패턴을 적용해 여러 UI 자동 동기화를 구현했고, URL 기반 필터 상태 관리도 자연스럽고 바람직합니다.
- 무한 스크롤 중복 호출 방지, 카테고리 UI 동기화 등 현실적 문제도 잘 해결하셨습니다.
다만,
- 모든 이벤트를 main.js에 한꺼번에 넣어 처리하면 복잡도와 유지보수성이 떨어질 수 있고,
- DOM 전체 교체로 인한 UI 깜빡임, 상태 초기화 문제,
- 상태 관리가 장바구니에 집중되고 다른 부분엔 분산된 점,
- IntersectionObserver 활용 미흡 등 미세 조정이 필요해 보입니다.
3. 실무에서라면 이렇게 설계할 것 같아요
- 이벤트 관리: 각 도메인별 이벤트 핸들러 모듈로 분리해 관심사 분리 및 모듈화를 추진하고,
- 라우팅 경로 관리: 경로 정규화 함수에 주석과 검증 추가해 명확성과 가독성을 강화하며,
- 상태 관리: UI 여러 곳에서 공유되고 복잡한 변경을 겪는 상태에만 Observer 패턴 적용하고, 상품 데이터는 읽기캐시 전략으로 유지,
- 렌더링 최적화: 스크롤 감지에 IntersectionObserver 활용, DOM 업데이트를 변경된 부분만 적용하는 방향 탐색,
- 프레임워크 고려: 반복적인 컴포넌트 라이프사이클 관리나 이벤트 핸들링 개선이 필요하다면 React 등의 도입도 고민해보면 좋겠어요.
4. 앞으로 구조를 잡을 때 참고하면 좋은 포인트
- 관심사별 이벤트 분리와 init/cleanup 패턴으로 이벤트 중복 및 충돌 방지
- 상수 및 상태명 네이밍 일관성 유지로 협업 편의성 증진
- 상태 변경 주기를 명확히 하고 렌더링 최소화 전략 수립
- URL 쿼리, 상태, API 캐싱 간 역할 구분과 일관된 데이터 흐름
- UI 컴포넌트 라이프사이클 직접 관리 고려 및 테스트 용이성 확보
지영님처럼 직접 SPA를 Vanilla JS로 구현하며 아키텍처 고민을 하신 경험은 앞으로 어떤 프레임워크를 다루더라도 큰 밑거름이 될 것입니다. 다음 단계에서 이벤트 모듈화, 렌더링 최적화, 상태관리 확장에 도전을 계속해보면 좋겠습니다.
| pushWithNoRender({ path: "/" }); | ||
| } else if (cat1Btn) { | ||
| selectedCat1 = cat1Btn.dataset.category1; | ||
| selectedCat2 = null; |
There was a problem hiding this comment.
지영님, main.js에서 모든 이벤트 핸들러를 한 곳에 몰아서 처리하고 계신 점 잘 보았습니다. 👍
하지만 이렇게 한 파일에 많은 이벤트를 집중하면 복잡도가 높아지고, 코드 유지보수와 확장에 어려움이 생길 수 있어요. 예를 들어 장바구니, 상품 카드, 카테고리 필터 등 담당하는 영역이 섞여있어 각 기능 변경 시 의도치 않은 영향도 우려됩니다.
이 부분은 다음과 같이 분리해보시면 좋을 것 같아요.
// 각 도메인별 이벤트핸들러 파일 예시
import { initCartEvents } from './events/cartEventHandlers.js';
import { initProductEvents } from './events/productEventHandlers.js';
import { initCategoryEvents } from './events/categoryEventHandlers.js';
// main.js
initCartEvents();
initProductEvents();
initCategoryEvents();- 이벤트 위임은 유지하되 핸들러 내부 로직만 분리합니다.
- 각 모듈에서 자신만의 이벤트 핸들링에 집중하며 init/cleanup 함수를 제공
- 이벤트 중복방지 및 이름 충돌 우려는 네이밍 컨벤션과 DOM 구조 설계를 통해 해소합니다.
이렇게 분리하면 협업, 테스트, 재사용성도 개선되고, 규모 커질 때 관리가 훨씬 쉬워집니다.
|
|
||
| const normalizePath = (value = "/") => { | ||
| const withLeading = ensureLeadingSlash(value.trim()); | ||
| if (withLeading === "/") return "/"; |
There was a problem hiding this comment.
BASE_PATH가 서브 경로일 때, 경로 정규화 부분을 조금 더 명확하게 다듬을 수 있어요. 지영님께서 작성한 코드는 다음과 같습니다:
const toAppPath = (pathname = "/") => {
const normalized = normalizePath(pathname);
if (basePath === "/") return normalized;
if (!normalized.startsWith(basePath)) return normalized;
const stripped = normalized.slice(basePath.length) || "/";
return normalizePath(stripped);
};이 구현은 문제는 없지만, 가독성을 위해 다음과 같이 변경할 수 있습니다:
const toAppPath = (pathname = "/") => {
const normalized = normalizePath(pathname);
if (basePath === "/") return normalized;
// basePath가 접두어가 아닌 경우 원래 경로 반환
if (!normalized.startsWith(basePath)) return normalized;
// basePath 제거 후, 빈 문자열일 경우 루트 경로 처리
const stripped = normalized.substring(basePath.length) || "/";
return normalizePath(stripped);
};- slice 대신 substring 사용은 선호도의 문제이지만 의미가 명확해집니다.
- 주석을 추가하여 의도를 분명히 해두면 다른 개발자나 미래의 지영님께서 읽기 좋습니다.
- 혹은
startsWith검사를 엄격히 한다면basePath가 '/'로 끝나도록 환경설정하는 것도 좋겠습니다.
| @@ -0,0 +1,76 @@ | |||
| const CART_STORAGE_KEY = "shopping_cart"; | |||
There was a problem hiding this comment.
장바구니 상태 관리를 Observer 패턴으로 잘 구현하셨습니다. 👍 이 부분은 여러 컴포넌트가 같은 상태를 구독해 유지보수성도 좋고, UI 동기화에 효과적입니다.
다만, 지영님 질문처럼 프로젝트 전반적으로 상태 관리를 어떻게 일관성 있게 할지 고민될 수 있어요.
-
상태 관리 대상 기준
- 여러 UI 컴포넌트에서 동시에 사용하거나, 복잡하게 상태가 변동되는 데이터 → Observer 패턴 등 명시적 상태 관리 추천
- 단일 컴포넌트 내에서만 사용하거나, 변경이 적은 임시 상태 → 로컬 변수나 DOM으로 처리 가능
- URL 쿼리 같은 경우 URL이 상태 저장소 역할을 하기 때문에 별도 store가 없는 것도 자연스러운 선택입니다.
-
전체 상품 데이터(productCache, infiniteScrollState 등)
현재 상품 데이터는 주로 읽기 전용이고, 변경 빈도가 적어 간단한 캐시 Map과 객체로 다루는 것은 실용적이에요.다만 실무에서 데이터 변경이 빈번하거나, UI가 여러 곳에서 동기화되어야 한다면
productStore같은 상태 관리 모델로 전환하는 것이 유지보수에 유리합니다. -
무한 스크롤 상태
infiniteScrollState에 Observer 기능을 붙여 직접 구독 구조를 구현하면 확대성은 있지만, 현재는 단순히 main.js에서만 관리하고 있으니 그대로 유지해도 괜찮습니다. -
모달 열림/닫힘
모달 상태는 빈번하게 변하고 UI 여러 곳에서 참조될 수 있으니 상태로 관리하고 Observer 패턴 적용해도 좋지만, 현 구조처럼 DOM 상태로 나타내는 방법도 나쁘지 않습니다.
요약하면, 모든 상태에 Observer 패턴을 적용할 필요는 없고, 여러 컴포넌트가 공유하고 복잡한 변경 로직을 다루는 상태에 집중하는 것이 가치 있습니다.
| const limit = Number(query.get("limit")); | ||
| const sort = query.get("sort") || "price_asc"; | ||
| const [products] = await Promise.all([ | ||
| getProducts({ search, category1: selectedCat1, category2: selectedCat2, limit, sort }), |
There was a problem hiding this comment.
무한 스크롤 구현에서 중복 요청 방지와 상태 초기화를 고민하신 점이 인상적입니다. 👍
특히 isLoading 플래그를 활용하여 스크롤 연속 트리거에 의한 중복 요청을 막는 설계가 좋네요.
실무에서는 성능과 확장성을 위해 직접 스크롤 이벤트 대신 IntersectionObserver API 사용을 추천합니다. 이렇게 하면 불필요한 이벤트 호출을 줄이고, 특정 시점에서만 데이터를 로드할 수 있습니다.
const observer = new IntersectionObserver((entries) => {
if (entries[0].isIntersecting) {
loadNextPage();
}
});
const sentinel = document.getElementById("infinite-scroll-trigger");
observer.observe(sentinel);또한 검색어나 필터 변경 시 무한 스크롤 상태를 초기화하는 부분도 중요합니다. 현재 구현이 충분하지만, 상태 초기화 시점과 UI 반영 타이밍을 좀 더 명시적으로 분리하면 예기치 않은 깜빡임/이전 데이터 노출을 줄일 수 있어요.
| <p class="text-lg font-bold text-gray-900"> | ||
| ${Number(lprice).toLocaleString()}원 | ||
| </p> | ||
| </div> |
There was a problem hiding this comment.
ProductList 컴포넌트에서 로딩 상태일 때 스켈레톤 UI를 보여주고, 데이터가 준비되면 실제 상품 목록을 렌더링하는 패턴이 깔끔합니다. 👍
다만, 현재는 문자열 템플릿을 innerHTML (또는 outerHTML)로 교체하는 방식이라 상태 별로 변경분만 업데이트하기 어렵고, 스크롤 위치, 폼 컨트롤 상태 등이 초기화될 수 있습니다.
이 부분은 다음 두 가지를 고려해보시면 좋아요:
- 변경된 부분만 DOM 조작하기
- 예: 기존 그리드 내에서 이전 데이터와 비교해 실제 변경된 엘리먼트만 교체
- 하지만 Vanilla JS로 직접 구현하려면 복잡함 증가
- 가상 DOM 또는 프레임워크 도입 고려
- React, Vue, Svelte 같은 라이브러리 활용하면 상태 변화에 따른 효율적 업데이트 가능
(강의에서 익힌 Vanilla JS 문법 위주로는 일단 동작 위주 구현 후 추후 개선해보면 좋습니다.)
| import { PageLayout } from "./PageLayout.js"; | ||
|
|
||
| export const HomePage = ({ categories, products, loading }) => { | ||
| const { filters, pagination, products: productList } = products || {}; |
There was a problem hiding this comment.
HomePage 컴포넌트가 SearchForm과 ProductList를 조합해 화면에 렌더링하는 역할을 명확히 맡아서 관심사 분리가 잘 되어 있어 좋아요. 👍
다만 ProductList 컴포넌트 안에서 필터, 페이지네이션 정보를 따로 받아서 관리하고 있으므로, props에서 받은 필터 정보와 infiniteScrollState가 중복 관리되는 부분은 앞으로 리팩터링 시 고민해보면 좋겠습니다.
예를 들어, 상태를 전역에서 관리하고 props로 일관되게 넘겨주는 방향으로 모듈화할 수 있습니다.
3 participants
과제 체크포인트
배포 링크
https://youngh02.github.io/front_7th_chapter2-1/
기본과제
상품목록
상품 목록 로딩
상품 목록 조회
한 페이지에 보여질 상품 수 선택
상품 정렬 기능
무한 스크롤 페이지네이션
상품을 장바구니에 담기
상품 검색
카테고리 선택
카테고리 네비게이션
현재 상품 수 표시
장바구니
장바구니 모달
장바구니 수량 조절
장바구니 삭제
장바구니 선택 삭제
장바구니 전체 선택
장바구니 비우기
상품 상세
상품 클릭시 상세 페이지 이동
/product/{productId}형태로 변경된다상품 상세 페이지 기능
상품 상세 - 장바구니 담기
관련 상품 기능
상품 상세 페이지 내 네비게이션
사용자 피드백 시스템
토스트 메시지
심화과제
SPA 네비게이션 및 URL 관리
페이지 이동
상품 목록 - URL 쿼리 반영
상품 목록 - 새로고침 시 상태 유지
장바구니 - 새로고침 시 데이터 유지
상품 상세 - URL에 ID 반영
/product/{productId})상품 상세 - 새로고침시 유지
404 페이지
AI로 한 번 더 구현하기
과제 셀프회고
React 없이 개발은 생각해본적 없었는데, 프레임워크의 소중함을 다시한번 느꼈습니다. 구현해야 할 코드 양이 꽤 많아 물리적인 시간도 많이 필요했고, 개념으로만 스치듯 알고 있던 내용과 부족한 부분을 자세히 살펴보지 못한채 완료하기 급급했던 점은 조금 아쉬움이 남았습니다.
발제 주제를 보는 순간 React 없는 환경에서는 처음이었기 때문에 과연 가능할까 싶었는데, 반 정도는 React와 비슷했고 반 정도는 React의 고마움을 느꼈습니다. 처음 React를 접했을떄 흐름이 중간중간 끊어지는 느낌을 많이 받았었는데 그 부분이 많이 해소되었고, 편하게 사용했던 라우팅, 상태 관리 같은 기능들을 직접 구현하면서 프레임워크가 내부적으로 하고 있는 일에 대해 조금은 윤곽이 보였습니다.
라우팅 하나 구현하는데도 History API를 공부해야 했고, 상태 관리 하나 만드는데도 Observer 패턴을 이해해야 했습니다. 하지만 이 과정에서 브라우저가 어떻게 동작하는지, 프레임워크가 내부적으로 무슨 일을 하는지 조금씩 보이기 시작했습니다.
기술적 성장
SPA형태의 페이지 이동
당연하게 생각했던 SPA였는데 직접 구현해 보니 라우팅을 꼬이지 않도록 하기 위해 많은 신경을 썼습니다. 브라우저가 제공하는 History API를 사용하되, 중복 네비게이션을 방지하기 위해 현재 경로와 목표 경로를 비교하는 로직도 추가했습니다. 같은 경로로 이동하려고 하면 아무 동작도 하지 않아 불필요한 렌더링을 막았습니다.
pushState,popstate)를 활용한 클라이언트 사이드 라우팅 구현history.pushState()로 페이지 새로고침 없이 URL 변경GitHub Pages의 서브 경로 배포 환경(
/front_7th_chapter2-1/)을 고려한 경로 정규화 로직을 구현해야 했습니다. 로컬환경에서는 그래도 History API로 어느정도 처리가 가능했는데, 배포를 하려다 보니, repo 경로가 생기며 배포 환경에서 라우팅이 깨지는 문제가 발생했습니다.=> 배포시점에 라우팅 깨지는 문제는 AI도움을 받아 해결했는데 아무래도 배포 환경에서 즉시 테스트가 어렵다 보니 시간이 꽤 소요되었습니다. 결국 라우팅 간에 정규화로직으로 보완하였습니다.
여전히 브라우저가 내부적으로 어떻게 이걸 처리하는지는 아직 완전히 이해하지 못했습니다.
history.pushState()를 호출하면 브라우저의 주소창은 변경되는데, 왜 서버에 요청을 보내지 않는지?popstate이벤트가 발생하는데, 어떻게 처리되는건지?이런 부분들은 브라우저 엔진의 내부 동작과 관련된 것 같은데, 아직 그 레벨까지는 이해하지 못했습니다. 하지만 "History API를 사용하면 URL을 변경해도 페이지가 새로고침되지 않는다"는 것만 알아도 SPA를 구현하는 데는 충분했습니다.
상태 관리 패턴
장바구니 기능을 구현하면서 Observer 패턴을 이해하고 적용해봤습니다. 처음에는 장바구니에 상품을 추가할 때마다 수동으로 UI를 업데이트하는 코드를 작성했는데, 이렇게 하니 코드가 여기저기 흩어지고 업데이트를 빠뜨리는 경우가 생겼습니다.
subscribe/notify구조로 상태가 변경되면 자동으로 구독자들에게 알림Observer 패턴을 적용하고 나니
cartStore.addToCart()만 호출하면 관련된 모든 UI가 자동으로 업데이트되어서 코드가 훨씬 깔끔해졌습니다.직접 구현하면서 느낀 한계와 복잡함이 바로 React가 해결해주고 있던 문제들이었습니다. 예를 들어 상태가 변경될 때마다 어떤 UI를 업데이트해야 하는지 일일이 관리해야 했고, 이 과정에서 실수로 업데이트를 빠뜨리면 화면과 데이터가 불일치하는 버그가 발생했습니다. React의 자동 리렌더링이 얼마나 편리한 기능인지 새삼 깨달았습니다.
이벤트와 DOM 조작
React에서는 JSX와 가상 DOM 덕분에 직접 DOM을 건드릴 일이 거의 없었는데, Vanilla JS로 구현하면서 DOM 조작이 어려웠습니다. 특히 이벤트 위임 패턴을 활용해
document.body에서 모든 클릭 이벤트를 처리하고,closest()메서드로 실제 타겟을 찾는 방식이 인상적이었습니다.React에서는
onClickprop만 넘기면 끝이었는데, 이벤트를 DOM마다 하나하나 적용해야 한다는게 많이 번거롭고 노가다스러운느낌도 들었습니다.URL 기반 상태 관리 (쿼리 파라미터)
React에서는
useState로 검색어나 필터 상태를 관리하지만, 이번 프로젝트에서는 URL 쿼리 파라미터를 상태 저장소로 활용되고 있다는걸 마지막에 가서 이해했습니다./?search=노트북&category1=전자제품)무한 스크롤 구현 (with AI..)
무한 스크롤은 이번 과제에서 가장 어려웠던 부분입니다. 개념은 이해했지만 실제로 구현하려니 고려해야 할 것들이 너무 많았습니다. 스크롤 이벤트를 감지해서 페이지 하단에 도달하면 다음 페이지 데이터를 불러오는 것까지는 간단했는데, 문제는 그 이후였습니다.
가장 먼저 마주한 문제는 중복 요청이었습니다. 스크롤을 빠르게 내리면 같은 페이지를 여러 번 요청하는 현상이 발생했습니다. 이를 해결하기 위해
isLoading플래그를 사용해서 로딩 중일 때는 추가 요청을 막아야 했습니다.두 번째 문제는 상태 초기화 타이밍이었습니다. 검색어나 카테고리를 변경했을 때 기존에 누적된 상품 목록을 초기화해야 하는데, 이 타이밍을 잘못 잡으면 화면에 이전 검색 결과가 잠깐 보이는 버그가 발생했습니다.
세 번째는 페이지 전환 시 처리였습니다. 상품 상세 페이지로 갔다가 뒤로가기로 돌아왔을 때, 무한 스크롤 상태를 어떻게 유지할지 고민이 많았습니다. 처음부터 다시 로드할지, 아니면 이전 상태를 유지할지 결정해야 했습니다.
솔직히 이 부분은 AI의 도움을 많이 받았습니다. 특히
infiniteScrollState객체의 구조와 중복 요청 방지 로직은 AI가 제안한 코드를 기반으로 작성했습니다. 코드는 동작하지만 아직 완전히 이해하지 못한 부분이 있어서 추가 학습이 필요합니다.자랑하고 싶은 코드
1. 라우터 구현 (
src/utils/router.js)동적 라우팅 파라미터를 정규표현식으로 변환하여 React Router와 유사한 방식으로 구현했습니다.
:id)를 정규표현식으로 변환하여 매칭toAppPath와toBrowserPath함수로 앱 내부 경로와 브라우저 경로를 분리 관리2. 장바구니 상태 관리 (
src/store/cartStore.js)Observer 패턴을 활용하여 상태가 변경되면 자동으로 모든 구독자에게 알림이 전달되어 UI가 업데이트됩니다.
3. 이벤트 위임 패턴 (
src/main.js)모든 이벤트를
document.body에서 위임받아 처리하는 방식으로 구현했습니다. 동적으로 생성되는 요소에도 이벤트가 자동으로 적용됩니다.4. 배포 시 SPA 라우팅 설정
로컬에서는 완벽하게 동작하던 SPA가 GitHub Pages에 배포하니 새로고침하면 404 에러가 발생했습니다. 예를 들어
/product/123페이지에서 새로고침을 누르면 "404 Page Not Found"가 떴습니다.이 두 줄을 추가하니 갑자기 모든 게 정상 동작했습니다. GitHub Pages의 특성을 이해하고 나니 해결책이 명확해졌습니다.
원인:
index.html로 리다이렉트해줌/product/123경로에 실제 파일이 없으면 404를 반환index.html을 반환해야 JavaScript 라우터가 동작함해결:
404.html파일을 보여줌404.html을index.html과 동일하게 만들면, 존재하지 않는 경로 접근 시에도index.html이 로드됨개선이 필요하다고 생각하는 코드
1. main.js의 이벤트 핸들러
현재
main.js에 모든 이벤트 핸들러가 집중되어 있습니다. 장바구니, 상품 카드, 카테고리 필터 등 모든 클릭/변경 이벤트를 하나의 파일에서 처리하고 있어 이부분 분리하거나 이벤트 처리 방법에 대한 고민이 필요합니다.src/events/cartEventHandlers.js: 장바구니 관련 이벤트src/events/productEventHandlers.js: 상품 관련 이벤트src/events/categoryEventHandlers.js: 카테고리 필터 관련 이벤트init()함수를 export하여 main.js에서 초기화2. 무한 스크롤 성능 최적화 필요
현재 스크롤 이벤트를 직접 리스닝하고 있어 스크롤할 때마다 함수가 실행됩니다.
(Intersection Observer) 등의 방식을 사용하여 개선이 필요합니다.
3. 컴포넌트 재렌더링 최적화
현재 컴포넌트들이 문자열 템플릿을 반환하고
innerHTML로 전체 DOM을 교체하는 방식입니다.-> 변경된 부분만 업데이트하는 방식으로 개선이 필요한데 상태관리 등과 엮여서 어떻게 처리해야 할지 방향은 없는 상태입니다.
학습 효과 분석
추가 학습이 필요한 영역
1. 무한 스크롤
infiniteScrollState의 상태 관리 흐름과 필터 변경 시 초기화 로직을 더 깊이 공부 필요2. 컴포넌트 라이프사이클 관리
innerHTML로 전체 DOM을 교체하고 있는데 React의 생명주기를 이해하고 개선해야 함useEffect나componentDidMount/componentWillUnmount같은 개념을 Vanilla JS로 구현하는 방법3. 이벤트 버스 패턴
4. DOM 조작
과제 피드백
좋았던 점
쇼핑몰 사이트 이다보니 왠만한 기능들이 다 포함되어 경험해 볼 수 있었고, 화면녹화와 E2E테스트가 제공되어 일부 텍스트로 불명확했던 내용들이 명확해져서 좋았습니다.
모호하거나 애매했던 부분
어떤 기술이나 어떤 방향으로 학습해야할지 키워드라도 제공되면 좋을것 같습니다.
AI 활용 경험 공유하기
AI 활용 방식
이번 과제는 스터디 과정이었기 때문에 AI에게 직접 코드를 작성해달라고 하기보다는, 구현 방향성을 물어보고 먼저 직접 구현해보려고 노력했습니다.
예를 들어 URL 기반 상태 관리(쿼리 파라미터)를 구현할 때, AI가 이렇게 단계별로 가이드해줬습니다:
쿼리스트링 구현 흐름 (AI 가이드)
이런 식으로 AI가 큰 그림을 제시해주면, 그걸 바탕으로 직접 코드를 작성해보고, 막히는 부분이 생기면 다시 질문하는 방식으로 진행했습니다.
전반적으로 AI가 방향성을 잡는 데 많은 도움을 줬습니다.
AI 도움을 많이 받은 부분
무한 스크롤과 배포 시 라우팅 설정은 AI의 도움을 많이 받았습니다.
1. 무한 스크롤 구현
처음에는 개념만 이해하고 직접 구현하려 했는데, 스크롤을 빠르게 내리면 같은 페이지를 여러 번 요청하는 문제, 검색어 변경 시 기존 목록이 남아있는 문제 등이 계속 발생했습니다. AI가 제안한
infiniteScrollState구조를 기반으로 구현했고, 특히isLoading플래그로 중복 요청을 방지하는 로직은 AI가 제안한 것을 그대로 사용했습니다. 코드는 동작하지만 아직 완전히 이해하지 못한 부분이 있어서 추가 학습이 필요합니다.2. 배포 시 SPA 라우팅 설정 및 경로 정규화
GitHub Pages에 배포했을 때 두 가지 문제가 발생했습니다:
/product/123페이지에서 새로고침하면 404 에러 발생/인데 배포는/front_7th_chapter2-1/로 서브 경로가 생김로컬에서는 동작했기 때문에 배포 환경에서만 발생하는 문제를 혼자 해결하기 어려웠습니다. 특히 배포할 때마다 확인해야 해서 디버깅이 힘들었습니다.
Claude가 두 가지 적용하여 해결되었습니다.
해결책 1: 404 폴백 설정
해결책 2: BASE_URL 경로 정규화 로직
AI가
toAppPath와toBrowserPath함수를 만들어서 로컬 경로와 배포 경로를 분리 관리하라고 알려줬습니다:이 정규화 로직 덕분에 로컬과 배포 환경 모두에서 라우팅이 정상 동작하게 되었습니다. 혼자서는 이런 접근 방식을 생각하기 어려웠을 것 같습니다.
느낀 점
AI는 방향성을 제시하고 막힌 부분을 해결하는 데 큰 도움이 되었습니다. 하지만 AI가 제안한 코드를 그대로 복사하기보다는, 왜 그렇게 해야 하는지 이해하려고 노력하는 것이 중요하다고 느꼈습니다.
리뷰 받고 싶은 내용
1. main.js의 이벤트 핸들러 구조 개선 방안
현재
main.js에 모든 이벤트 핸들러가 집중되어 있습니다 (약 150줄 이상). 장바구니, 상품 카드, 카테고리 필터 등 모든 클릭/변경 이벤트를 하나의 파일에서 처리하고 있는데요.이를 도메인별로 분리하는 것이 좋을지, 아니면 현재처럼 중앙 집중식으로 관리하는 것이 더 나은지 궁금합니다. 혹은 이벤트 단위가 아니라 컴포넌트에서 등록/해제 등을 하는 방법도 가능할 것으로 보여서요, 분리한다면 어떤 기준으로 나누는 것이 좋을까요?
2. 라우터의 경로 정규화 로직
router.js에서 BASE_PATH를 고려한 경로 정규화를 구현했는데, 이 부분이 복잡하게 느껴집니다:배포 환경(GitHub Pages)에서 BASE_URL이
/front_7th_chapter2-1/처럼 서브 경로일 때를 대응하기 위한 로직인데, 더 간결하고 명확하게 작성할 수 있는 방법이 있을까요?3. 상태 관리 구조
현재 프로젝트에서 상태 관리 방식이 일관되지 않습니다.
현재 구현 방식:
cartStore(Observer 패턴) - 여러 곳에서 구독하여 자동 UI 업데이트infiniteScrollState(단순 객체) - main.js에서 직접 관리productCache(Map) - 캐싱 용도로만 사용상태 관리가 필요한 데이터의 기준
현재 장바구니는 전역 store + Observer 패턴 + UI 자동 업데이트로 관리하고 있습니다. 그렇다면 다른 UI 데이터들도 모두 이런 방식으로 관리해야 할까요?
productCache에만 저장합니다. 이것도productStore로 만들어서 상태 관리를 해야 할까요?infiniteScrollState객체로 관리 중인데, 이것도 Observer 패턴이 필요할까요?모든 수정 가능한 UI 데이터를 Observer 패턴으로 통일하는 것이 좋을까요?
어떤 데이터를 상태로 관리하고, 어떤 데이터는 그냥 두어야 하는지 기준이 궁금합니다.
상품 데이터 관리 (중복 API 호출 문제)
동일한 상품 데이터인데 API 조회가 너무 많이 발생합니다.
productStore를 만들어서 한번에 관리하는게 좋을까요??(스터디 환경이라 데이터가 변동이 없는거고, 실제 환경이면 데이터 변동이 있으니 매번 호출해야 할까요?)