[5팀 오새듬] Chapter2-1. 프레임워크 없이 SPA 만들기 #37
Conversation
…e pull request trigger from deployment workflow
JunilHwang
left a comment
JunilHwang
left a comment
There was a problem hiding this comment.
이 피드백은 n8n + ai (gpt-5-mini)를 활용하여 자동으로 생성된 내용입니다.
전체 요약 및 구조 피드백
이번 PR에서는 요구사항을 충실히 구현하고, E2E 테스트 커버리지 작성도 잘 되어 있습니다. 상품 목록 로딩, 필터링, 무한 스크롤, 장바구니 모달, 상세 페이지, SPA 네비게이션 등 주요 기능이 체계적으로 구현되었습니다.
현재 아키텍처
- 컴포넌트는 기본적으로 함수형 템플릿 문자열 생성 방식 사용
- 상태 관리는 옵저버 패턴 기반의 자체 구현
cartStore사용 - API 호출은
productApi.js에 모듈화 - SPA 네비게이션은
main.js내 URL 상태와 히스토리 API로 직접 제어 - 무한 스크롤을 위한 별도 유틸 클래스
InfiniteScrollManager로 상태 관리 - 이벤트 리스닝은 주로
main.js에서 바디 위임 방식, 일부 컴포넌트 내부에서 직접 도큐먼트 이벤트 사용
확장성 측면
- 현재 상태, API, UI, 이벤트 관리가 부분적으로 분리되어 있으나, 각 영역 간 결합도가 중간 수준입니다.
- SPA 네비게이션과 URL 동기화 로직이 여러 이벤트 핸들러에 중복되어 있어 유지보수성 측면에서 개선 여지가 큽니다.
- 장바구니 모달 내 이벤트 핸들링의 중복 등록 문제로 사용성 및 성능 최적화가 가능해 보입니다.
- 상품 목록 필터 상태 관리를 DOM에 분산하여 상태를 한 곳에서 집중 관리하는 상태 관리 패턴이 추가되면 좋겠습니다.
제안
- SPA 네비게이션과 URL 쿼리 관리 로직을 별도의 라우터 모듈로 분리하여 일원화하면 상태 관리 및 렌더링 흐름이 명확해집니다.
- 상태 관리는 옵저버 패턴 외에 상태관리 라이브러리 또는 전역 상태 저장소를 참고해 확장성을 높여보세요.
- 이벤트 핸들링은 이벤트 위임과 단일 진입점 관리로 중복 등록과 메모리 누수 문제를 줄이면서 유지보수성을 높일 수 있습니다.
- 컴포넌트별 UI 생성과 상태 변화에 따른 렌더링 분리를 명확히 하는 것이 장기적으로 생산성을 향상시킵니다.
종합적으로 현재 구현은 요구사항을 충실히 반영하면서도, 아키텍처 개선을 통해 유지보수 및 확장성 강화가 가능한 상태입니다. 다음 단계에서는 설계상 개선에 중점을 두고 리팩토링에 도전해보시면 큰 도움이 될 것입니다.### 추가 질문에 대한 답변
- 함수와 변수 이름에 대해 어떻게 더 명확하게 지을 수 있을까요?
함수와 변수 이름은 해당 기능의 역할과 목적을 명확히 드러내야 합니다. 예를 들어, addItem 보다는 addItemToCart처럼 기능을 구체적으로 표시하면, 읽는 이가 함수가 어디에 관련된 것인지 쉽게 파악할 수 있습니다. 비슷하게 상태 변수도 items보다는 cartItems처럼 좀 더 구체적인 명칭을 주는 것도 좋습니다.
- 모듈화와 계층화 방향에 대해 어떻게 생각하시나요?
현재처럼 기능별 모듈로 분리하는 것은 좋은 시작입니다. 다만, 비즈니스 로직과 UI 렌더링 로직이 뒤섞이지 않도록 분리하는 것이 중요합니다. 예를 들어, API 호출과 상태 관리는 별도의 서비스 모듈, UI 렌더링은 컴포넌트 모듈, 라우팅은 라우터 모듈 등으로 계층화하여 관리하는 것을 추천합니다. 이렇게 하면 각 부분의 변경이 독립적으로 이루어질 수 있어 확장성과 유지보수가 용이해집니다.
- 옵저버 패턴 구현에 대해 검토해주실 수 있나요?
옵저버 패턴을 통한 상태 관리 방식은 좋은 접근입니다. 다만 상태 업데이트 시 모든 구독자에게 전체 상태를 전달하는 대신, 변경된 부분만 구독자에게 알리거나, 상태의 흐름을 추적하기 쉽게 액션 타입과 payload를 함께 전달하는 방식을 도입하면 효율적입니다. 또한 상태와 UI 연결이 느슨하게 유지되어야 단위 테스트와 컴포넌트 재사용성이 좋아집니다.
- 컴포넌트 간 의존성을 낮추고 테스트 가능성을 높이는 구조 개선 방안은?
컴포넌트 간 의존성은 이벤트 위임, 콜백 함수 전달, 상태 변경 이벤트 사용 등을 통해 낮출 수 있습니다. 각 컴포넌트는 props나 인자를 통해 데이터를 받고, 외부 상태나 이벤트에 의존하지 않도록 설계하세요. 테스트 시에는 필요한 의존성을 주입(mock)할 수 있어야 하며, 복잡한 DOM 조회나 전역 상태 참조를 줄여야 합니다.
이상으로, 이번 과제 구현 전반에 대해 축하드리며, 위 피드백을 참고하여 아키텍처 및 코드 품질 개선에 도전해보시면 더 큰 성장이 있을 것입니다. 필요하시면 추가 질문 부탁드립니다.
| // MSW 워커 시작 | ||
| await enableMocking(); | ||
| } | ||
| const render = async () => { |
There was a problem hiding this comment.
문제 상황 제시
상품 목록과 검색 필터를 URL 쿼리 파라미터로 관리하며, 각종 상태를 URL과 동기화하는 것은 좋은 접근입니다. 하지만 현재 push 함수 내부에서 URL 경로 조작과 렌더링이 직접 결합되어 있어, 만약 이후에 다른 형태의 네비게이션(예: 탭 뷰, 라우터 라이브러리 도입)이나 페이지 전환 요구가 생겼을 때 유연성이 떨어질 수 있습니다.
특히, BASE_URL 처리 로직과 렌더링 호출이 동시에 이루어지고 있어 재사용 및 테스트가 어려울 수 있습니다.
현재 코드 한계
push함수가 경로 변환과 히스토리 관리 및 렌더 호출을 모두 처리한다.- BASE_URL 관련 로직이 중복되고, 경로 변환이 명확하지 않아 유지보수가 어려움.
- 이벤트 핸들러 등에서 직접
render호출을 중복하여 가독성과 확장성 저해.
개선 구조
현재 구조:
push함수에서 경로 조작, 히스토리 작업, 렌더 호출 모두 수행- 이벤트 핸들러에서도
render를 직접 호출
개선된 구조:
push함수는 히스토리 업데이트만 담당- 경로 해석과 렌더링은 별도의
router혹은navigate함수에서 담당 - 이벤트 핸들러에서는
push호출 후 router가 알아서 렌더링하도록 위임
개선사항
- 경로 변환과 유효성 검사 로직 별도 함수 분리 (예: normalizePath)
- 히스토리 조작과 렌더링 로직는 분리하여 단일 책임 원칙에 부합
- SPA 라우터 진입점을 분리해 라우팅 확장에 유리하도록 구현
// ❌ 현재 방식
export const push = (path) => {
/* ...
history.pushState(null, null, finalPath);
render(); // 직접 렌더 호출
};
// ✅ 개선된 방식
const normalizePath = (path) => {
// BASE_URL 관련 정리 로직
// ...
return finalNormalizedPath;
};
export const push = (path) => {
const newPath = normalizePath(path);
history.pushState(null, null, newPath);
// 렌더링은 router 내부에서 처리
};
const router = () => {
const path = normalizePath(window.location.pathname);
// 경로에 따라 컴포넌트 렌더링 수행
};
window.addEventListener('popstate', router);
// 이벤트 핸들러
const handleNavigation = (e) => {
e.preventDefault();
push(e.target.href);
router();
};이렇게 개선 시 네비게이션과 렌더링 처리 분리가 명확해지고, 코드 유지 보수성 및 확장성이 향상됩니다.
|
|
||
| /** | ||
| * 상태 초기화 | ||
| */ |
There was a problem hiding this comment.
문제 상황 제시
무한 스크롤 기능이 잘 동작하지만, 카테고리, 필터, 검색어 등 다양한 조건에 의한 상품 목록 변화시 상태 리셋과 페이지 초기화가 복잡한 구조입니다. 또한, URL 쿼리와 일부 상태가 중복 및 분산 관리 되면서 상태 관리 측면에서 확장성에 제한이 있습니다.
특히, 여러 조건 변경 시 강제로 Observer를 재생성하고 DOM 직접 조작하는 부분은 코드가 커질수록 유지보수가 어려워질 수 있습니다.
현재 코드 한계
- 상태 값이 InfiniteScrollManager 내부와 DOM 요소(검색창, select 박스)에서 분산됨
- 상태가 중복 관리되어 필터 변경 시마다 reset + init이 수동으로 반복됨
- UI 업데이트가 DOM에 직접 method 호출로 이루어져 재사용성 및 테스트 어려움
개선 구조
현재 구조:
- InfiniteScrollManager가 상태와 UI 제어를 모두 관리
- 필터 및 검색 상태를 DOM에서 직접 참조
개선된 구조:
- 상태 관리는 전역 또는 별도 상태 관리(Store)에서 일원화
- 무한 스크롤 매니저는 순수 로직만 담당
- UI 렌더링은 컴포넌트 함수로 분리하여 인자의 변화에 따라 재렌더링
개선사항:
- URL 쿼리 파라미터, 필터 상태를 중앙 집중화하여 external state로 관리
- infiniteScrollManager는 현재 페이지와 로딩 상태만 관리
- 상태 변화시 자동으로 UI를 갱신하는 형태로 변경
// ❌ 현재 방식
class InfiniteScrollManager {
readCurrentParams() {
// DOM에서 검색어, 카테고리 읽음
}
loadNextPage() {
if (params changed) reset();
// fetch 후 DOM 직접 조작
}
}
// ✅ 개선된 방식
// 상태는 store에서 관리
const state = {
filters: { search, category1, category2, sort, limit },
page: 1,
loading: false,
products: [],
};
// 무한스크롤 매니저는 상태 변경에 따른 페이지 증가, 요청만 담당
class InfiniteScrollManager {
loadNextPage() {
if(state.loading) return;
state.loading = true;
fetchProducts(state.filters, state.page + 1).then(products => {
state.products = [...state.products, ...products];
state.page++;
state.loading = false;
renderProductList(state.products);
});
}
}이러한 개선으로 상태와 UI가 명확히 분리되어 코드 가독성, 테스트 용이성, 유지보수성 및 확장성이 좋아집니다.
| const existingItemIndex = state.items.findIndex((item) => String(item.productId) === productId); | ||
|
|
||
| if (existingItemIndex !== -1) { | ||
| // 이미 있는 상품이면 수량만 증가 (불변성 유지) |
There was a problem hiding this comment.
문제 상황 제시
현재 cartStore는 옵저버 패턴을 활용해 상태 변화를 구독자에게 알리고 있지만, 상태 변경에 따른 렌더링 reactivity가 수동적입니다. 예를 들어, UI 컴포넌트에서 store를 구독하고 있지만, 상태 변경 시 구체적으로 어떤 UI가 재렌더링되어야 하는지 분산되어 관리되고 있습니다.
장바구니 기능 확장 시(예: 비동기 상태, 다른 컴포넌트와의 상호작용) 상태 관리 코드가 복잡해질 가능성이 높습니다.
현재 코드 한계
- 상태 변경과 UI 변경이 직접 연결되어 있지 않고 구독자에 따라 다르게 처리됨
- 복잡한 로직(수량증가/감소, 선택 항목 등)가 단일 함수에 과도하게 몰릴 위험
- 비동기 저장, 로드 로직이 분산되어 추적이 어려움
개선 구조
현재 구조:
- 상태와 저장소 로직이 한 곳에 통합
- 옵저버가 콜백을 통해 전체 상태를 반환
개선된 구조:
- 상태 변경을 명확히 구분한 액션 함수 분리
- 비동기 처리(예: localStorage 저장) 분리 및 예외처리 강화
- 상태 변경에 따른 특정 파트 재렌더링 가능하도록 세분화된 이벤트 발행
개선사항:
- 상태 변경시 액션별 이벤트(dispatched)를 발생시키고 구독자가 선택적으로 처리
- 상태 변경 전후 체크 및 중앙집중식 저장 관리
// 액션 별 이벤트 발행
const addItem = (product, qty) => {
// ... 상태 변경
notifySubscribers({ type: 'add', payload: product });
};
// 구독자는 원하는 이벤트 타입에 따라 처리 가능
const subscriber = (state, action) => {
switch(action.type) {
case 'add': renderAddItem(action.payload); break;
case 'remove': removeItemUI(action.payload); break;
// ...
}
};이렇게 하면 상태 변경에 따른 UI 갱신 범위를 명확히 하여 불필요한 렌더를 줄일 수 있고, 테스트 용이성과 유지보수성이 향상됩니다.
| } | ||
| }; | ||
|
|
||
| // 선택된 항목 삭제 버튼 표시/숨김 관리 |
There was a problem hiding this comment.
문제 상황 제시
장바구니 모달 이벤트 핸들러들이 매 렌더링마다 재등록되고 있습니다. 특히 모달 내부 UI 갱신시 rerenderModal() 호출 후 다시 이벤트 리스너를 붙이는 구조인데, 이때 이벤트 중복 등록 위험과 메모리 효율성 문제가 존재합니다.
또한 이벤트 위임보다 개별 DOM 요소에 직접 리스너를 부착하는 비효율적인 구조가 커질수록 성능 저하 가능성이 높습니다.
현재 코드 한계
- 모달 UI가 다시 그려질 때마다 각 버튼별로 새 이벤트 리스너 등록
- 이벤트 중복 및 메모리 누수 가능성
- 코드 유지보수성 저하
개선 구조
현재 구조:
- 매번 UI 재렌더링 후, 각 요소마다 이벤트 핸들러 등록(클릭, 체크박스 등)
개선된 구조:
- 이벤트 위임 방식 도입: 모달 내 상위 요소에 이벤트 위임하여 이벤트 처리
- 한 번 등록 후 UI 변경과 관계없이 이벤트 핸들링 가능
개선사항:
#cart-modal-dialog에 single event listener를 등록한 뒤 이벤트 타입과 타겟 확인- 이벤트 핸들러 함수 통합 및 분리
- 리렌더 시 이벤트 리스너 등록 불필요
const modalEventListeners = () => {
const $modalDialog = document.querySelector('#cart-modal-dialog');
if ($modalDialog && !$modalDialog.hasListener) {
$modalDialog.addEventListener('click', e => {
const target = e.target;
if(target.closest('.quantity-increase-btn')) {
const productId = target.closest('.quantity-increase-btn').dataset.productId;
cartStore.increaseQuantity(productId);
rerenderModal();
} else if(target.closest('.cart-item-remove-btn')) {
const productId = target.closest('.cart-item-remove-btn').dataset.productId;
cartStore.removeItem(productId);
rerenderModal();
}
// ... 기타 이벤트
});
$modalDialog.hasListener = true;
}
};위 구조는 이벤트 등록 비용을 줄이고, 모달 재렌더링 후에도 지속적으로 이벤트 처리가 가능하므로 성능과 유지보수에 유리합니다.
|
|
||
| if (!selectedCategory1 || category2List.length === 0) { | ||
| return ""; | ||
| } |
There was a problem hiding this comment.
문제 상황 제시
카테고리 렌더링 함수에 조건 검증 로직이 산재하여 코드 가독성이 떨어지고 중복이 발생하고 있습니다. 예를 들어, Category1 함수 내에서 selectedCategory1이 존재하면 빈 문자열을 반환하는 로직이 있는데, 이는 호출하는 쪽에서 상태를 잘못 이해했을 때 의도와 다르게 동작할 위험이 있습니다.
또, 카테고리 1, 2차 렌더링 및 브레드크럼 처리 로직이 복잡하게 얽혀있어 확장성이 떨어집니다.
현재 코드 한계
- 조건에 따른 렌더링 로직이 분산되어 중복 발생
- UI 컴포넌트별로 상태 의존성이 명확하지 않고, 재사용 어려움
- 카테고리 상태 변경에 따른 일관적인 UI 업데이트 어려움
개선 구조
현재 구조:
- 카테고리 1, 2, 브레드크럼 렌더러가 개별 함수에서 상태에 따라 조건부 렌더링함
개선된 구조:
- 하나의 카테고리 컴포넌트로 통합, 내부에서 단계별 렌더링 분리
- 상태를 props 형태로 받아 통합 관리
- 렌더 함수는 순수 함수여야 하며, 상태 변경시 UI 업데이트 책임 분리
개선사항:
- 카테고리 데이터와 선택 상태 전달 후, 선택된 depth를 바탕으로 렌더링 결정
- 선택 해제(전체) 버튼 및 브레드크럼도 컴포넌트 내에서 일관성 있게 처리
const CategoryFilter = ({ categories, selectedCategory1, selectedCategory2 }) => {
// 1depth, 2depth 카테고리 분리
// 전체 버튼과 브레드크럼 등 일관 처리
// 선택 상태에 따라 버튼 스타일링
// 명확한 구조로 함수 책임 분리
return `...`;
};이렇게 개선하면 UI 변경이 쉽고, 재사용성과 유지보수성이 크게 향상됩니다.
| <div class="bg-white rounded-lg shadow-sm border border-gray-200 overflow-hidden animate-pulse"> | ||
| <div class="aspect-square bg-gray-200"></div> | ||
| <div class="p-3"> | ||
| <div class="h-4 bg-gray-200 rounded mb-2"></div> |
There was a problem hiding this comment.
문제 상황 제시
로딩 상태에서 Skeleton UI를 하드코딩된 문자열로 4개 반복 출력하는 방식은 간단하지만, 상품 카드 갯수 변경이나 UI 변경 시 유연하지 않습니다.
또한, 로딩과 실제 데이터 렌더링 로직이 혼재되어 가독성이 떨어지고 유지보수에 제약을 줄 수 있습니다.
현재 코드 한계
- Skeleton UI가 복제된 문자열 형태로 중복
- 조건부 렌더링이 JSX 혹은 템플릿 함수 분리 없이 한 함수 내에서 처리
- 재사용 가능한 컴포넌트와 역할 분리 부족
개선 구조
현재 구조:
ProductList내에서 loading 플래그에 따라 문자열을 조건부 렌더링
개선된 구조:
- Skeleton, ProductItem 컴포넌트를 분리
- 상위 컴포넌트가 로딩 여부와 데이터를 props로 전달하면 각 컴포넌트가 독립적으로 렌더링
개선사항:
Skeleton컴포넌트는 반복 횟수만큼 배열 생성 후 map 활용ProductList는 상태 구분 없이 오직 데이터 리스트 렌더링에 집중
const SkeletonItem = () => `...`;
const SkeletonList = () => Array(4).fill(null).map(_ => SkeletonItem()).join("");
export const ProductList = ({ loading, products }) => {
if (loading) return `<div>${SkeletonList()}</div>`;
return `<div>${products.map(ProductItem).join("")}</div>`;
};이런 구조는 유지보수성과 UI 테스트 확장에 효과적이며, UI 변경 시 범용 컴포넌트만 수정하면 됩니다.
| @@ -0,0 +1,29 @@ | |||
| // 상품 목록 조회 | |||
| export async function getProducts(params = {}) { | |||
| const { limit = 20, search = "", category1 = "", category2 = "", sort = "price_asc" } = params; | |||
There was a problem hiding this comment.
문제 상황 제시
API 통신 함수가 현재 fetch 호출 직후 바로 JSON 파싱을 수행하지만, 네트워크 오류나 잘못된 응답에 대한 예외처리가 없습니다.
추가 요구사항으로 네트워크 지연, 실패 상황 시 재시도, 에러 메시지 전달 등 개선 필요시 현재 구조는 예외처리 로직을 분산시켜 코드 중복이나 버그가 발생할 수 있습니다.
현재 코드 한계
- fetch 실패 시 예외 전파 되지 않음
- HTTP 상태 코드 검사 부족
- 재시도 로직, 캐싱 등 유연성 부족
개선 구조
현재 구조:
- fetch 호출 후 바로 await response.json();
개선된 구조:
- try-catch 구문 추가로 에러 핸들링 확장
- HTTP 2xx 이외 응답에 대한 처리
- 추후 재시도 정책이나 로컬 캐싱 추가 용이
개선사항:
- 공통 API 호출 util 함수로 fetch 래핑
- 에러 처리, 로딩 상태 관리, 재시도 등 기능 포함
async function safeFetch(url, options = {}) {
try {
const response = await fetch(url, options);
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}
return response.json();
} catch (error) {
console.error("API 요청 오류:", error);
throw error;
}
}
export async function getProducts(params) {
const searchParams = new URLSearchParams(params);
return safeFetch(`/api/products?${searchParams}`);
}이런 구조는 API 통신 안정성과 유지보수성을 높입니다.
| if (e.target.closest(".go-to-product-list")) { | ||
| push(`${import.meta.env.BASE_URL}`); | ||
| render(); | ||
| } |
There was a problem hiding this comment.
문제 상황 제시
검색어, 정렬, 카테고리 등 여러 UI 이벤트에서 URL 업데이트와 렌더 호출이 중복되는 코드가 많고, 비슷한 기능이 여러 이벤트 리스너에 분산되어 있습니다.
이 방식은 코드 중복을 증가시키고, 하나의 변경점이 여러 위치에 영향을 줄 위험이 있어 유지보수성을 떨어뜨립니다.
현재 코드 한계
- URL 쿼리 관리 로직 반복
- 렌더 호출 및 데이터 요청 중복
- 이벤트 핸들러 로직가 분산되어 관리 어려움
개선 구조
현재 구조:
- 이벤트별로 URL 업데이트, API 호출, 렌더 처리 모두 개별 구현
개선된 구조:
- 공통 URL 파라미터 관리 및 상태 업데이트 함수 도입
- 이벤트 핸들러에서는 상태 변경 호출 후 공통 함수가 렌더링 담당
- 불필요한 중복 제거로 코드 간결화 및 가독성 향상
개선사항:
- 상태변경 및 URL동기화 관리 함수 작성
- 예시:
updateFilters(newFilters) - 모듈성 확보 및 추후 기능 확장 용이
const updateFilters = async (newFilters) => {
const urlParams = new URLSearchParams(window.location.search);
Object.entries(newFilters).forEach(([key, value]) => {
if (value) urlParams.set(key, value);
else urlParams.delete(key);
});
const basePath = import.meta.env.BASE_URL;
const newUrl = `${basePath}?${urlParams.toString()}`;
history.pushState(null, null, newUrl);
await render();
};
// 이벤트 핸들러
const handleSortChange = (e) => {
updateFilters({ sort: e.target.value });
};이렇게 한 곳에서 조건 관리 및 URL과 UI 동기화를 하면, 코드 재사용성을 높이고 버그 가능성을 줄일 수 있습니다.
|
|
||
| export const HeaderCart = () => { | ||
| const itemCount = cartStore.getItemCount(); | ||
| console.log("장바구니 아이템 개수:", itemCount); |
There was a problem hiding this comment.
문제 상황 제시
HeaderCart 컴포넌트 내에서 cartStore.getItemCount() 호출과 로그 출력이 렌더 함수 내에 직접 위치해 있고, 콘솔 출력이 너무 빈번하게 발생할 수 있습니다.
또한 상태와 UI가 강하게 결합되어 있어, 장바구니 상태 변경 이외의 상황에도 리렌더링 필요시 코드 변경이 어렵습니다.
현재 코드 한계
- 렌더 함수에 디버깅용 console.log가 남아 있음
- 상태 변화 시 UI 동기화가 직접적이며 제한적
개선 구조
현재 구조:
- 상태 가져오기와 콘솔 출력이 렌더 함수 내에 있음
개선된 구조:
- 렌더 함수는 UI 생성만 담당하고, 상태 추출은 이벤트 구독 콜백 등으로 분리
- 콘솔 로그는 개발 환경에서만 출력하거나 별도 유틸로 분리
개선사항:
- 비즈니스 로직과 UI 로직 분리
- 로그 정리 및 필요시에만 출력
export const HeaderCart = (itemCount) => {
return `...${itemCount > 0 ? `<span>${itemCount}</span>` : ''}`;
};
cartStore.subscribe(state => {
updateHeader(state.items.length);
// 필요하면 debug logger 호출
});이렇게 하면 렌더 함수가 깔끔해지고 디버깅 로그 관리가 쉬워집니다.
|
|
||
| cartStore.addItem( | ||
| { | ||
| productId: product.productId, |
There was a problem hiding this comment.
문제 상황 제시
detailHandler 내에서 DOM 요소 조회와 이벤트 핸들러 등록이 각각의 함수 (insertCart, increaseQuantity, decreaseQuantity)에 분산되어 있습니다. 이 방식은 모듈 재사용 시 DOM 요소가 없는 상황에서 오류를 발생시키거나 이벤트 중복 등록 위험이 있습니다.
또한 전역 document에 click 이벤트를 등록하는 breadCrumb 함수는 이벤트 위임이긴 하지만, 불필요한 이벤트 빈도도 우려됩니다.
현재 코드 한계
- 각 기능별 DOM 조회와 이벤트 핸들러 등록이 분산됨
- DOM이 준비되지 않은 상태에서 실행 시 에러 가능
- 이벤트 위임 관리가 애플리케이션 전반과 이중으로 존재할 수 있음
개선 구조
현재 구조:
- 여러 이벤트 핸들러를 별도 함수에서 독립 등록
- 전역 document에서 클릭 위임 처리
개선된 구조:
- 초기화 시점에 DOM 존재 여부를 확실히 하거나 이벤트 위임 통합
init함수에서 종합적인 이벤트 리스너 등록- 단일 객체 혹은 클래스형 컴포넌트 구조로 이벤트 관리
개선사항:
- DOM 요소 모두 존재 후 이벤트 등록
- 클릭 이벤트 위임 분리 및 관리
const detailHandler = {
init() {
document.body.addEventListener('click', e => {
const target = e.target;
if(target.id === 'add-to-cart-btn') { /* 장바구니 추가 */ }
else if(target.classList.contains('breadcrumb-link')) { /* 브레드크럼 클릭 */ }
// ...
});
}
};
// init 함수는 페이지 렌더링 후 호출이렇게 단일 진입점으로 이벤트를 관리하면, 이벤트 핸들링 일관성과 재사용성, 유지보수가 좋아집니다.
eveneul
left a comment
eveneul
left a comment
There was a problem hiding this comment.
새듬 님 이번 주차도 고생 많으셨습니다! 힘들었던 테스트코드 챕터가 끝나고 자바스크립트 챕터로 오시니 어떠신가요..! 생각보다 어려워서 힘드셨죠? ㅜㅜ 저도 그랬습니다..
최종 마무리할 때는 디버깅용으로 남겨두었던 console.log는 삭제해 주시고, main.js에 많은 코드가 있는데 store로 기능을 따로 뺀 것처럼 무한 스크롤이나 SearchParams, Event 핸들러 같은 건 분리하면 main.js 파일이 많이 간결해질 것 같아용
우리 다음 주차도 파이팅해 봅시다~~
| @@ -0,0 +1,100 @@ | |||
| import { PageLayout } from "../pages/PageLayout"; | |||
|
|
|||
| export const Error = () => { | |||
There was a problem hiding this comment.
컴포넌트인데 파일명이 소문자로 시작하네욥..!!
https://world-developer.tistory.com/84
| <svg class="w-5 h-5 text-red-500" fill="none" stroke="currentColor" viewBox="0 0 24 24"> | ||
| <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M13 16h-1v-4h-1m1-4h.01M21 12a9 9 0 11-18 0 9 9 0 0118 0z"/> | ||
| </svg> | ||
| <span class="text-red-500">상품을 불러오는데 실패했습니다.</span> |
There was a problem hiding this comment.
사실상 에러 표시는 '상품을 불러오는 데 실패했습니다'만 필요한데, 검색쪽 UI도 같이 렌더링하고 있어요
검색쪽 폼은 기본 상태로 초기화시키고 (상태 관리 함수를 따로 구현하든, 아니면 하드코딩으로 박든) Error Component는 상품 그리드쪽만 수정할 수 있으면 더 좋을 것 같습니다!
| @@ -0,0 +1,147 @@ | |||
| // Toast HTML 템플릿 생성 함수 | |||
| const getToastHTML = (result) => { | |||
| if (result === "success") { | |||
There was a problem hiding this comment.
if문도 좋지만 switch문도 한번 고려해 보세요! default값을 지정할 수 있어서 default로 보여져야 할 상황에는 switch문이 더 효과적일 듯 합니다!
|
|
||
| const ProductSort = (filters) => { | ||
| const currentSort = filters?.sort || "price_asc"; | ||
| const options = [ |
There was a problem hiding this comment.
상수 부분은 안에 선언하는 것도 좋지만 시간이 되신다면 /constant 폴더를 만들어서 상수를 한꺼번에 관리하는 게 유지보수성에도 좋을 듯 합니다!
| <div class="text-sm text-gray-500 italic">카테고리 로딩 중...</div> | ||
| `; | ||
|
|
||
| const Category1 = (categories, selectedCategory1) => { |
There was a problem hiding this comment.
Category 버튼을 1뎁스, 2뎁스를 따로따로 만드는 것보다는 하나의 컴포넌트로 합치는 건 어떨까요? 저도 이번 챕터 문제를 풀 때 똑같은 고민을 했다가 성민 님처럼 두 개로 나눈 경험이 있는데요, 지금 생각해 보면 카테고리 뎁스가 더 많아질 때는 어떻게 하지? 생각이 들어서요.
제가 생각한 코드는..
const Category = (attrs, label, isSelected) => /* HTML */ `
<button
${Object.entries(attrs)
.map((k, v) => `data-${k}=${v}`)
.join(" ")}
class="px-3 py-2 text-sm rounded-md border transition-color
${isSelected ? "bg-blue-100 border-blue-300 text-blue-800" : "bg-white border-gray-300 text-gray-700 hover:bg-gray-50"}
>${label}</button>
`;이렇게 만들고, Category 컴포넌트를 사용할 때는,
.map(product => Category({ category1: product }, product, false).map(product => Category({ category1: selectedCategory1, category2: product },
product,
product === selectedCategory2
)
)이런 식으로 해도 좋을 것 같아용
|
|
||
| const data = await getProducts(params); | ||
| const categories = await getCategories(); | ||
| console.log(data); |
3 participants
과제 체크포인트
배포 링크
https://toeam.github.io/front_7th_chapter2-1/
기본과제
상품목록
상품 목록 로딩
상품 목록 조회
한 페이지에 보여질 상품 수 선택
상품 정렬 기능
무한 스크롤 페이지네이션
상품을 장바구니에 담기
상품 검색
카테고리 선택
카테고리 네비게이션
현재 상품 수 표시
장바구니
장바구니 모달
장바구니 수량 조절
장바구니 삭제
장바구니 선택 삭제
장바구니 전체 선택
장바구니 비우기
상품 상세
상품 클릭시 상세 페이지 이동
/product/{productId}형태로 변경된다상품 상세 페이지 기능
상품 상세 - 장바구니 담기
관련 상품 기능
상품 상세 페이지 내 네비게이션
사용자 피드백 시스템
토스트 메시지
심화과제
SPA 네비게이션 및 URL 관리
페이지 이동
상품 목록 - URL 쿼리 반영
상품 목록 - 새로고침 시 상태 유지
장바구니 - 새로고침 시 데이터 유지
상품 상세 - URL에 ID 반영
/product/{productId})상품 상세 - 새로고침시 유지
404 페이지
AI로 한 번 더 구현하기
과제 셀프회고
발제를 들었을 당시에는 재밋어보이는 과제라고 생각을 하면서도 동시에 너무 많은 양인 것 같다는 생각도 들었다. si회사를 다니면서 유지보수만 해오다가 spa를 구성하려고 하니 js를 하던 기억들이 새록새록 나면서도 많이 까먹어 다시 생각해보는 기회가 되었다. 시간이 좀 더 있었더라면 작성한 코드를 리팩토링하고 더 잘 다듬었으면 하는데 이거는 추후에 다시 돌아봐야 될 것 같다.
기술적 성장
자랑하고 싶은 코드
개선이 필요하다고 생각하는 코드
지금 main.js와 다른 컴포넌트 js에서 중복코드도 상당히 많고 지저분하기 때문에 싹 다 갈아 엎어야 되는 부분이라고 생각합니다.
(매우 거슬림)
학습 효과 분석
과제 피드백
과제를 하면서 Observer 패턴을 이해하는 데에 많은 시간을 들였던 것 같습니다. 지금도 어쨋든 작성은 하긴 했지만
이게 맞나 하는 느낌이 들어서 뭔가 빡! 하고 이해된 느낌은 아닌 것 같습니다.
이번주차가 끝나고도 더 학습해야 되는 부분이지만 알아가는 재미가 있었습니다.
AI 활용 경험 공유하기
리뷰 받고 싶은 내용