[3팀 김준모] Chapter2-1. 프레임워크 없이 SPA 만들기 #35
Conversation
JunilHwang
force-pushed
the
main
branch
2 times, most recently
from
c1cdc92 to
9b09aa3
Compare
JunilHwang
left a comment
JunilHwang
left a comment
There was a problem hiding this comment.
이 피드백은 n8n + ai (gpt-5-mini)를 활용하여 자동으로 생성된 내용입니다.
전체 리뷰 요약
이번 PR에서 전반적으로 Hook 기반 상태 관리와 컴포넌트 함수 렌더링 구조를 도입하여 이전 방식 대비 큰 발전이 있었습니다. 상태 관리가 useState 훅으로 분리되고, 이벤트 위임으로 동작하며, API 통신 및 URL 동기화까지 구현되어 있어 매우 훌륭합니다.
다만, 현 구조는 여러 상태 동기화, 이벤트 관리, API 호출 로직이 컴포넌트 내부에 분산되어 있어 향후 기능 추가 및 유지보수 시 복잡도가 증가할 위험이 있습니다.
주요 피드백
- 상태 관리 및 API 호출, 이벤트 핸들러 책임 분리로 코드 명확성 향상 권고
- 무한 스크롤 중복 호출 방지와 상태 업데이트 로직 개선 필요
- 이벤트 처리 함수는 역할별 분리 및 중복 검사 최소화 권장
- 전역 runtime 객체 대신 useState 단일 소스 원칙 준수 유도
- 로딩 및 에러 UI 컴포넌트화 및 재시도 인터랙션 개선
- DOM 직접 조작 대신 상태 중심 UI 렌더링 권장
- 캐싱과 상태 동기화 책임 분리로 데이터 일관성 보장
- URL-상태 동기화 구조 통일 및 중복 코드 제거 권장
- 이벤트 핸들러 등록 해제 철저히 하여 누수 예방
이러한 개선이 반영되면 유지보수성과 확장성이 한층 더 향상될 것입니다.
현재 코드 구조 주요 내용
[Router] => [페이지 컴포넌트 함수(HomePageComponent, DetailPageComponent)]
├─ useState 훅을 통한 상태 관리
├─ URL 파라미터 기반 초기 상태 생성
├─ 이벤트 위임을 통해 사용자 상호작용 처리
├─ API 호출은 컴포넌트 내 별도 비동기 함수로 분리되어 있음
├─ 상태 변경 시 scheduleUpdate로 전체 컴포넌트 재렌더링
├─ 전역 runtime 객체로 상태/함수 참조 저장해 관리
└─ UI는 상태를 기반으로 템플릿 문자열을 만들어 루트 DOM에 삽입
이 구조는 VanillaJS 환경에서 React 스타일의 상태관리를 모방한 점이 특징입니다. 하지만 state, event, side effect 등이 조금 분리되어야 더욱 확장에 강해질 수 있습니다.
<추가질문>: Router 구조 내에서 Hook 기반 렌더링을 자연스럽게 결합하는 법
- Router와 컴포넌트를 명확히 분리하라
- Router는 URL 경로를 매칭하고 Context(파라미터, 쿼리 등)를 컴포넌트에 전달하는 역할만 담당합니다.
- 각 Route에 연결된 컴포넌트는 오로지 전달받은 Context에 따라 훅(useState 등) 기반로컬 상태를 관리하며 UI를 렌더링합니다.
- Renderer 함수를 Router 내부에 일원화하라
- Router는 컴포넌트 실행 결과를 받아 DOM에 삽입합니다.
renderComponent(component, context, rootElement)같은 추상화된 함수가 호출되어 컴포넌트 실행 후 마운트 함수도 호출하게 합니다.
- 훅 상태 저장은 컴포넌트별 분리 유지
- 훅 기반 상태(DOM 마운트, 상태, 업데이트 예약 등)는 컴포넌트 실행단위로 WeakMap 등에 저장합니다.
- 이렇게 하면 Router가 컴포넌트를 다시 실행해도 각 컴포넌트 훅 상태가 따로 유지되어 다중 경로 전환 시 이상이 없습니다.
- 상태 변경은 컴포넌트 내부에서만 발생
- 컴포넌트 내 훅의 setState 함수는 상태 변경후 Router에 등록된
scheduleUpdate를 호출하여 재렌더링을 트리거합니다.
- Router가 페이지 이동시 컴포넌트 Context만 변경
- 경로변경시 (pushState 또는 popstate) Router는 컴포넌트와 Context만 다시 호출, 기존 훅 상태가 재사용되도록
prepareRender및bindRender동작
- Router는 마운트/언마운트 관리
- 컴포넌트가 변경되었으면 이전 컴포넌트의 이벤트를 정리하여 이벤트 누수 방지.
예) Router 구현 (의사코드):
const renderComponent = (component, context) => {
prepareRender(component);
const html = component(context); // 훅 state 사용
root.innerHTML = html;
if (component.mount) component.mount();
};
window.onpopstate = () => {
const route = matchRoute(location.pathname);
renderComponent(route.component, route.params);
};
const navigate = (path) => {
history.pushState({}, '', path);
const route = matchRoute(path);
renderComponent(route.component, route.params);
};훅, 렌더링, 라우터 구조가 느슨하게 연결되어 한 쪽 변경이 다른 쪽에 미치는 영향을 최소화하며 상태 재사용과 UI 갱신이 자연스럽게 동작하게 됩니다.
필요하다면 useEffect와 유사한 사이드 이펙트 구간을 구현해 API 요청 또는 외부 상태와 연동하는 패턴을 사용할 수 있습니다.
| @@ -0,0 +1,803 @@ | |||
| import { PageLayout } from "./PageLayout"; | |||
There was a problem hiding this comment.
1. 문제 상황 제시
구체적인 문제 상황:
현재 HomePage 컴포넌트는 useState 훅 기반 상태 관리를 사용하고 있지만, 상태 변경 시 데이터 패칭, URL 동기화, 무한 스크롤 트리거 등이 복잡하게 얽혀 있어 유지보수하고 확장하기 어려울 수 있습니다.
현재 코드의 한계:
- 상태 동기화 로직과 API 호출이 컴포넌트 코드 내 깊게 섞여 있어 책임 분리가 부족합니다.
- URL 파라미터와 상태 간 양방향 동기화에서 상태 초기화 및 재설정 조건들이 중복되고 복잡하게 작성되어 있습니다.
- 무한 스크롤의 상태 관리와 중복 요청 방지 플래그가 분산되어 있고, 상태 업데이트 시점이 명확하지 않아 확장 시 버그 발생 위험이 있습니다.
2. 근본 원인
핵심 문제:
상태 관리, 데이터 패칭, URL 관리, UI 렌더링 로직이 모두 한 컴포넌트 함수 내에서 처리되어 구조가 단일 책임 원칙을 위반하고 있다.
왜 문제인가:
이 구조로 진행하면 신규 요구사항(예: 필터 조건 추가, 무한 스크롤 트리거 개선 등)이 발생할 때마다 기존 코드 전체에 영향을 주며, 컴포넌트 로직이 복잡해져 유지보수가 어려워집니다.
3. 개선 구조
현재 구조:
HomePageComponent(state 관리 + 이벤트 핸들러 + 데이터 호출 + URL 동기화) -> DOM 렌더링
개선된 구조:
- 상태 관리와 상태 갱신 훅으로 역할 분리
- API 호출을 별도 비동기 함수나 훅으로 분리
- URL 파라미터 파싱 및 반영을 별도 유틸로 추출
- 이벤트 핸들러는 상태 갱신 호출만 담당
- 무한 스크롤 옵저버는 상태와 연동해 명확한 역할 분담
개선 사항:
- [개선 사항 1] 데이터 호출 및 상태 업데이트 분리:
useEffect또는 커스텀 훅으로 데이터 요청 처리 - [개선 사항 2] URL 쿼리 파싱과 상태 매핑 유틸 함수 분리 및 상태 변경 시 URL 자동 sync
- [개선 사항 3] 무한 스크롤 로직을 커스텀 훅이나 유틸로 분리하여 재사용성 확보
// ❌ 현재 방식
// API 요청과 상태 변경, URL 동기화가 모두 컴포넌트 내에 있음
const HomePageComponent = () => {
const [filters, setFilters] = useState(...);
// ...중략...
// api 호출
loadInitialData(query);
// 이벤트 핸들러가 URL 변경과 상태 변경을 직접 호출
};
// ✅ 개선된 방식
const useProductData = (filters, pagination) => {
const [data, setData] = useState({ products: [], total: 0, isLoading: false, error: null });
useEffect(() => {
setData((prev) => ({ ...prev, isLoading: true }));
fetchProducts(filters, pagination)
.then(setData)
.catch((error) => setData({ products: [], total: 0, isLoading: false, error }));
}, [filters, pagination]);
return data;
};
const HomePageComponent = () => {
const [filters, setFilters] = useState(...);
const [pagination, setPagination] = useState(...);
const { products, total, isLoading, error } = useProductData(filters, pagination);
// 이벤트 핸들러는 필터 상태만 변경
const handleFilterChange = (newFilters) => setFilters(newFilters);
// URL sync는 useEffect 내에서 분리 처리
useEffect(() => {
syncUrlFromState(filters, pagination);
}, [filters, pagination]);
return renderUI({ filters, pagination, products, isLoading, error });
};| const target = event.target; | ||
| if (!(target instanceof Element)) return; | ||
| if (!target.closest(".cart-modal")) return; | ||
| if (!target.matches("input[type='checkbox']")) return; |
There was a problem hiding this comment.
2. 상품 추가 로딩 중 중복 요청 방지 미흡
구체적인 문제 상황:
무한 스크롤로 페이지 하단에 도달했을 때 새로운 데이터를 로드하는 로직에서 'isLoadingMore' 플래그를 사용하는데, 데이터 요청이 여러 조건(초기 로딩, 추가 로딩)과 섞여 중복 호출 가능성이 내포되어 있습니다.
현재 코드의 한계:
- isLoadingMore, isInitializing 상태가 각각 관리되지만, 명확한 데이터 요청 구분과 업데이트 타이밍이 모호함
- 페이지 로드 중 중복 요청이 발생할 가능성이 있어 API 비용 증가 혹은 UI 오류를 유발할 수 있음
- 빌드된 상품 배열 관리가 복잡하며, 현재 페이지 대비 실제 로딩된 상품 간 불일치 가능성 존재
2. 근본 원인
핵심 문제:
상태 플래그와 데이터 요청 로직의 응집도가 낮고, 상태 업데이트가 비동기적으로 분산 구현되어 있어서 중복 호출을 완전히 제어하지 못함.
왜 문제인가:
이로 인해 사용자가 빠르게 스크롤하거나 조건 변경이 빈번할 때 의도치 않은 요청이 중복 실행되어 사용자 경험에 악영향 및 시스템 부하 증가 가능성 있다.
3. 개선 구조
개선 사항:
- isLoading과 isLoadingMore 플래그를 적절히 조합하여 요청 상태를 세분화 및 명확히 정의한다.
- 요청 함수에서 중복 호출 방지를 위한 Promise 상태 등으로 한정함
- 상품 배열은 한 곳에서 관리하고, 페이지별 데이터는 일관적으로 반영
// 예: 중복 요청을 막는 구조
let isRequesting = false;
const requestLoadMore = async () => {
if (isRequesting) return;
if (!pagination.hasNext) return;
isRequesting = true;
try {
const nextPage = pagination.page + 1;
const data = await getProducts({ ...filters, current: nextPage });
setProducts((prev) => [...prev, ...data.products]);
setPagination(data.pagination);
} catch (error) {
setError("추가 데이터를 불러오지 못했습니다.");
} finally {
isRequesting = false;
}
};또는 커스텀 훅으로 비동기 처리와 플래그 관리를 분리하는 방식을 추천합니다.
| cartStore.clear(); | ||
| if (hadItems) { | ||
| showToast({ type: "info", message: "장바구니를 비웠습니다." }); | ||
| } |
There was a problem hiding this comment.
3. 이벤트 위임 시 구체적 처리 함수 분리 미흡
구체적인 문제 상황:
모든 이벤트가 마운트 시점에 루트 노드에서 위임 방식으로 등록되어 있어서, 코드가 크고 하나의 함수 내에 여러 역할을 혼합하고 있습니다. 이로 인해 특정 이벤트 로직이 복잡해지고, 재사용 및 테스트가 어려워 집니다.
현재 코드의 한계:
- 이벤트 핸들러 함수가 여러 역할을 수행하면서 책임이 불명확
- 특정 이벤트 종류별 중복 검사 구문이 반복되고, 가독성이 떨어짐
- 이벤트 핸들러 단위 테스트가 어렵고 유지보수도 비효율적
3. 근본 원인
핵심 문제:
이벤트 핸들러 간 결합도가 높고, 핸들러가 대형 단일 함수 형태로 작성되어 있어 코드가 모듈화되지 않음.
왜 문제인가:
이 상태에서는 핸들러 추가, 수정, 오류 발생 시 영향 범위가 크고, 기능 하나만 수정하거나 추가하기 어려워진다.
3. 개선 구조
개선 사항:
- 이벤트 핸들러를 기능별로 분리하여 별도의 함수로 구성
- 각 핸들러는 이벤트 타입과 관련 DOM 조건을 명확히 구분
- 핸들러 등록하는 함수 내에서 핸들러를 묶어 관리해 단일 책임 원칙 준수
// 기능별 이벤트 핸들러 분리 예시
const onProductClick = (event) => {
const card = event.target.closest('.product-card');
if (card && !event.target.closest('.add-to-cart-btn')) {
navigate(`/product/${card.dataset.productId}`);
}
};
const onAddToCartClick = (event) => {
if (event.target.closest('.add-to-cart-btn')) {
// 장바구니 처리
}
};
// 마운트 시 이벤트 등록
root.addEventListener('click', (event) => {
onProductClick(event);
onAddToCartClick(event);
// 기타 이벤트 핸들러 호출
});이렇게 하면 이벤트별 책임이 분리되어 가독성 향상과 유지보수가 쉬워집니다.
| }; | ||
|
|
||
| const handleGoToProductListClick = (event) => { | ||
| // 상품 목록으로 돌아가기 |
There was a problem hiding this comment.
4. 런타임 상태 객체 사용에 따른 테스트 및 유지보수 복잡성
구체적인 문제 상황:
DetailPageComponent에 runtime이라는 전역 객체를 사용해 상태와 setter를 보관하고 있으며, 이를 통한 상태 동기화와 로직 구현이 다소 긴밀하게 연결되고 있습니다.
현재 코드의 한계:
- 상태와 setter가 모두 전역 객체에 저장되어 컴포넌트 복수 인스턴스 생성 시 문제 발생 위험
- 상태 변경 함수가 직접 runtime을 변경하며, 사이드 이펙트 관리가 어려움
- 상태 동기화 로직이 분산되어 디버깅과 테스트가 어려울 수 있음
4. 근본 원인
핵심 문제:
전역 상태 저장소에 의존하는 방식으로, 컴포넌트 로컬 상태 관리 원칙과 분리되어 있지 않음.
왜 문제인가:
컴포넌트 재사용이나 병렬 렌더링에 부적합하며, 향후 기능 추가 시 사이드 이펙트가 확산될 우려가 있음.
4. 개선 구조
개선 사항:
- 각 상태 항목과 setter는 useState 훅 내부에 선언해 캡슐화
- 이벤트 핸들러는 상태 업데이트 함수(setter)를 통해 일원화된 상태 관리를 수행
- sideEffect 관리용 useEffect 스타일 훅을 사용해 비동기 로직 및 상태 간 조율
export const DetailPageComponent = ({ params }) => {
const productId = params?.id;
const [state, setState] = useState({ loading: true, product: null, error: null });
const [quantity, setQuantity] = useState(1);
const [cart, setCart] = useState(cartStore.getState());
useEffect(() => {
// 비동기 제품 로드
fetchProduct(productId).then(product => setState({ loading: false, product, error: null }));
}, [productId]);
const onAddToCart = () => { ... };
return renderView(state, quantity, cart);
};이 방식은 각 상태가 컴포넌트에 묶이고, 테스트 및 유지보수가 쉬워집니다.
|
|
||
| const loadInitialData = async (query) => { | ||
| // ✅ 초기 렌더 또는 URL 변경 시 데이터를 다시 불러온다 | ||
| if (runtime.isInitializing) return; |
There was a problem hiding this comment.
5. 중복 상태와 비동기 사이드 이펙트 관리
구체적인 문제 상황:
runtime 객체와 컴포넌트 내부 useState 훅 상태가 혼재되어 관리되고 있으며, 이 두 상태를 동시에 변경하는 패턴이 복잡하게 얽혀 있습니다.
현재 코드의 한계:
- 상태 변경 시 반드시 두 곳(runtime 객체, 훅) 모두 업데이트해야 하므로 실수 위험 존재
- 상태 변화 타이밍과 연관 로직들이 분산되어 있어 사이드 이펙트 예측 어려움
- 상태 복원, URL 동기화, API 호출 로직이 컴포넌트 내와 runtime에 중복됨
5. 근본 원인
핵심 문제:
명확한 단일 상태 소스(single source of truth) 없이 여러 상태 저장소를 동시에 관리하며 동기화에 대한 관리 체계가 부재.
왜 문제인가:
추가 기능 확장 시 상태 불일치 문제, 복잡도 증가 그리고 버그 가능성이 커지기 때문.
5. 개선 구조
개선 사항:
- 상태는 useState 훅을 통해 단일 소스로 관리하고, runtime 객체는 제거하거나 훅 기반 상태로 대체
- 상태 변화 로직을 useEffect와 커스텀 훅으로 분리해 관리
- URL과 상태 동기화는 별도 useEffect로 관리하여 무한루프 방지 및 명확화
const [filters, setFilters] = useState(initialFilters);
useEffect(() => {
// filters 변경 시 URL 동기화
syncUrl(filters);
}, [filters]);
useEffect(() => {
// URL 변경 시 filters 업데이트
const urlFilters = parseUrlFilters();
if (urlFilters !== filters) setFilters(urlFilters);
}, [window.location.search]);이렇게 하면 상태 관리가 일관되고 리액티브하게 진행됩니다.
| const target = event.target; | ||
| if (!(target instanceof Element)) return; | ||
| if (!target.closest(".cart-modal")) return; | ||
| if (!target.matches("input[type='checkbox']")) return; |
There was a problem hiding this comment.
6. 로딩 및 에러 상태 UI 미흡
구체적인 문제 상황:
에러 발생 시 메시지 출력이 template literal 내 정적인 위치에 고정되어 있고, 로딩과 에러 처리 UI가 깔끔하게 모듈화되어 있지 않습니다.
현재 코드의 한계:
- 에러 UI가 단순 문자열로 표시되며 재시도 버튼이 UI에 없음
- 로딩 상태 스켈레톤 UI가 ProductList 컴포넌트 내에서만 처리되어 일관성 부족
- 에러 발생 시 사용자 조작으로 재시도를 유도하는 UX 부재
6. 근본 원인
핵심 문제:
로딩과 에러 처리 UI가 컴포넌트에서 분리되어 있지 않아 재사용과 유지보수가 어렵고, 사용자 친화적 피드백이 미흡함.
왜 문제인가:
올바른 사용자 경험 제공이 어렵고, 에러 핸들링과 재시도 로직이 혼재됨.
6. 개선 구조
개선 사항:
- 별도의 Loading, Error 컴포넌트 제작 및 위치 분리
- Error 컴포넌트 내 재시도 버튼 및 콜백 구현
- 에러 상태 및 로딩 상태를 명확히 state로 관리하고 일관되게 렌더링 처리
const ErrorDisplay = ({ message, onRetry }) => `
<div class="error-message">
<p>${message}</p>
<button onClick="${onRetry}">재시도</button>
</div>
`;
const HomePageComponent = () => {
const [error, setError] = useState(null);
const [isLoading, setIsLoading] = useState(false);
const loadData = async () => {
setIsLoading(true);
try {
// 데이터 로드
setError(null);
} catch (err) {
setError("데이터를 불러오는 중 오류가 발생했습니다.");
} finally {
setIsLoading(false);
}
};
return `
${isLoading ? Loading() : error ? ErrorDisplay({ message: error, onRetry: loadData }) : ProductList({ products })}
`;
};이렇게 개선하면 로딩과 에러 처리의 책임과 UI 표현이 명확해집니다.
|
|
||
| let hasChanged = false; | ||
| runtime.setSelectProductList?.((prev) => { | ||
| const baseList = Array.isArray(prev) ? prev : []; |
There was a problem hiding this comment.
7. 이벤트 핸들러 내 직접 DOM 조회 및 조작
구체적인 문제 상황:
DetailPage 내 여러 이벤트 핸들러에서 querySelector, closest 등으로 직접 DOM을 탐색하며 수동으로 값을 읽거나 수정하고 있습니다.
현재 코드의 한계:
- 직접 DOM 접근이 많아 뷰 상태와 JavaScript 상태 간 불일치 가능성 존재
- DOM 이벤트를 복잡하게 처리하는 부분이 누적되면서 가독성과 유지보수성 저하
7. 근본 원인
핵심 문제:
상태 기반 렌더링 방식을 완전하게 활용하지 않고 DOM 수동 조작에 의존하고 있음.
왜 문제인가:
컴포넌트 상태와 UI 간 일관성 유지가 어려워지고, 버그 발생 시 디버깅이 복잡해집니다.
7. 개선 구조
개선 사항:
- 이벤트 핸들러는 상태 업데이트에만 집중하고, 화면 렌더링은 상태를 기반으로 수행
- 입력 값은 controlled input 형태에 가깝게 상태와 연결
- 가능한 상태로부터 UI를 재생성하여 상태 동기화 이슈 최소화
const handleQuantityChange = (newQty) => {
setQuantity(prev => Math.max(1, newQty));
};
// input은 항상 상태값 기반으로 렌더링
<input id="quantity-input" value={quantity} onInput={(e) => handleQuantityChange(+e.target.value)} />| prevItem.quantity !== currentItem.quantity || | ||
| Boolean(prevItem.checked) !== Boolean(currentItem.checked) | ||
| ) { | ||
| isShallowEqual = false; |
There was a problem hiding this comment.
8. 캐싱 로직 및 데이터 동기화 모호
구체적인 문제 상황:
카테고리 데이터는 로컬 변수(cachedCategories)에 캐싱 중이지만, 이 캐싱 데이터를 초기화하거나 갱신하는 로직이 분명하지 않아 데이터 불일치나 갱신 실패 위험이 있습니다.
현재 코드의 한계:
- 캐싱 데이터와 상태값 간 동기화 부족
- 에러 발생 시 캐시 초기화만 있고, 재시도 로직이 명확하지 않음
8. 근본 원인
핵심 문제:
캐시 상태가 컴포넌트 상태 분리 없이 로컬 파일 스코프 변수에 위치하여 관리 주체가 불명확함.
왜 문제인가:
이해관계가 혼재되어 캐싱 관련 버그 및 부적절한 데이터 렌더링을 초래할 수 있음.
8. 개선 구조
개선 사항:
- 카테고리 데이터는 전역 상태관리(store 또는 context) 내 관리
- 캐시 갱신 시 명시적 액션 트리거와 에러 핸들링 분리
- 혹은 커스텀 훅으로 캐싱과 상태 관리를 포함한 데이터 로딩 책임 위임
const useCategories = () => {
const [categories, setCategories] = useState(null);
useEffect(() => {
getCategories()
.then(setCategories)
.catch(() => setCategories(null));
}, []);
return categories;
};| return query; | ||
| }; | ||
|
|
||
| const updateCurrentPageInUrl = (page) => { |
There was a problem hiding this comment.
9. URL 동기화 로직 중복과 복잡도 증가
구체적인 문제 상황:
필터 및 페이징 상태 변경 시 URL을 update하는 코드가 여러 이벤트 핸들러와 상태 관리 함수에 산재해 있으며, 각기 조금씩 다른 패턴으로 처리되고 있습니다.
현재 코드의 한계:
- URL 상태 갱신 로직이 반복되고 수동으로 관리되어 코드 중복 발생
- 상태와 URL 간 양방향 계속 동기화 로직에서 무한루프 혹은 잘못된 상태 반영 우려
9. 근본 원인
핵심 문제:
상태-URL 동기화를 처리하는 단일 추상화 계층 부재
왜 문제인가:
상태 변경과 URL 변경 로직을 분리하지 않아 유지보수가 번거로우며, 기능 변경 시 오류 가능성 증가
9. 개선 구조
개선 사항:
- URL과 상태 관리 로직을 커스텀 훅이나 별도 유틸에 위임
- 상태 변경 시 URL sync는 독립적인 useEffect로 처리, URL 변경시 상태 업데이트도 마찬가지
- URL과 상태를 연결하는 단방향 데이터 흐름으로 설계
// urlUtils.js
export const syncUrlWithFilters = (filters, pagination) => {
const url = new URL(window.location.href);
// set or delete params based on filters
window.history.replaceState({}, '', url.toString());
};
// HomePageComponent 내부
useEffect(() => {
syncUrlWithFilters(filters, pagination);
}, [filters, pagination]);
useEffect(() => {
const newFilters = parseFiltersFromUrl(window.location.search);
if (!shallowEqual(newFilters, filters)) {
setFilters(newFilters);
}
}, [window.location.search]);이렇게 하면 URL 동기화가 명확하고 반복을 줄일 수 있습니다.
|
|
||
| if (searchKeyword) { | ||
| currentUrl.searchParams.set("search", searchKeyword); | ||
| } else { |
There was a problem hiding this comment.
10. 마운트/언마운트 처리 부재와 이벤트 누수 위험성
구체적인 문제 상황:
컴포넌트가 마운트되고 언마운트될 때 이벤트 리스너 등록과 해제를 명확히 관리하지 않으면 메모리 누수나 중복 이벤트 발생 위험이 있습니다.
현재 코드의 한계:
- mount 함수 내 이벤트 리스너 등록은 있지만 해제 로직이 누락되거나 불완전할 가능성 존재
- 이벤트 중복 등록이 되면 의도치 않은 부작용 발생 가능
10. 근본 원인
핵심 문제:
이벤트 생명주기 관리가 컴포넌트 생명주기와 연계되어 있지 않음
왜 문제인가:
리소스 관리 실패로 앱 성능 저하, 버그 확대, 디버깅 어려움을 유발함
10. 개선 구조
개선 사항:
- 컴포넌트 언마운트 시점에 이벤트 리스너와 옵저버를 꼭 제거하는 문법 적용
- 이벤트 핸들러 참조를 변수에 보관해 정확히 제거
const mountHomePage = () => {
const onClick = (event) => { ... };
root.addEventListener("click", onClick);
return () => {
root.removeEventListener("click", onClick);
};
};
// 렌더 함수 내에서 mount 호출과 함께 cleanup 함수 캐싱이렇게 하면 누수없이 깨끗한 이벤트 관리가 가능합니다.
3 participants
과제 체크포인트
배포 링크
https://jumoooo.github.io/front_7th_chapter2-1/
기본과제
상품목록
상품 목록 로딩
상품 목록 조회
한 페이지에 보여질 상품 수 선택
상품 정렬 기능
무한 스크롤 페이지네이션
상품을 장바구니에 담기
상품 검색
카테고리 선택
카테고리 네비게이션
현재 상품 수 표시
장바구니
장바구니 모달
장바구니 수량 조절
장바구니 삭제
장바구니 선택 삭제
장바구니 전체 선택
장바구니 비우기
상품 상세
상품 클릭시 상세 페이지 이동
/product/{productId}형태로 변경된다상품 상세 페이지 기능
상품 상세 - 장바구니 담기
관련 상품 기능
상품 상세 페이지 내 네비게이션
사용자 피드백 시스템
토스트 메시지
심화과제
SPA 네비게이션 및 URL 관리
페이지 이동
상품 목록 - URL 쿼리 반영
상품 목록 - 새로고침 시 상태 유지
장바구니 - 새로고침 시 데이터 유지
상품 상세 - URL에 ID 반영
/product/{productId})상품 상세 - 새로고침시 유지
404 페이지
AI로 한 번 더 구현하기
과제 셀프회고
기술적 성장
이번 과제를 통해 React의 동작 원리를 바닐라 JavaScript로 직접 구현해보며,
프레임워크가 내부적으로 어떻게 상태를 관리하고 렌더링을 제어하는지를 깊이 이해할 수 있었습니다.
특히
useState, 렌더링 스케줄링, 그리고 라우팅 구조를 직접 설계하면서 단순히 React를 사용하는 수준이 아니라“React가 왜 이렇게 설계되었는지”를 체감할 수 있었습니다.
React 공식 문서에서 강조하는 핵심 개념인 “상태에 따라 UI를 선언적으로 관리한다”는 부분을 직접 코드로 구현하면서,
**렌더링 최적화와 비동기 렌더링(batch update)**의 중요성을 배웠습니다.
그리고 React의 Hooks 구조를 모방하기 위해 렌더 순서를 보장하는 인덱스 관리 로직과
전역 currentComponent 컨텍스트를 구현하면서 컴포넌트 단위의 독립적인 상태 관리가 왜 필요한지를 이해하게 되었습니다.
자랑하고 싶은 코드
React의 렌더링 구조를 모방해본 부분입니다.
개선이 필요하다고 생각하는 코드
라우터 구현 부분에서는 여전히 개선할 곳이 많습니다.
현재는 Router에서 페이지를 렌더링할 때 HTML 문자열을 직접 반환하는 방식이라,
Hook이 작동할 수 있는 렌더 트리 구조가 존재하지 않습니다.
React처럼 컴포넌트 단위로 렌더링 트리를 구성하고,
각 컴포넌트마다 Hook 컨텍스트를 독립적으로 유지할 수 있는 구조로 리팩토링이 필요하다고 생각합니다.
이벤트 등록을 메인 스크립트에서 한꺼번에 처리하고 있어서, 페이지 단위의 이벤트 관리가 어려운 점도 개선해야 합니다.
학습 효과 분석
React의 렌더링이 동기적으로 즉시 실행되지 않고,
Promise 기반의 비동기 스케줄링을 통해 여러 상태 업데이트를 한 번에 처리(batch) 한다는 점이 실무 성능에 큰 의미가 있음을 알게 되었습니다.
과제 피드백
제가 부족하여 없습니다...
AI 활용 경험 공유하기
React를 만든다는 것이 너무 막연하게 느껴졌기 때문에,
AI(ChatGPT)의 도움을 받아 학습 순서와 구현 계획을 세웠습니다.
처음에는 어디서부터 시작해야 할지 감이 없었지만,
AI의 안내를 통해 React의 핵심 요소를 다음과 같은 순서로 접근했습니다.
이 과정을 통해 막연한 구현 목표를 구체적인 개발 계획으로 바꾸는 법을 배울 수 있었습니다.
또한, AI가 제공한 React 공식 문서 기반의 설명을 참고하여
React의 동작 원리와 제약 조건을 보다 정확히 이해할 수 있었습니다.
이후에는 코드 작성에 어려움이 있을 때마다 작성의 도움을 받을수 있었고, 주석 등 반복적인 것들은 AI 에게 따로 작업을 시켰습니다.
리뷰 받고 싶은 내용