diff --git a/.cursor/mockdowns/react-implementation/00_implementation-history.md b/.cursor/mockdowns/react-implementation/00_implementation-history.md new file mode 100644 index 00000000..85e081bc --- /dev/null +++ b/.cursor/mockdowns/react-implementation/00_implementation-history.md @@ -0,0 +1,611 @@ +# React Implementation 전체 작업 이력 + +> **목적**: Mini-React 구현 과정의 전체 이력을 시간 순서대로 정리한 문서입니다. +> **대상**: 추후 동일한 기능을 다시 구현하거나 문제를 해결할 때 참고할 수 있도록 작성되었습니다. + +--- + +## 📋 목차 + +1. [1단계: 초기 핵심 기능 구현](#1단계-초기-핵심-기능-구현) +2. [2단계: Memo HOC 구현 및 디버깅](#2단계-memo-hoc-구현-및-디버깅) +3. [3단계: 이벤트 시스템 구현 및 문제 해결](#3단계-이벤트-시스템-구현-및-문제-해결) +4. [4단계: DOM 순서 문제 해결](#4단계-dom-순서-문제-해결) +5. [5단계: 무한 스크롤 문제 해결](#5단계-무한-스크롤-문제-해결) +6. [6단계: GitHub Pages 배포 설정](#6단계-github-pages-배포-설정) + +--- + +## 1단계: 초기 핵심 기능 구현 + +### 1.1 Reconciliation 문제 분석 및 해결 + +**문서**: `01-reconciliation-issue-analysis.md` + +#### 문제 상황 +- 테스트 실패: 중첩된 컴포넌트에서 `useState`가 각각 독립적으로 동작하지 않음 +- `item-3`이 `Footer`의 상태(101)를 가지고 있음 (기대값: 0) + +#### 근본 원인 +- Footer가 인덱스 변경으로 이동할 때 기존 path(`root.0.3`)를 유지해야 하지만, `reconcileChildren`에서 새 path를 생성함 +- Footer의 훅 상태는 기존 path에 남아있고, Item3이 같은 path를 사용하면 Footer의 상태를 가져옴 + +#### 해결 방법 +- `reconcileChildren`에서 타입이 다를 때 path 충돌 방지 로직 추가 +- `reconcile`에서 타입이 다를 때 기존 path의 훅 상태 정리 + +#### 수정 파일 +- `packages/react/src/core/reconciler.ts` + +--- + +### 1.2 useState 구현 상세 + +**문서**: `02-useState-implementation-details.md` + +#### 핵심 구조 +- **Path 기반 상태 격리**: 각 컴포넌트의 고유 경로(path)를 키로 사용하여 훅 상태를 격리 +- **커서(Cursor) 시스템**: 컴포넌트 내에서 훅의 호출 순서를 추적 +- **상태 업데이트 플로우**: `setState` → 상태 변경 → `enqueueRender` → 비동기 렌더링 + +#### 주요 데이터 구조 +```typescript +interface HooksContext { + state: Map; // path별 훅 상태 배열 + cursor: Map; // path별 훅 커서 + visited: Set; // 현재 렌더링에서 방문한 path + componentStack: string[]; // 컴포넌트 스택 +} +``` + +#### Path 생성 규칙 +- 루트: `"root"` +- 자식: `${parentPath}.${key ?? index}` +- 예시: `"root.0.1"`, `"root.0.1.0"` + +#### 상태 업데이트 플로우 +1. `useState` 호출 → 현재 path와 cursor로 훅 상태 조회/생성 +2. `setState` 호출 → 상태 변경 감지 → `enqueueRender` 호출 +3. `render` 실행 → `reconcile` → 컴포넌트 재렌더링 +4. `cleanupUnusedHooks` → 사용되지 않은 훅 정리 + +--- + +### 1.3 useEffect 구현 + +**문서**: `03-useEffect-implementation-plan.md` + +#### 구현 목표 +- 렌더 이후 비동기로 실행 +- 의존성이 변경될 때만 실행 +- 클린업 함수 지원 (재실행 시, 언마운트 시) + +#### 핵심 로직 +1. **의존성 비교**: `shallowEquals`로 이전 deps와 현재 deps 비교 +2. **이전 클린업 실행**: 의존성 변경 시 이전 클린업 함수 먼저 실행 +3. **이펙트 큐에 추가**: `context.effects.queue`에 `{ path, cursor }` 추가 +4. **비동기 실행**: `render` 완료 후 `flushEffects`로 실행 + +#### 구현 파일 +- `packages/react/src/core/hooks.ts`: `useEffect` 함수 +- `packages/react/src/core/hooks.ts`: `flushEffects` 함수 +- `packages/react/src/core/render.ts`: `flushEffects` 호출 추가 + +#### 완료 상태 +✅ 모든 테스트 통과 (3/3) + +--- + +### 1.4 Fragment 업데이트 처리 + +**문서**: `04-fragment-update-fix.md` + +#### 문제 상황 +- Fragment의 조건부 자식이 업데이트될 때 제대로 처리되지 않음 +- `#dynamic` 요소가 렌더링되지 않음 + +#### 원인 +- `reconcile` 함수에서 Fragment 타입의 업데이트 처리가 누락됨 + +#### 해결 방법 +- Fragment 업데이트 로직 추가 +- Fragment는 자체 DOM이 없으므로, 자식들을 재조정할 때 부모 DOM을 사용 +- `normalizeChildren`로 자식 VNode 배열 정규화 +- `reconcileChildren`으로 자식 인스턴스 재조정 + +#### 수정 파일 +- `packages/react/src/core/reconciler.ts` + +--- + +### 1.5 Key 기반 DOM 재배치 + +**문서**: `05-key-based-dom-reordering.md` + +#### 문제 상황 +- key가 있는 자식을 재배치할 때 기존 DOM이 재사용되지만 순서가 변경되지 않음 +- 기대: `[B, C, A]` 순서 +- 실제: `[A, B, C]` 순서 (변경되지 않음) + +#### 원인 +- key 기반 매칭은 올바르게 작동하지만, DOM 순서 재배치 로직이 누락됨 + +#### 해결 방법 +- DOM 순서 재배치 로직 추가 +- **역순 순회**: 마지막 인스턴스부터 첫 번째까지 역순으로 순회 +- **Anchor 사용**: 다음 인스턴스(i + 1)의 첫 DOM 노드를 anchor로 사용 +- **위치 확인 및 재배치**: 현재 DOM이 올바른 위치에 있는지 확인하고, 다르면 재배치 + +#### 핵심 로직 +```typescript +// 역순으로 순회하여 올바른 위치에 DOM 배치 +for (let i = newInstances.length - 1; i >= 0; i--) { + const currentFirstDom = getFirstDomFromChildren([instance]); + const nextFirstDom = nextInstance ? getFirstDomFromChildren([nextInstance]) : null; + + if (nextFirstDom) { + // anchor 앞에 있어야 함 + if (currentFirstDom.nextSibling !== nextFirstDom) { + // DOM 재배치 + domNodes.forEach((node) => { + parentDom.insertBefore(node, nextFirstDom); + }); + } + } +} +``` + +#### 수정 파일 +- `packages/react/src/core/reconciler.ts` + +--- + +### 1.6 추가 Hooks 구현 + +**문서**: `06-hooks-impl.md` + +#### 구현된 Hooks +1. **useRef**: `useState` lazy initializer로 한 번만 생성 +2. **useMemo**: 이전 deps/value를 `useRef`로 저장하여 의존성 변경 시에만 factory 재실행 +3. **useCallback**: `useMemo`를 활용해 콜백 참조 메모이제이션 +4. **useDeepMemo**: `deepEquals`를 이용해 깊은 비교 후 메모 제공 +5. **useAutoCallback**: `useRef` + `useCallback`으로 안정된 참조에서 최신 함수 호출 + +#### 테스트 상태 +- ✅ `useRef` 테스트 통과 +- ✅ `useMemo` 테스트 통과 +- ✅ `useCallback` 테스트 통과 +- ✅ `useDeepMemo` 테스트 통과 +- ⚠️ `useAutoCallback` 테스트는 실행 단계에서 거부됨 (IDE에서 직접 실행 권장) + +--- + +## 2단계: Memo HOC 구현 및 디버깅 + +### 2.1 memo HOC 구현 + +**문서**: `07-memo-hoc-implementation.md` + +#### 구현 목표 +- 컴포넌트의 props가 변경되지 않았을 경우, 마지막 렌더링 결과를 재사용하여 리렌더링 방지 + +#### 핵심 로직 +```typescript +const MemoizedComponent: FunctionComponent

= (props) => { + const memoRef = useRef({ + prevProps: null, + prevResult: null, + }); + + // 이전 props와 현재 props 비교 + if (memoRef.current.prevProps !== null && equals(memoRef.current.prevProps, props)) { + return memoRef.current.prevResult; // 이전 결과 재사용 + } + + // props가 변경되었거나 첫 렌더링인 경우 컴포넌트 실행 + const result = Component(props); + memoRef.current = { prevProps: props, prevResult: result }; + return result; +}; +``` + +#### 구현 파일 +- `packages/react/src/hocs/memo.ts` + +--- + +### 2.2 memo 리렌더링 문제 디버깅 + +**문서**: `08-memo-rerender-debug.md`, `09-memo-rerender-issue.md` + +#### 문제 상황 +- 동일한 props `{ value: 1 }`로 `setState`를 호출했을 때, `TestComponent`가 2번 호출됨 (예상: 1번) +- `expected "spy" to be called 1 times, but got 2 times` + +#### 원인 분석 과정 +1. **1차 가설**: `useRef` 초기화 문제 → 해결 시도했으나 문제 지속 +2. **2차 가설**: 훅의 `cursor`가 리렌더링 시 초기화되지 않음 → 틀림 (이미 0으로 리셋됨) +3. **최종 결론**: **경로(Path) 충돌** + +#### 근본 원인 +- 함수형 컴포넌트가 반환한 자식 VNode를 `reconcile` 할 때, **부모 컴포넌트의 경로를 그대로 전달** +- 부모와 자식이 동일한 `path`를 공유하게 되어 훅 상태가 충돌 +- `memo` HOC의 `useRef`가 상태를 잃어버림 + +--- + +### 2.3 함수형 컴포넌트 Path 수정 + +**문서**: `10_function-component-path-fix.md` + +#### 해결 방법 +- 함수형 컴포넌트의 자식이 부모와 독립된 고유한 경로를 갖도록 수정 +- `createChildPath`를 사용하여 자식의 고유 경로 생성 + +#### 수정 내용 + +**1. 컴포넌트 업데이트 로직 수정 (`reconcile` 함수)** +```typescript +// 수정 전 +const childInstance = reconcile(childParentDom, existingChildInstance || null, componentVNode, componentPath); + +// 수정 후 +const childPath = createChildPath(componentPath, componentVNode.key ?? null, 0); +const childInstance = reconcile(childParentDom, existingChildInstance || null, componentVNode, childPath); +``` + +**2. 컴포넌트 마운트 로직 수정 (`mountNode` 함수)** +```typescript +// 수정 전 +const childInstance = reconcile(parentDom, null, componentVNode, path); + +// 수정 후 +const childPath = createChildPath(path, componentVNode.key ?? null, 0); +const childInstance = reconcile(parentDom, null, componentVNode, childPath); +``` + +#### 수정 파일 +- `packages/react/src/core/reconciler.ts` + +#### 기대 효과 +- 모든 컴포넌트가 트리 구조에 따라 고유한 경로를 부여받음 +- 부모와 자식 간의 훅 상태 충돌 해결 +- `memo` HOC가 정상적으로 동작 + +--- + +## 3단계: 이벤트 시스템 구현 및 문제 해결 + +### 3.1 이벤트 핸들링 문제 초기 분석 + +**문서**: `11_event-handling-issue-analysis.md` + +#### 문제 상황 +- 애플리케이션 전체에서 `onClick`, `onKeyDown`, `onChange` 등 모든 DOM 이벤트 핸들러가 동작하지 않음 +- 브라우저 콘솔에 에러 메시지 없음 + +#### 원인 분석 +- **이벤트 위임(Event Delegation)** 패턴 사용 +- `addEventHandler`는 핸들러를 `elementEventStore`(WeakMap)에 저장 +- 각 이벤트 타입에 대한 단일 리스너가 `rootContainer`에 부착되어야 함 +- **문제**: `render` 함수에서 `setEventRoot`를 호출하는 코드가 누락됨 + +#### 해결 방법 +- `packages/react/src/core/render.ts`의 `render` 함수 상단에 `setEventRoot` 호출 추가 +- 중복 실행 방지를 위한 가드 추가 + +--- + +### 3.2 Reconciliation 로직 결함 분석 + +**문서**: `12_reconciliation-logic-flaw-analysis.md` + +#### 문제 상황 +- 이벤트 핸들러 등록 문제 해결 후에도 검색창 입력 오류, 무한 스크롤 미작동, 카트 버튼 클릭 시 모달창이 뜨지 않음 + +#### 원인 분석 +- 함수형 컴포넌트 재조정 로직에 결함 +- 함수형 컴포넌트를 먼저 실행하여 새로운 자식 VNode를 얻고, 이 VNode를 이전 인스턴스와 재조정하려고 시도 +- **문제**: 부모가 리렌더링되어도 자식 컴포넌트의 함수 자체를 다시 실행하는 과정을 건너뛰게 만듦 + +#### 해결 방법 +- `reconcile` 함수 내 함수형 컴포넌트 분기 로직 수정 +- 타입이 같다면, 이전 자식 인스턴스와 컴포넌트를 새롭게 렌더링한 결과를 재귀적으로 `reconcile` + +--- + +### 3.3 이벤트 시스템 & 재조정 로그 분석 + +**문서**: `13_event-and-reconcile-log-analysis.md` + +#### 로그로 확인한 사실 +1. **함수형 컴포넌트가 매번 새로 마운트됨** + - 동일한 함수형 컴포넌트 경로가 첫 렌더 이후에도 계속 `decision: mount`로 남아있음 + - 부모가 상태를 갱신해도 자식 함수형 컴포넌트가 업데이트 단계로 진입하지 못함 + +2. **parentDom이 비어 있는 상태** + - 동일한 DOM 컨테이너에 다시 렌더링할 때 `parentDom`이 비어 있음 + - 함수형 컴포넌트가 기존 자식 DOM을 모두 치운 뒤 새 자식을 삽입하려고 했지만, 부모 DOM을 잃어버림 + +#### 근본 원인 +1. **이벤트 시스템 초기화 누락**: `setEventRoot`가 호출되지 않아 `rootContainer`가 `null` +2. **함수형 컴포넌트 재조정 순서 오류**: 부모 DOM을 인자로 전달하지 못하면 자식 인스턴스를 다시 DOM에 삽입할 위치를 잃어버림 + +#### 해결 방안 +1. `setEventRoot` 보장 호출 +2. 함수형 컴포넌트 재조정 순서 수정 +3. 디버깅 가드 추가 + +--- + +### 3.4 React 스타일 이벤트 시스템 전환 + +**문서**: `14_event-system-debugging-plan.md` + +#### 목표 +- React DOM과 동일한 철학/흐름으로 재구성 +- 추후 `react-dom`으로 교체해도 사용자 코드 변경 없이 동작하도록 준비 + +#### React DOM의 핵심 원칙 +1. **createRoot 시점 단일 등록**: `createRoot`가 호출되면 해당 컨테이너를 이벤트 시스템에 등록 +2. **이벤트 타입 전역 레지스트리**: 이벤트 타입이 처음 필요할 때만 네이티브 리스너를 붙이고, 이후에는 재사용 +3. **Synthetic Event 디스패치 파이프라인**: 네이티브 이벤트 → Synthetic Event로 래핑 → 핸들러 실행 + +#### 전환 계획 +1. **루트 라이프사이클 재정의**: `createRoot`에서 `setEventRoot` 호출 책임 이동 +2. **전역 이벤트 레지스트리 도입**: `registeredEvents`, `rootListeners` 도입 +3. **listenToNativeEvent 유틸 구현**: 이벤트 타입별 capture/bubble 핸들러 생성 +4. **Synthetic Event 스텁 추가**: 네이티브 이벤트를 래핑하여 추후 React DOM drop-in 시 호환성 확보 + +#### 구현 완료 상태 +- ✅ 이벤트 루트 설정 책임 이관 +- ✅ 전역 이벤트 레지스트리 도입 +- ✅ Synthetic Event 구현 +- ✅ JSDOM 호환성 수정 + +--- + +### 3.5 JSDOM 호환성 수정 + +**문서**: `15_event-system-jsdom-fix.md` + +#### 문제 상황 +- 단위 테스트 오류: `'get target' called on an object that is not a valid instance of Event.`, `Illegal invocation` +- 개발 서버 오류: 카테고리 클릭 시 `Illegal invocation` 오류 + +#### 원인 +- `Object.create(nativeEvent)`로 만든 객체가 JSDOM에서 유효한 Event 인스턴스로 인식되지 않음 +- `handler.call(current, syntheticEvent)`에서 발생 + +#### 해결 방법 +1. **네이티브 이벤트 직접 사용**: `Object.create` 대신 네이티브 이벤트를 직접 사용 +2. **Handler 호출 방식 변경**: `handler.call` → `handler` 직접 호출 +3. **currentTarget 처리**: 이벤트 위임 환경에서는 네이티브 이벤트의 `currentTarget` 사용 + +--- + +### 3.6 부분 이벤트 핸들링 문제 + +**문서**: `16_partial-event-handling-issue.md` + +#### 문제 상황 +- **작동하는 이벤트**: `onClick` (장바구니 담기, product 카드 클릭), `handleMainCategoryClick` +- **작동하지 않는 이벤트**: `onKeyDown`, `onChange`, `handleBreadCrumbClick`, `handleSubCategoryClick`, 카트 버튼 클릭 + +#### 원인 분석 +1. **이벤트 버블링 처리 로직 문제**: `listenToNativeEvent`에서 이벤트 버블링 여부를 확인하는 로직이 잘못됨 +2. **이벤트 타입별 버블링 특성**: `click`, `keydown`은 버블링함, `change`는 버블링하지 않음 +3. **텍스트 노드 처리 문제**: `e.target`이 텍스트 노드인 경우 `getAttribute` 호출 시 오류 발생 + +#### 해결 방법 +1. 이벤트 버블링 처리 로직 수정 +2. 텍스트 노드 처리: `TEXT_NODE`인 경우 `parentNode`로 이동 +3. `dispatchEvent`에서 `event.bubbles`와 `event.eventPhase` 확인하여 올바른 단계에서 처리 + +--- + +### 3.7 이벤트 핸들러 등록 문제 + +**문서**: `19_event-handler-registration-issue.md` + +#### 문제 상황 +- 로그 분석 결과: 모든 요소에서 `hasHandlers: false` +- `handlerKeys: Array(0)` - 빈 배열 +- `[DOM] updateDomProps: registering event handler` 로그 없음 + +#### 원인 +- `updateDomProps`에서 이벤트 핸들러를 등록하기 전에 `Object.is(prevValue, nextValue)` 체크를 먼저 수행 +- 함수 참조가 같으면 이벤트 핸들러 등록 로직을 건너뜀 + +#### 해결 방법 +- 이벤트 핸들러 처리 로직을 `Object.is` 체크 **이전**으로 이동 +- 이벤트 핸들러는 항상 재등록하도록 수정 + +--- + +### 3.8 이벤트 디버깅 가이드 + +**문서**: `17_event-debugging-guide.md`, `18_event-debugging-step-by-step.md` + +#### 디버깅 방법 +1. **브라우저 콘솔에서 디버깅 모드 활성화** + ```javascript + window.__REACT_DEBUG_EVENTS__ = true; + localStorage.setItem("__REACT_DEBUG_EVENTS__", "true"); // 새로고침 후에도 유지 + ``` + +2. **확인할 로그들** + - `[EventSystem] setEventRoot called` + - `[EventSystem] addEventHandler called` + - `[EventSystem] dispatchEvent called` + - `[EventSystem] Looking for handler` + - `[DOM] setDomProps called` + - `[DOM] updateDomProps: registering event handler` + +3. **체크리스트** + - `createRoot`가 호출되었는가? + - `setEventRoot`가 호출되었는가? + - `rootContainer`가 올바르게 설정되었는가? + - 이벤트 핸들러가 `addEventHandler`를 통해 등록되었는가? + - `registerEvent`가 호출되어 이벤트 타입이 등록되었는가? + - 네이티브 이벤트 발생 시 `dispatchEvent`가 호출되는가? + - 핸들러가 실제로 실행되는가? + +--- + +### 3.9 클릭 이벤트 문제 분석 + +**문서**: `09-click-event-issue-analysis.md` + +#### 문제 상황 +- HomePage에서 ProductItem을 클릭하는 것 외에 다른 클릭 이벤트가 작동하지 않음 + +#### 발견된 문제점 +1. **`setDomProps`에서 이벤트 리스너 중복 등록**: 이전 리스너를 제거하지 않고 계속 추가만 함 +2. **이벤트 위임 시스템 미사용**: `addEventListener`를 직접 호출하는 대신 `addEventHandler`를 사용해야 함 + +#### 해결 방법 +- `setDomProps`에서 `addEventListener` 직접 호출 제거 +- `addEventHandler`를 사용하여 이벤트 위임 시스템에 등록 + +--- + +## 4단계: DOM 순서 문제 해결 + +### 4.1 DOM 순서 문제 원인 분석 + +**문서**: `dom-order-issue-analysis.md`, `footer-order-issue-analysis.md` + +#### 문제 상황 +- `PageWrapper`의 `

` 내부에서 `header`, `main`, `Footer` 순서로 작성했지만 +- 실제 화면에서는 `Footer`, `header`, `main` 순서로 표시됨 +- `Footer`를 `Toast` 아래로 옮기면 `Footer`가 맨 위로 올라가는 오류 발생 + +#### 원인 분석 +- `reconcileChildren`에서 각 자식을 순차적으로 DOM에 삽입하지만, 재배치 로직이 올바르게 작동하지 않음 +- 재배치 로직에서 `nextSibling` 비교가 정확하지 않음 + +#### 해결 방법 +- 재배치 로직 개선 +- DOM 위치 확인 로직 정확화 +- 역순 순회를 사용하여 효율적으로 재배치 + +--- + +## 5단계: 무한 스크롤 문제 해결 + +### 5.1 무한 스크롤 문제 분석 + +**문서**: `20_infinite-scroll-issue-analysis.md`, `21_infinite-scroll-react-issue-analysis.md` + +#### 문제 상황 +- 무한 스크롤 기능이 작동하지 않음 +- 스크롤을 내려도 추가 상품이 로드되지 않음 + +#### 원인 분석 (App 쪽) +1. **함수 참조 불일치**: `removeEventListener`에서 다른 함수 참조를 제거하려고 시도 +2. **전역 변수 사용**: `scrollHandlerRegistered`가 전역 변수로 관리되어 컴포넌트 리렌더링 시 문제 발생 +3. **useEffect 의존성 배열**: 빈 배열 `[]`로 인해 최신 상태를 캡처하지 못함 + +#### 원인 분석 (React 쪽) +1. **cleanupUnusedHooks의 실행 타이밍**: `cleanupUnusedHooks`가 `reconcile` 이후에 실행되며, `visited` Set이 먼저 초기화됨 +2. **useEffect cleanup 실행 조건**: 의존성이 변경되지 않았는데도 cleanup이 실행됨 + +#### 해결 방법 +1. **useEffect cleanup 로직 수정**: cleanup은 `shouldRunEffect`가 `true`일 때만 실행되도록 수정 +2. **스크롤 핸들러 관리 개선**: `scrollHandler`를 외부 변수로 관리하여 cleanup에서 제거 가능하도록 수정 + +#### 수정 파일 +- `packages/react/src/core/hooks.ts`: `useEffect` cleanup 로직 수정 +- `packages/app/src/pages/HomePage.jsx`: 스크롤 핸들러 관리 개선 + +--- + +## 6단계: GitHub Pages 배포 설정 + +### 6.1 GitHub Pages 자동 배포 계획 + +**문서**: `22_github-pages-deployment-plan.md` + +#### 목표 +- GitHub Pages에 자동 배포를 설정하여 `main` 브랜치에 푸시될 때마다 자동으로 배포 + +#### 배포 링크 +- `https://jumoooo.github.io/front_7th_chapter2-2/` + +#### 현재 상태 +- ✅ Base path 설정 완료 (`/front_7th_chapter2-2/`) +- ✅ 빌드 스크립트 존재 +- ✅ 404 페이지 처리 +- ❌ GitHub Actions 워크플로우 없음 + +#### 구현 내용 +1. **GitHub Actions 워크플로우 생성**: `.github/workflows/deploy.yml` +2. **워크플로우 단계**: + - 체크아웃 + - Node.js 및 pnpm 설정 + - 의존성 설치 + - 단위 테스트 실행 + - E2E 테스트 실행 + - 빌드 + - GitHub Pages 배포 + +#### 사용자가 해야 할 작업 +1. GitHub 저장소 설정 확인 +2. GitHub Pages 설정 (Settings > Pages) +3. GitHub Actions 권한 설정 (Settings > Actions > General) + +--- + +## 📊 통합 요약 + +### 주요 해결된 문제들 + +1. **Reconciliation 문제** + - Path 충돌 방지 + - 타입 변경 시 훅 상태 정리 + +2. **함수형 컴포넌트 Path 문제** + - 부모와 자식이 동일한 path를 공유하던 문제 해결 + - `createChildPath`를 사용하여 고유 경로 생성 + +3. **이벤트 시스템 문제** + - 이벤트 루트 설정 누락 해결 + - React DOM 스타일로 전환 + - JSDOM 호환성 수정 + - 이벤트 핸들러 등록 문제 해결 + +4. **useEffect cleanup 문제** + - 의존성 변경 시에만 cleanup 실행하도록 수정 + +5. **무한 스크롤 문제** + - useEffect cleanup 로직 수정 + - 스크롤 핸들러 관리 개선 + +### 핵심 아키텍처 + +1. **Path 기반 상태 격리**: 각 컴포넌트의 고유 경로로 훅 상태 격리 +2. **이벤트 위임**: 루트 컨테이너에 단일 리스너 부착 +3. **Synthetic Event**: 네이티브 이벤트를 래핑하여 React DOM 호환성 확보 +4. **비동기 이펙트 실행**: 렌더링 후 마이크로태스크 큐에서 이펙트 실행 + +--- + +## 🔗 관련 문서 + +- **초기 구현**: `01-reconciliation-issue-analysis.md` ~ `06-hooks-impl.md` +- **Memo HOC**: `07-memo-hoc-implementation.md` ~ `10_function-component-path-fix.md` +- **이벤트 시스템**: `11_event-handling-issue-analysis.md` ~ `19_event-handler-registration-issue.md` +- **DOM 순서**: `dom-order-issue-analysis.md`, `footer-order-issue-analysis.md` +- **무한 스크롤**: `20_infinite-scroll-issue-analysis.md`, `21_infinite-scroll-react-issue-analysis.md` +- **배포**: `22_github-pages-deployment-plan.md` +- **기타**: `gemini-analysis-verification.md`, `09-click-event-issue-analysis.md` + +--- + +## 📌 참고 사항 + +- 모든 구현은 **React DOM으로 교체 가능**하도록 설계됨 (규칙 17) +- 테스트 코드는 수정하지 않음 (`e2e/e2e.spec.js`, `packages/react/src/__tests__/`) +- 기존 기능은 모두 유지되어야 함 + diff --git a/.cursor/mockdowns/react-implementation/01-reconciliation-issue-analysis.md b/.cursor/mockdowns/react-implementation/01-reconciliation-issue-analysis.md new file mode 100644 index 00000000..4353d042 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/01-reconciliation-issue-analysis.md @@ -0,0 +1,46 @@ +# Reconciliation 문제 분석 및 해결 계획 (최종 업데이트 3) + +## 문제 상황 + +### 테스트 실패 + +- **테스트**: `중첩된 컴포넌트에서 useState가 각각 독립적으로 동작한다` (763-860 라인) +- **실패 지점**: item-3이 Footer의 상태(101)를 가지고 있음 +- **기대값**: item-3은 새로 생성된 Item이므로 0이어야 함 + +## 근본 원인 (재분석) + +### 핵심 문제 + +Footer가 인덱스 변경으로 이동할 때: + +1. Footer는 기존 path(`root.0.3`)를 유지해야 함 (같은 컴포넌트이므로) +2. 하지만 `reconcileChildren`에서 새 path(`root.0.2`, `root.0.4`)를 생성함 +3. Footer의 훅 상태는 기존 path(`root.0.3`)에 남아있음 +4. Item3이 `root.0.3` path를 사용하면 Footer의 훅 상태를 가져옴 + +### 해결 방안 + +타입이 다를 때 새 path가 기존 인스턴스의 path와 같지 않도록 보장해야 합니다. + +- `reconcileChildren`에서 타입이 다를 때 path 충돌 방지 로직 추가 (완료) +- `reconcile`에서 타입이 다를 때 기존 path의 훅 상태 정리 (완료) + +## 수정 사항 + +### 완료된 수정 + +1. ✅ `reconcileChildren`에서 타입이 다른 인스턴스는 null로 전달 +2. ✅ 타입 매칭 로직 개선 +3. ✅ 타입이 다를 때 path 충돌 방지 로직 추가 +4. ✅ `reconcile`에서 타입이 다를 때 기존 path의 훅 상태 정리 + +### 현재 상태 + +- 여전히 Item3이 Footer의 상태를 가져오는 문제 발생 +- 타입이 다를 때 path 충돌 방지 로직이 제대로 작동하지 않을 수 있음 + +## 다음 단계 + +1. 타입이 다를 때 path 충돌 방지 로직이 제대로 작동하는지 확인 +2. 모든 oldChildren의 path를 확인하여 충돌 방지 diff --git a/.cursor/mockdowns/react-implementation/02-useState-implementation-details.md b/.cursor/mockdowns/react-implementation/02-useState-implementation-details.md new file mode 100644 index 00000000..c27997bf --- /dev/null +++ b/.cursor/mockdowns/react-implementation/02-useState-implementation-details.md @@ -0,0 +1,904 @@ +# useState 구현 상세 문서 + +## 📋 목차 + +1. [전체 구조 개요](#전체-구조-개요) +2. [핵심 데이터 구조](#핵심-데이터-구조) +3. [useState 구현 상세](#usestate-구현-상세) +4. [Path 기반 상태 격리 시스템](#path-기반-상태-격리-시스템) +5. [컴포넌트 라이프사이클과 useState](#컴포넌트-라이프사이클과-usestate) +6. [Reconciliation과 useState 연동](#reconciliation과-usestate-연동) +7. [상태 업데이트 플로우](#상태-업데이트-플로우) +8. [주요 문제 해결 사항](#주요-문제-해결-사항) + +--- + +## 전체 구조 개요 + +### 아키텍처 다이어그램 + +``` +┌─────────────────────────────────────────────────────────────┐ +│ Mini-React 시스템 │ +├─────────────────────────────────────────────────────────────┤ +│ │ +│ ┌──────────────┐ ┌──────────────┐ │ +│ │ Context │ │ useState │ │ +│ │ (전역 상태) │◄─────┤ (훅) │ │ +│ └──────────────┘ └──────────────┘ │ +│ │ │ │ +│ │ │ │ +│ ▼ ▼ │ +│ ┌──────────────────────────────────────┐ │ +│ │ HooksContext │ │ +│ │ - state: Map │ │ +│ │ - cursor: Map │ │ +│ │ - visited: Set │ │ +│ │ - componentStack: string[] │ │ +│ └──────────────────────────────────────┘ │ +│ │ │ +│ │ │ +│ ▼ │ +│ ┌──────────────────────────────────────┐ │ +│ │ Reconciliation │ │ +│ │ - reconcile() │ │ +│ │ - reconcileChildren() │ │ +│ │ - renderFunctionComponent() │ │ +│ └──────────────────────────────────────┘ │ +│ │ │ +│ ▼ │ +│ ┌──────────────────────────────────────┐ │ +│ │ Render Cycle │ │ +│ │ - render() │ │ +│ │ - cleanupUnusedHooks() │ │ +│ └──────────────────────────────────────┘ │ +│ │ +└─────────────────────────────────────────────────────────────┘ +``` + +--- + +## 핵심 데이터 구조 + +### 1. Context 구조 (`context.ts`) + +```typescript +interface Context { + root: RootContext; // 루트 렌더링 정보 + hooks: HooksContext; // 훅 상태 관리 + effects: EffectsContext; // 이펙트 큐 +} + +interface HooksContext { + // path를 키로 사용하여 각 컴포넌트의 훅 상태를 격리 + state: Map; // path별 훅 상태 배열 + cursor: Map; // path별 훅 커서 (다음 훅 인덱스) + visited: Set; // 현재 렌더링에서 방문한 path + componentStack: string[]; // 컴포넌트 스택 (현재 실행 중인 컴포넌트 추적) + + // Getter 프로퍼티 + currentPath: string; // 현재 컴포넌트의 path + currentCursor: number; // 현재 컴포넌트의 훅 커서 + currentHooks: State[]; // 현재 컴포넌트의 훅 배열 +} +``` + +### 2. Path 구조 + +Path는 컴포넌트 트리에서의 위치를 나타내는 고유 식별자입니다. + +**Path 생성 규칙** (`createChildPath`): +```typescript +createChildPath(parentPath, key, index) { + const id = key ?? index.toString(); + return parentPath ? `${parentPath}.${id}` : id; +} +``` + +**예시**: +- 루트: `"root"` +- 루트의 첫 번째 자식: `"root.0"` +- 루트의 첫 번째 자식의 두 번째 자식: `"root.0.1"` +- key가 있는 경우: `"root.0.user-123"` + +**타입 충돌 방지 Path**: +- 타입이 다를 때: `"root.0.3_cItem"` (Item 컴포넌트) +- 타입이 다를 때: `"root.0.3_hdiv"` (div 엘리먼트) + +### 3. Hook 상태 구조 + +```typescript +interface StateHook { + kind: "state"; + type: "state"; + value: T; // 실제 상태 값 +} +``` + +--- + +## useState 구현 상세 + +### 함수 시그니처 + +```typescript +function useState( + initialValue: T | (() => T) +): [T, (nextValue: T | ((prev: T) => T)) => void] +``` + +### 실행 흐름 + +#### 1단계: 현재 컴포넌트 정보 가져오기 + +```typescript +const path = context.hooks.currentPath; // 현재 컴포넌트의 path +const cursor = context.hooks.currentCursor; // 현재 훅 커서 +``` + +**동작 원리**: +- `currentPath`: `componentStack`의 마지막 요소를 반환 +- `componentStack`은 `renderFunctionComponent`에서 관리됨 +- 컴포넌트 렌더링 시작 시 path를 스택에 push, 종료 시 pop + +#### 2단계: 훅 상태 배열 초기화 + +```typescript +if (!context.hooks.state.has(path)) { + context.hooks.state.set(path, []); +} +const hooksForPath = context.hooks.state.get(path)!; +``` + +**동작 원리**: +- 각 path마다 독립적인 훅 배열을 가짐 +- 같은 path를 가진 컴포넌트는 같은 훅 배열을 공유 +- 다른 path를 가진 컴포넌트는 완전히 격리된 상태를 가짐 + +#### 3단계: 훅 인스턴스 가져오기 또는 생성 + +```typescript +let hook = hooksForPath[cursor] as { kind: string; type?: string; value: T } | undefined; + +if (!hook) { + // 최초 실행: 초기값 평가 및 저장 + const value = typeof initialValue === "function" + ? (initialValue as () => T)() + : initialValue; + + hook = { + kind: HookTypes.STATE, + type: HookTypes.STATE, + value, + }; + hooksForPath[cursor] = hook; +} +``` + +**동작 원리**: +- `cursor`는 현재 컴포넌트에서 호출된 훅의 순서를 나타냄 +- 첫 번째 `useState` 호출: `cursor = 0` +- 두 번째 `useState` 호출: `cursor = 1` +- 훅이 없으면 초기값으로 생성, 있으면 기존 훅 재사용 + +**이니셜라이저 함수 처리**: +- `initialValue`가 함수인 경우: 최초 한 번만 실행 +- 이후 렌더링에서는 이니셜라이저 함수를 무시하고 기존 값 사용 + +#### 4단계: setState 함수 생성 + +```typescript +const hookIndex = cursor; +const setState = (nextValue: T | ((prev: T) => T)) => { + const currentHook = hooksForPath[hookIndex] as { value: T }; + const previous = currentHook.value; + + // 함수형 업데이트 또는 직접 값 + const next = typeof nextValue === "function" + ? (nextValue as (prev: T) => T)(previous) + : nextValue; + + // 값이 같으면 재렌더링 건너뛰기 + if (Object.is(previous, next)) return; + + // 상태 업데이트 및 재렌더링 요청 + currentHook.value = next; + enqueueRender(); +}; +``` + +**동작 원리**: +- `Object.is()`를 사용하여 값 비교 (=== 와 유사하지만 NaN, +0/-0 처리) +- 값이 같으면 재렌더링을 건너뜀 (성능 최적화) +- 값이 다르면 상태를 업데이트하고 `enqueueRender()` 호출 + +**함수형 업데이트**: +- `setState(prev => prev + 1)`: 이전 값을 기반으로 새 값 계산 +- `setState(5)`: 직접 값 설정 + +#### 5단계: 커서 증가 및 반환 + +```typescript +context.hooks.cursor.set(path, hookIndex + 1); +return [(hooksForPath[hookIndex] as { value: T }).value, setState]; +``` + +**동작 원리**: +- 다음 훅이 올바른 인덱스를 참조하도록 커서를 증가시킴 +- 현재 훅의 값과 setState 함수를 반환 + +--- + +## Path 기반 상태 격리 시스템 + +### Path의 역할 + +Path는 컴포넌트의 고유 식별자로, 다음 목적을 가집니다: + +1. **상태 격리**: 각 컴포넌트의 훅 상태를 독립적으로 관리 +2. **컴포넌트 추적**: 컴포넌트 트리에서의 위치 추적 +3. **상태 유지**: 컴포넌트가 재렌더링되어도 같은 path를 사용하면 상태 유지 + +### Path 생성 시점 + +#### 1. 컴포넌트 마운트 시 + +```typescript +// mountNode 함수에서 +if (typeof node.type === "function") { + const componentVNode = renderFunctionComponent(node.type, node.props, path); + // path는 createChildPath로 생성됨 +} +``` + +#### 2. 컴포넌트 업데이트 시 + +```typescript +// reconcile 함수에서 +if (typeof nextNode.type === "function") { + const componentPath = instance.path; // 기존 path 유지 + // 기존 인스턴스의 path를 사용하여 상태 유지 +} +``` + +**중요**: 컴포넌트가 업데이트될 때는 기존 path를 유지하여 상태를 보존합니다. + +### Path 충돌 방지 + +#### 문제 상황 + +타입이 다른 컴포넌트가 같은 path를 사용하면 훅 상태가 섞일 수 있습니다. + +**예시**: +- Footer 컴포넌트: path `root.0.3`, 상태 `footerCount = 101` +- Item3 컴포넌트: path `root.0.3` (같은 인덱스) +- Item3이 Footer의 상태를 가져옴 ❌ + +#### 해결 방법 + +`reconcileChildren` 함수에서 타입이 다를 때 path 충돌을 방지: + +```typescript +if (!isTypeMatch) { + // 모든 oldChildren의 path를 확인하여 충돌 방지 + for (const oldChild of oldChildren) { + if (oldChild && oldChild.path === childPath) { + // 타입이 다르고 path가 같다면, 타입 정보를 포함하여 고유한 path 생성 + const typeIdentifier = + typeof childVNode.type === "function" + ? `c${childVNode.type.name || "Component"}` + : typeof childVNode.type === "string" + ? `h${childVNode.type}` + : "unknown"; + childPath = `${childPath}_${typeIdentifier}`; + break; + } + } +} +``` + +**결과**: +- Item3: `root.0.3_cItem` (충돌 방지) +- Footer: `root.0.3` (기존 path 유지) + +--- + +## 컴포넌트 라이프사이클과 useState + +### 1. 마운트 (Mount) 단계 + +#### 1.1 컴포넌트 렌더링 시작 + +```typescript +// renderFunctionComponent 함수 +function renderFunctionComponent(component, props, path) { + context.hooks.componentStack.push(path); // 스택에 path 추가 + context.hooks.visited.add(path); // visited에 추가 + context.hooks.cursor.set(path, 0); // 커서를 0으로 초기화 + + if (!context.hooks.state.has(path)) { + context.hooks.state.set(path, []); // 훅 배열 초기화 + } + + try { + return component(props); // 컴포넌트 함수 실행 + } finally { + context.hooks.componentStack.pop(); // 스택에서 제거 + } +} +``` + +**동작 순서**: +1. `componentStack`에 path push → `currentPath`가 이 path를 반환 +2. `visited`에 path 추가 → cleanup에서 제거되지 않도록 보호 +3. `cursor`를 0으로 초기화 → 첫 번째 훅부터 시작 +4. 훅 배열이 없으면 초기화 +5. 컴포넌트 함수 실행 (useState 호출) +6. `componentStack`에서 path pop + +#### 1.2 useState 호출 + +```typescript +// 첫 번째 useState 호출 +const [count, setCount] = useState(0); +// path: "root.0.1" +// cursor: 0 +// hooksForPath[0] = { kind: "state", type: "state", value: 0 } + +// 두 번째 useState 호출 +const [name, setName] = useState(""); +// path: "root.0.1" (같은 컴포넌트) +// cursor: 1 +// hooksForPath[1] = { kind: "state", type: "state", value: "" } +``` + +**상태 저장 구조**: +``` +context.hooks.state = { + "root.0.1": [ + { kind: "state", type: "state", value: 0 }, // 첫 번째 useState + { kind: "state", type: "state", value: "" } // 두 번째 useState + ] +} +``` + +### 2. 업데이트 (Update) 단계 + +#### 2.1 상태 변경 트리거 + +```typescript +setCount(1); // setState 호출 +// 1. currentHook.value = 1로 업데이트 +// 2. enqueueRender() 호출 +``` + +#### 2.2 재렌더링 시작 + +```typescript +// render 함수 +export const render = (): void => { + context.hooks.visited.clear(); // visited만 초기화 (상태는 유지) + const newInstance = reconcile(root.container, root.instance, root.node, "root"); + root.instance = newInstance; + cleanupUnusedHooks(); // 사용되지 않은 훅 정리 +}; +``` + +**중요**: `visited`만 초기화하고 `state`와 `cursor`는 유지합니다. + +#### 2.3 컴포넌트 재렌더링 + +```typescript +// renderFunctionComponent 함수 +context.hooks.cursor.set(path, 0); // 커서를 0으로 리셋 +// 하지만 state는 유지됨 +``` + +**동작 순서**: +1. `cursor`를 0으로 리셋 (훅 호출 순서 보장) +2. `visited`에 path 추가 (cleanup 방지) +3. 컴포넌트 함수 실행 +4. `useState` 호출 시 기존 훅 재사용 + +```typescript +// useState에서 +let hook = hooksForPath[cursor]; // cursor = 0 +// hook이 이미 존재하므로 초기값 무시하고 기존 값 사용 +// hook.value = 1 (이전에 setCount(1)로 업데이트된 값) +``` + +### 3. 언마운트 (Unmount) 단계 + +#### 3.1 컴포넌트 제거 + +```typescript +// reconcile 함수에서 +if (!node) { + if (instance) removeInstance(parentDom, instance); + return null; +} +``` + +#### 3.2 훅 상태 정리 + +```typescript +// cleanupUnusedHooks 함수 +export const cleanupUnusedHooks = () => { + for (const [path, hooks] of context.hooks.state.entries()) { + if (!context.hooks.visited.has(path)) { + // 이펙트 클린업 함수 실행 + hooks.forEach((hook) => { + if (hook.type === HookTypes.EFFECT && typeof hook.destroy === "function") { + hook.destroy(); + } + }); + + // 훅 상태 삭제 + context.hooks.state.delete(path); + context.hooks.cursor.delete(path); + } + } +}; +``` + +**동작 원리**: +- `visited`에 없는 path는 사용되지 않는 컴포넌트 +- 해당 path의 모든 훅 상태를 삭제 +- 이펙트 클린업 함수 실행 (useEffect의 경우) + +--- + +## Reconciliation과 useState 연동 + +### 1. reconcile 함수의 역할 + +`reconcile` 함수는 이전 인스턴스와 새로운 VNode를 비교하여 DOM을 업데이트합니다. + +#### 1.1 함수형 컴포넌트 업데이트 + +```typescript +if (typeof nextNode.type === "function") { + // 기존 인스턴스의 path를 사용하여 훅 상태를 올바르게 유지 + const componentPath = instance.path; + const componentVNode = renderFunctionComponent(nextNode.type, nextNode.props, componentPath); + // ... +} +``` + +**핵심 원칙**: +- 컴포넌트가 업데이트될 때는 **기존 path를 유지**합니다 +- 이는 컴포넌트가 이동하거나 재렌더링되어도 상태를 보존하기 위함입니다 + +#### 1.2 타입이 다를 때 처리 + +```typescript +if (!instance || nextNode.type !== instance.node.type) { + if (instance) { + removeInstance(parentDom, instance); + } + + // 타입이 다를 때는 기존 path의 훅 상태를 정리 + const isTypeChange = instance !== null && nextNode.type !== instance.node.type; + if (isTypeChange && context.hooks.state.has(path)) { + // 기존 path의 훅 상태를 정리 + const oldHooks = context.hooks.state.get(path); + if (oldHooks) { + // 이펙트 클린업 함수 실행 + oldHooks.forEach((hook) => { + if (hook.type === HookTypes.EFFECT && typeof hook.destroy === "function") { + hook.destroy(); + } + }); + } + context.hooks.state.delete(path); + context.hooks.cursor.delete(path); + } + + return mountNode(parentDom, nextNode, path); +} +``` + +**동작 원리**: +- 타입이 다를 때는 완전히 새로운 컴포넌트로 간주 +- 기존 path의 훅 상태를 정리하여 타입이 다른 컴포넌트가 같은 path를 사용할 때 상태가 섞이지 않도록 보장 + +### 2. reconcileChildren 함수의 역할 + +`reconcileChildren` 함수는 자식 컴포넌트들을 재조정합니다. + +#### 2.1 인스턴스 매칭 로직 + +```typescript +// key가 없는 경우: 인덱스로 매칭하되 타입도 확인 +if ( + unkeyedInstances[index] !== undefined && + !usedUnkeyedIndices.has(index) && + unkeyedInstances[index]?.node.type === childVNode.type +) { + matchedInstance = unkeyedInstances[index]; + usedUnkeyedIndices.add(index); +} else { + // 타입이 같은 인스턴스를 찾기 + for (let i = 0; i < unkeyedInstances.length; i++) { + if ( + unkeyedInstances[i] !== undefined && + !usedUnkeyedIndices.has(i) && + unkeyedInstances[i]?.node.type === childVNode.type + ) { + matchedInstance = unkeyedInstances[i]; + usedUnkeyedIndices.add(i); + break; + } + } +} +``` + +**핵심 원칙**: +- **타입이 같을 때만** 인스턴스를 매칭합니다 +- 타입이 다르면 새로 마운트합니다 + +#### 2.2 Path 생성 및 충돌 방지 + +```typescript +const isTypeMatch = matchedInstance !== null && matchedInstance.node.type === childVNode.type; +let childPath = + isTypeMatch && matchedInstance + ? matchedInstance.path // 타입이 같으면 기존 path 사용 + : createChildPath(parentPath, childVNode.key ?? null, index); // 새 path 생성 + +// 타입이 다를 때 path 충돌 방지 +if (!isTypeMatch) { + for (const oldChild of oldChildren) { + if (oldChild && oldChild.path === childPath) { + // 타입 정보를 포함하여 고유한 path 생성 + const typeIdentifier = + typeof childVNode.type === "function" + ? `c${childVNode.type.name || "Component"}` + : typeof childVNode.type === "string" + ? `h${childVNode.type}` + : "unknown"; + childPath = `${childPath}_${typeIdentifier}`; + break; + } + } +} +``` + +**동작 원리**: +1. 타입이 같으면 기존 path 사용 (상태 유지) +2. 타입이 다르면 새 path 생성 +3. 새 path가 기존 인스턴스의 path와 충돌하면 타입 정보를 추가하여 고유하게 만듦 + +--- + +## 상태 업데이트 플로우 + +### 전체 플로우 다이어그램 + +``` +사용자 액션 (setState 호출) + │ + ▼ +┌─────────────────────┐ +│ setState 함수 실행 │ +│ - 값 비교 │ +│ - 상태 업데이트 │ +│ - enqueueRender() │ +└─────────────────────┘ + │ + ▼ +┌─────────────────────┐ +│ enqueueRender() │ +│ - 마이크로태스크 큐 │ +│ - 중복 실행 방지 │ +└─────────────────────┘ + │ + ▼ +┌─────────────────────┐ +│ render() 함수 │ +│ - visited.clear() │ +│ - reconcile() │ +│ - cleanupUnusedHooks()│ +└─────────────────────┘ + │ + ▼ +┌─────────────────────┐ +│ reconcile() │ +│ - 인스턴스 비교 │ +│ - 컴포넌트 재렌더링│ +└─────────────────────┘ + │ + ▼ +┌─────────────────────┐ +│ renderFunctionComponent()│ +│ - componentStack.push()│ +│ - cursor.set(0) │ +│ - component() 실행 │ +└─────────────────────┘ + │ + ▼ +┌─────────────────────┐ +│ useState() 호출 │ +│ - 기존 훅 재사용 │ +│ - 업데이트된 값 반환│ +└─────────────────────┘ + │ + ▼ +┌─────────────────────┐ +│ DOM 업데이트 │ +│ - 변경된 값 반영 │ +└─────────────────────┘ +``` + +### 단계별 상세 설명 + +#### 1. setState 호출 + +```typescript +setCount(1); +// 또는 +setCount(prev => prev + 1); +``` + +**내부 동작**: +1. 현재 훅의 값을 가져옴 +2. 함수형 업데이트인 경우 이전 값을 인자로 함수 실행 +3. `Object.is()`로 값 비교 +4. 값이 같으면 early return (재렌더링 건너뜀) +5. 값이 다르면 상태 업데이트 및 `enqueueRender()` 호출 + +#### 2. enqueueRender (마이크로태스크 큐) + +```typescript +export const enqueueRender = withEnqueue(render); +``` + +**동작 원리**: +- `withEnqueue`는 마이크로태스크 큐를 사용하여 중복 실행을 방지 +- 여러 `setState` 호출이 있어도 `render`는 한 번만 실행됨 +- `Promise.resolve().then(render)` 방식으로 비동기 실행 + +#### 3. render 함수 + +```typescript +export const render = (): void => { + context.hooks.visited.clear(); // visited만 초기화 + const newInstance = reconcile(root.container, root.instance, root.node, "root"); + root.instance = newInstance; + cleanupUnusedHooks(); // 사용되지 않은 훅 정리 +}; +``` + +**중요 사항**: +- `visited`만 초기화하고 `state`와 `cursor`는 유지 +- 이는 컴포넌트가 재렌더링되어도 상태를 보존하기 위함 + +#### 4. reconcile 및 컴포넌트 재렌더링 + +```typescript +// reconcile에서 함수형 컴포넌트 업데이트 +const componentPath = instance.path; // 기존 path 유지 +const componentVNode = renderFunctionComponent(nextNode.type, nextNode.props, componentPath); +``` + +**동작 순서**: +1. 기존 인스턴스의 path를 가져옴 +2. `renderFunctionComponent` 호출하여 컴포넌트 재렌더링 +3. 컴포넌트 함수 실행 중 `useState` 호출 +4. `useState`는 기존 훅을 재사용하여 업데이트된 값 반환 + +#### 5. cleanupUnusedHooks + +```typescript +export const cleanupUnusedHooks = () => { + for (const [path, hooks] of context.hooks.state.entries()) { + if (!context.hooks.visited.has(path)) { + // 사용되지 않는 경로의 훅 정리 + context.hooks.state.delete(path); + context.hooks.cursor.delete(path); + } + } +}; +``` + +**동작 원리**: +- `visited`에 없는 path는 현재 렌더링에서 사용되지 않은 컴포넌트 +- 해당 path의 훅 상태를 삭제하여 메모리 누수 방지 + +--- + +## 주요 문제 해결 사항 + +### 문제 1: 타입이 다른 컴포넌트가 같은 path를 사용하는 경우 + +#### 문제 상황 + +``` +초기: [Item0, Item1, Item2, Footer] + path: root.0.0, root.0.1, root.0.2, root.0.3 + +Item 개수 2로 줄임: [Item0, Item1, Footer] + path: root.0.0, root.0.1, root.0.2 (Footer가 root.0.2로 이동) + +Item 개수 4로 늘림: [Item0, Item1, Item2, Item3, Footer] + Item3이 root.0.3 path를 사용 → Footer의 이전 상태(root.0.3)를 가져옴 ❌ +``` + +#### 해결 방법 + +`reconcileChildren`에서 타입이 다를 때 path 충돌 방지: + +```typescript +if (!isTypeMatch) { + for (const oldChild of oldChildren) { + if (oldChild && oldChild.path === childPath) { + // 타입 정보를 포함하여 고유한 path 생성 + const typeIdentifier = `c${childVNode.type.name || "Component"}`; + childPath = `${childPath}_${typeIdentifier}`; + break; + } + } +} +``` + +**결과**: +- Item3: `root.0.3_cItem` (고유한 path) +- Footer: `root.0.2` (기존 path 유지) +- 상태가 섞이지 않음 ✅ + +### 문제 2: 타입이 다를 때 기존 path의 훅 상태가 남아있는 경우 + +#### 문제 상황 + +타입이 다른 컴포넌트로 교체될 때, 기존 path의 훅 상태가 남아있어 새 컴포넌트가 이전 상태를 가져올 수 있음 + +#### 해결 방법 + +`reconcile` 함수에서 타입이 다를 때 기존 path의 훅 상태 정리: + +```typescript +const isTypeChange = instance !== null && nextNode.type !== instance.node.type; +if (isTypeChange && context.hooks.state.has(path)) { + // 기존 path의 훅 상태를 정리 + const oldHooks = context.hooks.state.get(path); + if (oldHooks) { + oldHooks.forEach((hook) => { + if (hook.type === HookTypes.EFFECT && typeof hook.destroy === "function") { + hook.destroy(); + } + }); + } + context.hooks.state.delete(path); + context.hooks.cursor.delete(path); +} +``` + +**결과**: +- 타입이 다른 컴포넌트로 교체될 때 기존 상태가 정리됨 +- 새 컴포넌트는 깨끗한 상태로 시작 ✅ + +### 문제 3: 컴포넌트가 이동할 때 상태 유지 + +#### 문제 상황 + +컴포넌트가 인덱스 변경으로 이동할 때 상태를 유지해야 함 + +#### 해결 방법 + +`reconcile` 함수에서 기존 인스턴스의 path를 유지: + +```typescript +if (typeof nextNode.type === "function") { + const componentPath = instance.path; // 기존 path 유지 + const componentVNode = renderFunctionComponent(nextNode.type, nextNode.props, componentPath); + // ... +} +``` + +**결과**: +- 컴포넌트가 이동해도 같은 path를 사용하여 상태 유지 ✅ + +--- + +## 핵심 설계 원칙 + +### 1. Path 기반 상태 격리 + +- 각 컴포넌트는 고유한 path를 가짐 +- 같은 path를 가진 컴포넌트는 같은 훅 배열을 공유 +- 다른 path를 가진 컴포넌트는 완전히 격리된 상태를 가짐 + +### 2. 타입 기반 인스턴스 매칭 + +- 타입이 같을 때만 인스턴스를 재사용 +- 타입이 다르면 새로 마운트 +- 타입이 다를 때 path 충돌 방지 + +### 3. 상태 보존 + +- 컴포넌트가 재렌더링되어도 같은 path를 사용하면 상태 유지 +- 컴포넌트가 이동해도 기존 path를 유지하여 상태 보존 + +### 4. 메모리 관리 + +- 사용되지 않는 컴포넌트의 훅 상태는 자동으로 정리 +- `visited` Set을 사용하여 현재 렌더링에서 사용된 컴포넌트만 보존 + +--- + +## 코드 참조 위치 + +### 주요 파일 + +1. **`packages/react/src/core/hooks.ts`** + - `useState` 구현 (38-79 라인) + - `cleanupUnusedHooks` 구현 (13-31 라인) + +2. **`packages/react/src/core/context.ts`** + - `HooksContext` 구조 정의 (26-77 라인) + - `currentPath`, `currentCursor`, `currentHooks` getter + +3. **`packages/react/src/core/reconciler.ts`** + - `reconcile` 함수 (26-123 라인) + - `reconcileChildren` 함수 (151-267 라인) + - `renderFunctionComponent` 함수 (269-285 라인) + - `mountNode` 함수 (287-367 라인) + +4. **`packages/react/src/core/render.ts`** + - `render` 함수 (12-29 라인) + - `enqueueRender` 함수 (34 라인) + +5. **`packages/react/src/core/elements.ts`** + - `createChildPath` 함수 (93-104 라인) + +--- + +## 테스트 케이스 분석 + +### 성공한 테스트: "중첩된 컴포넌트에서 useState가 각각 독립적으로 동작한다" + +#### 테스트 시나리오 + +```typescript +초기: [Item0, Item1, Item2, Footer] + - Item0: path = root.0.0, count = 0 + - Item1: path = root.0.1, count = 0 + - Item2: path = root.0.2, count = 0 + - Footer: path = root.0.3, footerCount = 100 + +Item0.count = 1, Item1.count = 2, Footer.footerCount = 101 + +Item 개수 2로 줄임: [Item0, Item1, Footer] + - Item0: path = root.0.0 (유지), count = 1 (유지) ✅ + - Item1: path = root.0.1 (유지), count = 2 (유지) ✅ + - Footer: path = root.0.2 (변경), footerCount = 101 (유지) ✅ + +Item 개수 4로 늘림: [Item0, Item1, Item2, Item3, Footer] + - Item0: path = root.0.0 (유지), count = 1 (유지) ✅ + - Item1: path = root.0.1 (유지), count = 2 (유지) ✅ + - Item2: path = root.0.2_cItem (새로 생성), count = 0 (초기값) ✅ + - Item3: path = root.0.3_cItem (충돌 방지), count = 0 (초기값) ✅ + - Footer: path = root.0.2 (유지), footerCount = 101 (유지) ✅ +``` + +#### 핵심 검증 사항 + +1. ✅ 각 컴포넌트의 상태가 독립적으로 동작 +2. ✅ 컴포넌트가 이동해도 상태 유지 +3. ✅ 새로 생성된 컴포넌트는 초기값 사용 +4. ✅ 타입이 다른 컴포넌트가 같은 path를 사용해도 상태가 섞이지 않음 + +--- + +## 결론 + +이 구현은 React의 useState와 유사한 동작을 제공하며, 다음 핵심 기능을 구현합니다: + +1. **Path 기반 상태 격리**: 각 컴포넌트의 상태를 독립적으로 관리 +2. **상태 보존**: 컴포넌트 재렌더링 및 이동 시 상태 유지 +3. **타입 기반 매칭**: 타입이 같을 때만 인스턴스 재사용 +4. **충돌 방지**: 타입이 다른 컴포넌트가 같은 path를 사용해도 상태가 섞이지 않음 +5. **메모리 관리**: 사용되지 않는 컴포넌트의 상태 자동 정리 + +이러한 설계를 통해 React와 유사한 상태 관리 시스템을 구현할 수 있습니다. + diff --git a/.cursor/mockdowns/react-implementation/03-useEffect-implementation-plan.md b/.cursor/mockdowns/react-implementation/03-useEffect-implementation-plan.md new file mode 100644 index 00000000..44b55d7d --- /dev/null +++ b/.cursor/mockdowns/react-implementation/03-useEffect-implementation-plan.md @@ -0,0 +1,105 @@ +# useEffect 구현 계획 및 완료 보고 + +## 목표 ✅ + +`basic.mini-react.test.tsx (1049-1069)` 테스트를 통과하기 위한 `useEffect` 훅 구현 + +## 완료 상태 + +✅ 모든 테스트 통과 (3/3) + +- ✅ useEffect는 렌더 이후 비동기로 실행된다 +- ✅ useEffect는 의존성이 변경될 때만 실행된다 +- ✅ useEffect 클린업은 재실행과 언마운트 시 호출된다 + +## 테스트 요구사항 분석 + +### 테스트 1: "useEffect는 렌더 이후 비동기로 실행된다" + +- 렌더링 중에는 "render"만 callOrder에 추가 +- `flushMicrotasks()` 후에 "effect"가 추가되어야 함 +- 즉, useEffect는 렌더링 후 비동기로 실행되어야 함 + +### 테스트 2: "useEffect는 의존성이 변경될 때만 실행된다" + +- 의존성 배열이 변경될 때만 이펙트 실행 +- `shallowEquals`를 사용하여 의존성 비교 + +### 테스트 3: "useEffect 클린업은 재실행과 언마운트 시 호출된다" + +- 이펙트가 재실행될 때 이전 클린업 함수 먼저 실행 +- 컴포넌트 언마운트 시 클린업 함수 실행 + +## 현재 구조 분석 + +### 1. Context 구조 (`context.ts`) + +```typescript +effects: { + queue: [], // Array<{ path: string; cursor: number }> +} +``` + +### 2. EffectHook 타입 (`types.ts`) + +```typescript +export interface EffectHook { + kind: HookType["EFFECT"]; + deps: unknown[] | null; + cleanup: (() => void) | null; + effect: () => (() => void) | void; +} +``` + +### 3. Render 함수 (`render.ts`) + +- 렌더링 후 이펙트를 실행하는 로직이 필요함 + +## 구현 계획 + +### 1단계: useEffect 훅 구현 (`hooks.ts`) + +1. **의존성 배열 비교** + - 이전 훅이 없으면 첫 렌더링이므로 실행 + - 이전 훅이 있으면 `shallowEquals`로 의존성 비교 + - 의존성이 변경되었거나 첫 렌더링이면 실행 + +2. **이전 클린업 함수 실행** + - 이전 훅의 `cleanup` 함수가 있으면 먼저 실행 + +3. **이펙트를 큐에 추가** + - `context.effects.queue`에 `{ path, cursor }` 추가 + - 이펙트 함수 자체는 저장하지 않고, path와 cursor로 나중에 찾음 + +4. **훅 상태 저장** + - `context.hooks.state`에 `EffectHook` 객체 저장 + - `deps`, `cleanup`, `effect` 저장 + +### 2단계: 이펙트 실행 로직 (`render.ts` 또는 별도 함수) + +1. **렌더링 완료 후 이펙트 실행** + - `render` 함수 끝에서 `flushEffects` 호출 + - `flushEffects`는 `context.effects.queue`를 순회하며 실행 + +2. **이펙트 실행** + - `path`와 `cursor`로 훅 찾기 + - 이펙트 함수 실행 + - 클린업 함수가 반환되면 훅에 저장 + +3. **큐 초기화** + - 실행 후 큐 비우기 + +### 3단계: 클린업 처리 + +1. **재실행 시 클린업** + - `useEffect`에서 이전 클린업 함수 실행 + +2. **언마운트 시 클린업** + - `cleanupUnusedHooks`에서 이미 처리됨 (확인 필요) + +## 구현 순서 + +1. `useEffect` 함수 구현 +2. `flushEffects` 함수 구현 +3. `render` 함수에 `flushEffects` 호출 추가 +4. 테스트 실행 및 디버깅 diff --git a/.cursor/mockdowns/react-implementation/04-fragment-update-fix.md b/.cursor/mockdowns/react-implementation/04-fragment-update-fix.md new file mode 100644 index 00000000..7c7d102a --- /dev/null +++ b/.cursor/mockdowns/react-implementation/04-fragment-update-fix.md @@ -0,0 +1,92 @@ +# Fragment 업데이트 처리 수정 + +## 문제 상황 + +`basic.mini-react.test.tsx (1234-1284)` 테스트에서 에러 발생 + +- `#dynamic` 요소가 렌더링되지 않음 +- Fragment의 조건부 자식이 업데이트될 때 제대로 처리되지 않음 + +## 원인 분석 + +`reconcile` 함수에서 Fragment 타입의 업데이트 처리가 누락되어 있었습니다. + +현재 처리되는 타입: + +- ✅ `TEXT_ELEMENT` - 텍스트 노드 업데이트 +- ✅ `string` - 일반 DOM 요소 업데이트 +- ✅ `function` - 함수형 컴포넌트 업데이트 +- ❌ `Fragment` - Fragment 업데이트 (누락) + +## 해결 방법 + +`reconcile` 함수에 Fragment 업데이트 로직을 추가했습니다. + +### 구현 내용 + +1. **Fragment 업데이트 로직 추가** (`packages/react/src/core/reconciler.ts`) + - Fragment는 자체 DOM이 없으므로, 자식들을 재조정할 때 부모 DOM을 사용 + - 기존 자식 인스턴스가 있으면 그 DOM의 부모를 찾아서 사용 + - 없으면 `parentDom`을 사용 + - `normalizeChildren`로 자식 VNode 배열 정규화 + - `reconcileChildren`으로 자식 인스턴스 재조정 + +2. **핵심 로직** + + ```typescript + // Fragment 업데이트 + if (nextNode.type === Fragment) { + // Fragment는 자체 DOM이 없으므로, 자식들을 재조정할 때 부모 DOM을 사용해야 합니다 + const existingChildInstance = instance.children?.[0]; + let childParentDom = parentDom; + + if (existingChildInstance) { + const childDom = getFirstDomFromChildren([existingChildInstance]); + if (childDom) { + if (childDom.parentElement) { + childParentDom = childDom.parentElement; + } else if (childDom.parentNode && childDom.parentNode instanceof HTMLElement) { + childParentDom = childDom.parentNode; + } + } + } + + // Fragment의 자식들을 재조정합니다 + const childNodes = normalizeChildren(nextNode.props.children); + instance.children = reconcileChildren(childParentDom, instance.children || [], childNodes, path); + instance.node = nextNode; + return instance; + } + ``` + +## 테스트 케이스 + +```typescript +function Dynamic({ visible }: { visible: boolean }) { + return <>{visible &&

dynamic

}; +} + +function Sample() { + const [visible, update] = useState(false); + return ( +
+ static + + +
+ ); +} +``` + +- 초기: `visible=false` → Fragment 자식 없음 +- 업데이트: `visible=true` → Fragment에 `

dynamic

` 추가 +- 기존 DOM 요소들(`#static`, `#list`, `#first`, `#second`)은 유지되어야 함 + +## 변경 파일 + +- `packages/react/src/core/reconciler.ts` - Fragment 업데이트 로직 추가 + +## 완료 상태 + +✅ 테스트 통과 +✅ 린터 에러 없음 diff --git a/.cursor/mockdowns/react-implementation/05-key-based-dom-reordering.md b/.cursor/mockdowns/react-implementation/05-key-based-dom-reordering.md new file mode 100644 index 00000000..c4d419bb --- /dev/null +++ b/.cursor/mockdowns/react-implementation/05-key-based-dom-reordering.md @@ -0,0 +1,116 @@ +# key 기반 DOM 재배치 처리 + +## 문제 상황 + +`basic.mini-react.test.tsx (1410-1447)` 테스트에서 에러 발생 + +- key가 있는 자식을 재배치할 때 기존 DOM이 재사용되지만 순서가 변경되지 않음 +- 기대: `[initialOrder[1], initialOrder[2], initialOrder[0]]` (B, C, A 순서) +- 실제: `[initialOrder[0], initialOrder[1], initialOrder[2]]` (A, B, C 순서, 변경되지 않음) + +## 원인 분석 + +`reconcileChildren` 함수에서 key 기반 매칭은 올바르게 작동하지만, DOM 순서 재배치 로직이 누락되어 있었습니다. + +- ✅ key 기반 인스턴스 매칭: 올바르게 작동 +- ✅ 인스턴스 재사용: 올바르게 작동 +- ❌ DOM 순서 재배치: 누락됨 + +## 해결 방법 + +`reconcileChildren` 함수에 DOM 순서 재배치 로직을 추가했습니다. + +### 구현 내용 + +1. **DOM 순서 재배치 로직 추가** (`packages/react/src/core/reconciler.ts`) + - 역순으로 순회하여 DOM을 올바른 위치에 배치 + - 역순 순회를 사용하면 다음 인스턴스의 첫 DOM 노드를 anchor로 사용할 수 있어 효율적 + - 각 인스턴스의 첫 DOM 노드를 찾아 올바른 위치에 배치 + +2. **핵심 로직** + + ```typescript + // 5. DOM 순서 재배치: 역순으로 순회하여 올바른 위치에 DOM 배치 + // 역순으로 순회하면 다음 인스턴스의 첫 DOM 노드를 anchor로 사용할 수 있어 효율적입니다 + for (let i = newInstances.length - 1; i >= 0; i--) { + const instance = newInstances[i]; + if (!instance) continue; + + // 현재 인스턴스의 첫 DOM 노드 찾기 + const currentFirstDom = getFirstDomFromChildren([instance]); + if (!currentFirstDom) continue; + + // 다음 인스턴스의 첫 DOM 노드를 anchor로 사용 + const nextInstance = i + 1 < newInstances.length ? newInstances[i + 1] : null; + const nextFirstDom = nextInstance ? getFirstDomFromChildren([nextInstance]) : null; + + // 현재 DOM이 올바른 위치에 있는지 확인 + if (nextFirstDom) { + // anchor 앞에 있어야 하는데 현재 위치가 다르면 재배치 + if (currentFirstDom.nextSibling !== nextFirstDom) { + // DOM 노드들을 anchor 앞에 삽입 + const domNodes = getDomNodes(instance); + domNodes.forEach((node) => { + parentDom.insertBefore(node, nextFirstDom); + }); + } + } else { + // anchor가 없으면 마지막 위치에 있어야 함 + if (currentFirstDom.nextSibling !== null) { + // DOM 노드들을 마지막에 삽입 + const domNodes = getDomNodes(instance); + domNodes.forEach((node) => { + parentDom.appendChild(node); + }); + } + } + } + ``` + +### 동작 방식 + +1. **역순 순회**: 마지막 인스턴스부터 첫 번째 인스턴스까지 역순으로 순회 +2. **Anchor 찾기**: 다음 인스턴스(i + 1)의 첫 DOM 노드를 anchor로 사용 +3. **위치 확인**: 현재 인스턴스의 첫 DOM 노드가 anchor의 바로 앞에 있는지 확인 +4. **재배치**: 위치가 다르면 DOM 노드들을 올바른 위치에 삽입 + +### 역순 순회를 사용하는 이유 + +- 정순 순회: 이전 인스턴스를 anchor로 사용하려면 이미 처리된 인스턴스의 위치를 기억해야 함 +- 역순 순회: 다음 인스턴스(아직 처리되지 않음)를 anchor로 사용하면 효율적이고 간단함 + +## 테스트 케이스 + +```typescript +function List() { + const [items, setItems] = useState([ + { id: "a", label: "A" }, + { id: "b", label: "B" }, + { id: "c", label: "C" }, + ]); + reorder = () => setItems(([first, ...rest]) => [...rest, first]); + return ( +
    + {items.map((item) => ( +
  • + {item.label} +
    • + ))} +
+ ); +} +``` + +- 초기: A, B, C 순서 +- `reorder()` 호출: 첫 번째 아이템을 마지막으로 이동 → B, C, A 순서가 되어야 함 +- 기존 DOM 요소들은 재사용되되 순서만 변경되어야 함 + +## 변경 파일 + +- `packages/react/src/core/reconciler.ts` - DOM 순서 재배치 로직 추가 (339-376줄) +- `packages/react/src/core/reconciler.ts` - `getDomNodes` import 추가 + +## 완료 상태 + +✅ 테스트 통과 +✅ 린터 에러 없음 diff --git a/.cursor/mockdowns/react-implementation/06-hooks-impl.md b/.cursor/mockdowns/react-implementation/06-hooks-impl.md new file mode 100644 index 00000000..6c1314cb --- /dev/null +++ b/.cursor/mockdowns/react-implementation/06-hooks-impl.md @@ -0,0 +1,22 @@ +# Mini-React Hooks 구현 인수인계 (2025-11-19) + +## 1. 작업 개요 +- `useRef`를 `useState` lazy initializer로 한 번만 생성하도록 구현했습니다. +- `useMemo`는 이전 deps/value를 `useRef`로 저장하여 의존성 변경 시에만 factory를 재실행합니다. +- `useCallback`은 `useMemo`를 활용해 콜백 참조를 메모이제이션합니다. +- `useDeepMemo`는 `deepEquals`를 이용해 깊은 비교 후 메모을 제공합니다. +- `useAutoCallback`은 `useRef` + `useCallback`으로 안정된 참조에서 최신 함수를 호출합니다. + +## 2. 테스트 진행 현황 +- `pnpm test -- advanced.hooks.test.tsx -t "리렌더링이 되어도 useRef의 참조값이 유지된다" --run` +- `pnpm test -- advanced.hooks.test.tsx -t "useMemo 메모이제이션 테스트" --run` +- `pnpm test -- advanced.hooks.test.tsx -t "useCallback 메모이제이션 테스트" --run` +- `pnpm test -- advanced.hooks.test.tsx -t "useDeepMemo" --run` +- `useAutoCallback` it 테스트는 명령 실행 단계에서 거부되어 반영되지 못했습니다. 동일한 패턴의 명령을 여러 번 시도했으나 시스템에서 실행을 중단했습니다. +- 모든 명령 실행 시 `advanced.hoc.test.tsx`의 다른 미구현 영역 때문에 전체 테스트는 실패 상태입니다. hooks 관련 it들은 위에 기재한 범위까지 통과했습니다. + +## 3. 추가 메모 +- 향후 `useAutoCallback` it 테스트를 실행해야 합니다. vitest가 허용되는 명령 형식을 요구하는 것으로 보이니 IDE에서 직접 실행하는 방식을 권장합니다. +- hoc 관련 실패 케이스는 이번 작업 범위 밖이므로 별도 이슈로 추적해야 합니다. +- 코드 내 주석은 모두 한글로 작성하여 주니어도 이해할 수 있게 했습니다. + diff --git a/.cursor/mockdowns/react-implementation/07-memo-hoc-implementation.md b/.cursor/mockdowns/react-implementation/07-memo-hoc-implementation.md new file mode 100644 index 00000000..4b973560 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/07-memo-hoc-implementation.md @@ -0,0 +1,123 @@ +# memo HOC 구현 문서 + +## 📋 작업 개요 + +- **작업 일자**: 2025-01-19 +- **작업 범위**: `packages/react/src/hocs/memo.ts` 구현 +- **관련 테스트**: `packages/react/src/__tests__/advanced.hoc.test.tsx` (19-62 라인) + +## 🎯 구현 목표 + +`memo` HOC를 구현하여 컴포넌트의 props가 변경되지 않았을 경우, 마지막 렌더링 결과를 재사용하여 리렌더링을 방지합니다. + +## 📝 핵심 로직 설명 + +### 1. memo HOC 구조 + +```typescript +export function memo

(Component: FunctionComponent

, equals = shallowEquals) +``` + +- **Component**: 메모이제이션할 컴포넌트 +- **equals**: props를 비교할 함수 (기본값: `shallowEquals`) +- **반환값**: 메모이제이션이 적용된 새로운 컴포넌트 + +### 2. 메모이제이션 로직 + +```typescript +const MemoizedComponent: FunctionComponent

= (props) => { + // 1. useRef로 이전 props와 렌더링 결과 저장 + const memoRef = useRef({ + prevProps: null, + prevResult: null, + }); + + // 2. 이전 props와 현재 props 비교 + if (memoRef.current.prevProps !== null && equals(memoRef.current.prevProps, props)) { + // props가 같으면 이전 렌더링 결과 재사용 + return memoRef.current.prevResult; + } + + // 3. props가 변경되었거나 첫 렌더링인 경우 컴포넌트 실행 + const result = Component(props); + memoRef.current = { + prevProps: props, + prevResult: result, + }; + + return result; +}; +``` + +### 3. 동작 흐름 + +1. **첫 렌더링**: `prevProps`가 `null`이므로 컴포넌트를 실행하고 결과를 저장 +2. **두 번째 렌더링**: `equals` 함수로 이전 props와 현재 props를 비교 + - **같으면**: 이전 렌더링 결과를 반환 (컴포넌트 재실행 안 함) + - **다르면**: 컴포넌트를 실행하고 새로운 결과를 저장 + +## 🔍 주요 구현 포인트 + +### useRef를 사용한 이유 + +- `useRef`는 리렌더링 간에도 값을 유지하면서 리렌더링을 트리거하지 않습니다 +- 이전 props와 렌더링 결과를 저장하기에 적합합니다 +- `useState`를 사용하면 값 변경 시 리렌더링이 발생하므로 부적합합니다 + +### equals 함수의 역할 + +- 기본값은 `shallowEquals`로 얕은 비교를 수행합니다 +- `deepMemo`는 `deepEquals`를 사용하여 깊은 비교를 수행합니다 +- 사용자가 커스텀 비교 함수를 제공할 수 있습니다 + +## 📂 관련 파일 + +- **구현 파일**: `packages/react/src/hocs/memo.ts` +- **테스트 파일**: `packages/react/src/__tests__/advanced.hoc.test.tsx` +- **의존성**: `useRef` (hooks), `shallowEquals` (utils) + +## ✅ 테스트 케이스 + +### memo 테스트 + +```typescript +it("props로 전달하는 값이 변경되어야 리렌더링 된다.", async () => { + const MemoizedComponent = memo(TestComponent); + // ... + + // 동일한 값으로 setState - 메모이제이션으로 호출되지 않아야 함 + rerender!({ value: 1 }); + expect(TestComponent).toHaveBeenCalledTimes(1); + + // 다른 값으로 setState - 새로 호출되어야 함 + rerender!({ value: 2 }); + expect(TestComponent).toHaveBeenCalledTimes(2); +}); +``` + +## 🔗 관련 구현 + +### deepMemo + +`deepMemo`는 `memo`를 사용하여 `deepEquals`를 전달합니다: + +```typescript +export function deepMemo

(Component: FunctionComponent

) { + return memo(Component, deepEquals); +} +``` + +## 📌 주의사항 + +1. **props 비교**: `equals` 함수가 정확하게 동작해야 메모이제이션이 올바르게 작동합니다 +2. **렌더링 결과 저장**: VNode를 저장하므로 참조 동일성에 주의해야 합니다 +3. **첫 렌더링**: `prevProps`가 `null`인 경우를 반드시 처리해야 합니다 + +## 🚀 다음 단계 + +- [ ] 테스트 실행 및 검증 +- [ ] deepMemo 관련 테스트 확인 +- [ ] 성능 최적화 검토 (필요시) + + + diff --git a/.cursor/mockdowns/react-implementation/08-memo-rerender-debug.md b/.cursor/mockdowns/react-implementation/08-memo-rerender-debug.md new file mode 100644 index 00000000..95956211 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/08-memo-rerender-debug.md @@ -0,0 +1,20 @@ +# Memo HOC 리렌더 디버깅 노트 + +## 진행 상황 + +- `memo` HOC에서 `useRef` 초기화가 null을 반환하며 `prevProps` 접근 시 에러 발생 → 방어 로직 추가. +- 동일 props 전달에도 `TestComponent`가 두 번 호출되는 문제 재현됨. shallow 비교에서 `{ value: 1 }` 객체가 항상 다른 참조라 true가 나오지 않아 memo 캐시가 갱신됨을 확인. +- 추정 원인: wrapper `TestWrapper`가 새로운 props 객체를 만들기 때문에 `prevProps`와 `props` 레퍼런스가 달라 `shallowEquals`가 false. 얕은 비교 함수가 구조적 동등을 판단하지 못함. + +## 다음 액션 + +1. `shallowEquals` 동작을 점검해 객체 비교 시 key 존재 여부 확인이 `b` 대상 객체를 직접 사용하도록 수정 필요. +2. memo 내부에서 props 비교 시, hooks 흐름상 ref가 초기화되고 이후에는 항상 값이 존재하도록 보장. +3. 테스트는 사용자가 직접 실행 예정 → 수정 후 로직 설명과 예상 결과만 공유. + +## 참고 + +- 실패 테스트: `src/__tests__/advanced.hoc.test.tsx` 48~50 라인. +- 현재 memo 구현 위치: `packages/react/src/hocs/memo.ts`. + + diff --git a/.cursor/mockdowns/react-implementation/09-click-event-issue-analysis.md b/.cursor/mockdowns/react-implementation/09-click-event-issue-analysis.md new file mode 100644 index 00000000..0cc0cff4 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/09-click-event-issue-analysis.md @@ -0,0 +1,199 @@ +# HomePage 클릭 이벤트 문제 분석 보고서 + +## 🔍 문제 상황 + +HomePage.jsx에서 ProductItem을 클릭하는 것 외에 다른 클릭 이벤트가 작동하지 않는 문제가 발생했습니다. + +## 📋 분석 결과 + +### 1. 발견된 주요 문제점 + +#### ❌ 문제 1: `setDomProps`에서 이벤트 리스너 중복 등록 + +**위치**: `packages/react/src/core/dom.ts:14-53` + +```typescript +export const setDomProps = (dom: HTMLElement, props: Record): void => { + // ... + if (key.startsWith("on") && typeof value === "function") { + const eventName = key.slice(2).toLowerCase(); + // ⚠️ 문제: 이전 리스너를 제거하지 않고 계속 추가만 함 + dom.addEventListener(eventName, value); + return; + } + // ... +}; +``` + +**문제점**: + +- `setDomProps`는 초기 마운트 시 호출되는 함수입니다. +- 이벤트 핸들러를 등록할 때 이전 리스너를 제거하지 않고 계속 추가만 합니다. +- 컴포넌트가 재렌더링될 때마다 같은 이벤트 핸들러가 중복으로 등록될 수 있습니다. +- 중복 등록된 리스너들이 모두 실행되면 예상치 못한 동작이 발생할 수 있습니다. + +**비교**: `updateDomProps`는 올바르게 구현되어 있습니다: + +```typescript +// 이벤트 핸들러 업데이트 +if (key.startsWith("on") && typeof nextValue === "function") { + const eventName = key.slice(2).toLowerCase(); + // ✅ 이전 핸들러가 있으면 제거 + if (typeof prevValue === "function") { + dom.removeEventListener(eventName, prevValue); + } + // ✅ 새로운 핸들러 등록 + dom.addEventListener(eventName, nextValue); + return; +} +``` + +#### ⚠️ 잠재적 문제 2: Router의 document 레벨 클릭 이벤트 리스너 + +**위치**: `packages/app/src/lib/Router.js:22-30` + +```javascript +document.addEventListener("click", (e) => { + if (e.target.closest("[data-link]")) { + e.preventDefault(); + const url = e.target.getAttribute("href") || e.target.closest("[data-link]").getAttribute("href"); + if (url) { + this.push(url); + } + } +}); +``` + +**분석**: + +- 이 리스너는 document 레벨에서 모든 클릭 이벤트를 캡처합니다. +- `[data-link]` 속성을 가진 요소에만 `preventDefault()`를 호출하므로, 다른 요소의 클릭 이벤트에는 직접적인 영향을 주지 않아야 합니다. +- 하지만 이벤트 버블링 단계에서 실행되므로, React의 이벤트 핸들러와 실행 순서가 다를 수 있습니다. + +### 2. 이벤트 처리 흐름 분석 + +#### React의 이벤트 등록 방식 + +1. **초기 마운트**: `setDomProps` 호출 → `addEventListener`로 이벤트 등록 +2. **업데이트**: `updateDomProps` 호출 → 이전 리스너 제거 후 새 리스너 등록 + +#### 실제 이벤트 실행 순서 + +1. 사용자가 요소를 클릭 +2. 브라우저가 네이티브 클릭 이벤트 발생 +3. **캡처 단계**: document → ... → target +4. **타겟 단계**: target 요소 +5. **버블링 단계**: target → ... → document +6. Router의 document 리스너가 버블링 단계에서 실행 (조건부로 `preventDefault()` 호출) +7. React의 이벤트 핸들러가 버블링 단계에서 실행 + +### 3. 영향받는 컴포넌트 + +#### ✅ 정상 작동하는 컴포넌트 + +- **ProductCard**: `onClick` 이벤트가 정상 작동 (사용자 보고) + +#### ❌ 작동하지 않는 컴포넌트 (추정) + +- **SearchBar**의 버튼들: + - `category1-filter-btn`: `handleMainCategoryClick` + - `category2-filter-btn`: `handleSubCategoryClick` + - 브레드크럼 버튼: `handleBreadCrumbClick` +- **ProductList**의 `retry-btn` +- **PageWrapper**의 `cart-icon-btn` + +### 4. 근본 원인 추정 + +#### 가장 가능성 높은 원인: `setDomProps`의 중복 리스너 등록 + +**시나리오**: + +1. 컴포넌트가 처음 마운트될 때 `setDomProps`가 호출되어 이벤트 리스너가 등록됩니다. +2. 컴포넌트가 재렌더링될 때마다 `setDomProps`가 다시 호출될 수 있습니다. +3. 이전 리스너를 제거하지 않고 새 리스너를 추가하면 중복 등록이 발생합니다. +4. 중복 등록된 리스너들이 모두 실행되면서 예상치 못한 동작이 발생할 수 있습니다. +5. 특히 이벤트 핸들러 내에서 `preventDefault()`를 호출하는 경우, 여러 번 호출되면서 다른 이벤트에 영향을 줄 수 있습니다. + +#### 추가 가능성: 이벤트 핸들러가 등록되지 않는 경우 + +- `setDomProps`가 재렌더링 시 호출되지 않아야 하는데 호출되는 경우 +- 이벤트 핸들러 함수가 매번 새로 생성되어 참조가 달라지는 경우 + +## 🔧 해결 방안 + +### 해결책 1: `setDomProps`에서 이벤트 리스너 중복 등록 방지 + +**방법 1**: 이전 리스너를 제거하고 새로 등록 + +```typescript +if (key.startsWith("on") && typeof value === "function") { + const eventName = key.slice(2).toLowerCase(); + // 이전 리스너 제거 (있다면) + // 주의: 이전 핸들러 참조를 저장해야 함 + dom.removeEventListener(eventName /* 이전 핸들러 */); + dom.addEventListener(eventName, value); + return; +} +``` + +**방법 2**: 이벤트 핸들러를 DOM 요소에 저장하여 관리 + +```typescript +// 이벤트 핸들러를 DOM 요소의 속성으로 저장 +const handlerKey = `__${key}Handler__`; +const prevHandler = (dom as any)[handlerKey]; + +if (prevHandler) { + dom.removeEventListener(eventName, prevHandler); +} + +dom.addEventListener(eventName, value); +(dom as any)[handlerKey] = value; +``` + +**방법 3**: `setDomProps`는 초기 마운트 시에만 사용하고, 업데이트는 `updateDomProps`만 사용 + +- `reconciler.ts`에서 마운트 시와 업데이트 시를 명확히 구분 +- 마운트 시: `setDomProps` 사용 +- 업데이트 시: `updateDomProps` 사용 (이미 올바르게 구현됨) + +### 해결책 2: Router의 이벤트 리스너 개선 + +현재 구현은 문제가 없어 보이지만, 더 명확하게 개선할 수 있습니다: + +```javascript +document.addEventListener( + "click", + (e) => { + const linkElement = e.target.closest("[data-link]"); + if (linkElement) { + e.preventDefault(); + e.stopPropagation(); // 명시적으로 버블링 중단 + const url = linkElement.getAttribute("href"); + if (url) { + this.push(url); + } + } + }, + true, +); // 캡처 단계에서 실행하여 React 이벤트보다 먼저 처리 +``` + +## 📊 우선순위 + +1. **높음**: `setDomProps`의 이벤트 리스너 중복 등록 문제 해결 +2. **중간**: Router의 이벤트 리스너 개선 (명시적 처리) +3. **낮음**: 이벤트 핸들러 참조 관리 개선 + +## 🧪 검증 방법 + +1. 브라우저 개발자 도구에서 이벤트 리스너 확인 + - Elements 탭 → 특정 요소 선택 → Event Listeners 탭에서 중복 등록 확인 +2. 이벤트 핸들러에 로그 추가하여 실행 횟수 확인 +3. `setDomProps`와 `updateDomProps` 호출 시점 확인 + +## 📝 참고 사항 + +- React의 실제 구현에서는 이벤트 위임(Event Delegation)을 사용하여 document 레벨에서 모든 이벤트를 처리합니다. +- 현재 Mini-React 구현은 각 요소에 직접 이벤트 리스너를 등록하는 방식입니다. +- 이는 실제 React와 다르지만, 더 단순한 구현입니다. diff --git a/.cursor/mockdowns/react-implementation/09-memo-rerender-issue.md b/.cursor/mockdowns/react-implementation/09-memo-rerender-issue.md new file mode 100644 index 00000000..c88d1763 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/09-memo-rerender-issue.md @@ -0,0 +1,280 @@ +# Memo HOC 리렌더링 문제 통합 문서 + +> **최종 업데이트**: 2025-01-19 +> **상태**: 진행 중 (path 문제 해결 중) + +## 📋 문제 상황 + +### 테스트 실패 +- **파일**: `packages/react/src/__tests__/advanced.hoc.test.tsx` +- **라인**: 48-50 +- **에러**: `expected "spy" to be called 1 times, but got 2 times` +- **시나리오**: 동일한 props `{ value: 1 }`로 `setState`를 호출했을 때, `TestComponent`가 2번 호출됨 (예상: 1번) + +### 테스트 코드 +```typescript +it("props로 전달하는 값이 변경되어야 리렌더링 된다.", async () => { + const MemoizedComponent = memo(TestComponent); + let rerender: ({ value }: { value: number }) => void; + + function TestWrapper() { + const [props, setProps] = useState({ value: 1 }); + rerender = setProps; + return ; + } + + const container = document.createElement("div"); + setup(, container); + await flushMicrotasks(); + expect(TestComponent).toHaveBeenCalledTimes(1); // ✅ 통과 + + // 동일한 값으로 setState - 메모이제이션으로 호출되지 않아야 함 + rerender!({ value: 1 }); // ❌ 여기서 실패 + await flushMicrotasks(); + expect(TestComponent).toHaveBeenCalledTimes(1); // 예상: 1, 실제: 2 +}); +``` + +## 🔍 원인 분석 과정 + +### 1단계: 초기 문제 분석 + +#### 문제 1: useRef 초기화 문제 +- `useRef(null)`로 초기화하여 `memoRef.current`가 `null`일 수 있음 +- **해결 시도**: 초기값을 객체로 변경 `useRef({ prevProps: null, prevResult: null })` + +#### 문제 2: memoRef.current 접근 에러 +- **에러**: `Cannot read properties of undefined (reading 'prevProps')` +- **증상**: 무한 로딩 발생 +- **해결 시도**: 방어 로직 추가 및 `context` import 추가 + +#### 문제 3: 객체 할당 vs 속성 수정 +- `memoRef.current = { ... }` 방식이 문제일 수 있음 +- **해결 시도**: 속성 직접 수정으로 변경 → 여전히 문제 발생 + +### 2단계: 로그 분석 결과 + +#### 현재 로그 출력 +``` +[memo] useRef 호출: { + memoRef: { value: 1 }, + memoRefCurrent: undefined, + prevProps: undefined, + currentPath: 'root', + currentCursor: 1 +} +[memo] memoRef.current가 undefined - 초기화 +[memo] 첫 렌더링 +[memo] 컴포넌트 실행 +[memo] 저장 완료: { + prevProps: { value: 1 }, + prevResult: { ... } +} +``` + +**핵심 발견**: +1. `memoRef.current`가 매번 `undefined`로 초기화되고 있습니다. +2. `currentPath: 'root'` - path가 항상 'root'로 나옵니다. 이것은 문제입니다! +3. `memo` 컴포넌트는 `TestWrapper`의 자식이므로 더 구체적인 path를 가져야 합니다. + +### 3단계: 근본 원인 추정 + +#### 문제: memo 컴포넌트의 path가 잘못 설정됨 + +**핵심 문제**: `memo` 컴포넌트가 렌더링될 때 path가 'root'로 나오는 것은 `memo` 컴포넌트가 `TestWrapper`의 자식으로 렌더링되는데, path가 제대로 설정되지 않았다는 의미입니다. + +**가능한 원인들**: + +1. **mountNode에서 path 전달 문제** + - `mountNode`에서 함수형 컴포넌트를 처리할 때 `renderFunctionComponent`에 `path`를 전달 + - 하지만 `memo` 컴포넌트의 경우 부모의 path를 기반으로 새로운 path를 생성해야 함 + - 현재는 부모의 path를 그대로 사용하고 있어서 문제가 발생할 수 있음 + +2. **renderFunctionComponent의 path 사용 문제** + - `renderFunctionComponent`는 전달받은 `path`를 `componentStack`에 push + - 이때 `path`가 `memo` 컴포넌트의 path가 아니라 부모의 path일 수 있음 + - `memo` 컴포넌트 내부에서 `useRef`를 호출할 때 `currentPath`가 'root'로 나오는 것은 `componentStack`의 마지막 요소가 'root'라는 의미 + +3. **useRef의 상태 유지 실패** + - `useRef`는 `useState`를 사용하여 path와 cursor를 기반으로 상태를 저장 + - path가 'root'로 나오면 `memo` 컴포넌트의 상태가 제대로 격리되지 않음 + - 매번 새로운 상태를 생성하게 되어 `memoRef.current`가 `undefined`로 초기화됨 + +## 🔧 현재 구현 상태 + +### memo.ts 현재 코드 +```typescript +import { useRef } from "../hooks"; +import { type FunctionComponent } from "../core"; +import { shallowEquals } from "../utils"; +import { context } from "../core/context"; + +export function memo

(Component: FunctionComponent

, equals = shallowEquals) { + const MemoizedComponent: FunctionComponent

= (props) => { + type MemoState = { + prevProps: P | null; + prevResult: ReturnType> | null; + }; + + const memoRef = useRef({ + prevProps: null, + prevResult: null, + }); + + // 디버깅: path와 cursor 확인 + const currentPath = context.hooks?.currentPath; + const currentCursor = context.hooks?.currentCursor; + + console.log("[memo] useRef 호출:", { + memoRef, + memoRefCurrent: memoRef.current, + prevProps: memoRef.current?.prevProps, + currentPath, + currentCursor, + }); + + // 방어 로직 + if (!memoRef.current) { + console.log("[memo] memoRef.current가 undefined - 초기화"); + memoRef.current = { + prevProps: null, + prevResult: null, + }; + } + + // props 비교 + if (memoRef.current.prevProps !== null) { + const isEqual = equals(memoRef.current.prevProps, props); + console.log("[memo] 비교:", { + prevProps: memoRef.current.prevProps, + newProps: props, + isEqual, + }); + if (isEqual) { + console.log("[memo] 재사용"); + return memoRef.current.prevResult; + } + } else { + console.log("[memo] 첫 렌더링"); + } + + // 컴포넌트 실행 및 저장 + console.log("[memo] 컴포넌트 실행"); + const result = Component(props); + memoRef.current = { + prevProps: props, + prevResult: result, + }; + console.log("[memo] 저장 완료:", memoRef.current); + + return result; + }; + + MemoizedComponent.displayName = `Memo(${Component.displayName || Component.name})`; + return MemoizedComponent; +} +``` + +### reconciler.ts 관련 코드 + +#### mountNode 함수 +```typescript +// 4) 함수형 컴포넌트 처리 +if (typeof node.type === "function") { + const componentVNode = renderFunctionComponent(node.type, node.props, path); + const childInstance = reconcile(parentDom, null, componentVNode, path); + // ... +} +``` + +#### renderFunctionComponent 함수 +```typescript +function renderFunctionComponent( + component: (props: VNode["props"]) => VNode | null, + props: VNode["props"], + path: string, +): VNode | null { + context.hooks.componentStack.push(path); + context.hooks.visited.add(path); + context.hooks.cursor.set(path, 0); + // ... + try { + return component(props); + } finally { + context.hooks.componentStack.pop(); + } +} +``` + +## 🎯 해결 방안 + +### 핵심 문제: path가 'root'로 나오는 이유 + +`memo` 컴포넌트가 `TestWrapper`의 자식으로 렌더링되는데, path가 'root'로 나오는 것은 `renderFunctionComponent`가 호출될 때 전달받은 `path`가 'root'라는 의미입니다. + +**문제 분석**: +1. `TestWrapper`가 렌더링될 때 path는 'root.0' 같은 형태여야 함 +2. `memo` 컴포넌트가 `TestWrapper`의 자식으로 렌더링될 때 path는 'root.0.0' 같은 형태여야 함 +3. 하지만 로그에서는 `currentPath: 'root'`로 나오므로, `memo` 컴포넌트가 렌더링될 때 `componentStack`의 마지막 요소가 'root'임 + +**가능한 원인**: +- `mountNode`에서 함수형 컴포넌트를 처리할 때 `renderFunctionComponent`에 부모의 path를 전달하는데, 이 path가 'root'일 수 있음 +- 또는 `memo` 컴포넌트가 렌더링될 때 `componentStack`이 제대로 설정되지 않았을 수 있음 + +### 해결 방안 + +1. **path 생성 로직 확인** + - `memo` 컴포넌트가 렌더링될 때 올바른 path가 생성되는지 확인 + - `mountNode`에서 함수형 컴포넌트를 처리할 때 path가 제대로 전달되는지 확인 + +2. **renderFunctionComponent의 path 사용 확인** + - `renderFunctionComponent`가 전달받은 `path`를 `componentStack`에 push하는 것이 맞는지 확인 + - `memo` 컴포넌트의 경우 부모의 path를 기반으로 새로운 path를 생성해야 할 수도 있음 + +3. **useRef의 상태 유지 확인** + - path가 올바르게 설정되면 `useRef`의 상태가 제대로 유지될 것 + - 같은 path와 cursor에서 호출되면 같은 상태를 반환해야 함 + +## 📝 관련 파일 + +- **구현 파일**: `packages/react/src/hocs/memo.ts` +- **테스트 파일**: `packages/react/src/__tests__/advanced.hoc.test.tsx` +- **의존성 파일**: + - `packages/react/src/hooks/useRef.ts` - useRef 구현 + - `packages/react/src/utils/equals.ts` - shallowEquals 구현 + - `packages/react/src/core/reconciler.ts` - reconciler 구현 + - `packages/react/src/core/hooks.ts` - useState 구현 + - `packages/react/src/core/context.ts` - context 구현 + - `packages/react/src/core/elements.ts` - createChildPath 구현 + +## 📌 핵심 이슈 + +### path가 'root'로 나오는 문제 + +**현상**: `memo` 컴포넌트가 렌더링될 때 `currentPath: 'root'`로 나옴 + +**원인 추정**: +1. `mountNode`에서 함수형 컴포넌트를 처리할 때 path가 제대로 전달되지 않음 +2. `renderFunctionComponent`가 호출될 때 전달받은 path가 'root'임 +3. `memo` 컴포넌트가 `TestWrapper`의 자식으로 렌더링되는데, path가 제대로 설정되지 않음 + +**확인 필요 사항**: +- `TestWrapper`가 렌더링될 때 path는 무엇인가? +- `memo` 컴포넌트가 렌더링될 때 전달되는 path는 무엇인가? +- `renderFunctionComponent`가 호출될 때 `componentStack`의 상태는 무엇인가? + +## 🚀 다음 작업 + +1. **path 생성 로직 확인**: `memo` 컴포넌트가 렌더링될 때 올바른 path가 생성되는지 확인 +2. **renderFunctionComponent 확인**: path가 제대로 전달되고 `componentStack`에 push되는지 확인 +3. **useRef 상태 유지 확인**: path가 올바르게 설정되면 `useRef`의 상태가 제대로 유지되는지 확인 +4. **테스트 검증**: 수정 후 테스트 실행하여 검증 +5. **디버깅 로그 제거**: 문제 해결 후 디버깅 로그 제거 + +## 📌 변경 이력 + +- **2025-01-19**: 초기 문제 분석 및 여러 해결 시도 +- **2025-01-19**: 로그 분석 결과 `memoRef.current`가 매번 `undefined`로 초기화되는 문제 발견 +- **2025-01-19**: Path와 cursor 로그 추가하여 근본 원인 파악 진행 중 +- **2025-01-19**: `context is not defined` 에러 해결 - `memo.ts`에 `context` import 추가 +- **2025-01-19**: 로그 분석 결과 `currentPath: 'root'`로 나오는 문제 발견 - path 생성 로직 확인 필요 diff --git a/.cursor/mockdowns/react-implementation/10_function-component-path-fix.md b/.cursor/mockdowns/react-implementation/10_function-component-path-fix.md new file mode 100644 index 00000000..36833455 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/10_function-component-path-fix.md @@ -0,0 +1,94 @@ +# 10. `memo` HOC 버그 및 함수형 컴포넌트 경로 문제 해결 + +> **목표**: `memo` HOC가 오작동하던 버그의 근본 원인인 함수형 컴포넌트의 경로(path) 문제를 해결하고, 그 과정을 기록합니다. + +--- + +### 1. 문제 요약 (Problem Summary) + +`memo`로 감싼 컴포넌트에 동일한 내용의 props가 전달되어도 불필요한 리렌더링이 발생하는 문제가 있었습니다. 이로 인해 `advanced.hoc.test.tsx`의 `toHaveBeenCalledTimes(1)` 테스트가 `2`번 호출되어 실패했습니다. + +이는 `memo` HOC가 내부적으로 사용하는 `useRef` 훅이 렌더링 간에 상태를 보존하지 못했기 때문입니다. + +### 2. 근본 원인 분석 (Root Cause Analysis) + +1. **1차 가설**: `useRef` 또는 `useState`의 구현 자체에 결함이 있을 것이다. + - **분석**: `useRef`와 `useState`의 코드를 분석한 결과, 훅 자체의 로직은 `path`와 `cursor`를 기반으로 상태를 저장하고 조회하는 올바른 구조였습니다. + +2. **2차 가설**: 훅의 `cursor`가 리렌더링 시 초기화되지 않을 것이다. + - **분석**: `reconciler.ts`를 분석한 결과, `renderFunctionComponent` 함수 내부에 `context.hooks.cursor.set(path, 0)` 코드가 존재하여, 함수형 컴포넌트가 렌더링되기 직전에 `cursor`를 `0`으로 리셋하고 있음을 확인했습니다. 이 가설은 틀렸습니다. + +3. **최종 결론: 경로(Path) 충돌**: + - **결정적 단서**: `reconciler.ts`의 `reconcile` (업데이트 시) 및 `mountNode` (마운트 시) 함수 모두, 함수형 컴포넌트가 반환한 **자식 VNode**를 `reconcile` 할 때, **부모 컴포넌트의 경로를 그대로 전달**하고 있었습니다. + + ```typescript + // 버그 발생 코드 + const componentVNode = renderFunctionComponent(node.type, node.props, path); + // 자식(componentVNode)에게 부모의 path를 그대로 전달하고 있음 + const childInstance = reconcile(parentDom, null, componentVNode, path); + ``` + + - **영향**: 이로 인해 부모 컴포넌트와 자식 컴포넌트가 동일한 `path`를 공유하게 됩니다. 훅 시스템은 `path`와 `cursor`로 상태를 관리하므로, 서로 다른 컴포넌트의 훅 상태가 충돌하고, 의도치 않게 덮어쓰여 상태 보존에 실패하게 된 것입니다. `memo` HOC의 `useRef`가 상태를 잃어버린 것도 바로 이 때문입니다. + +--- + +### 3. 수정 내역 (Changes Made) + +함수형 컴포넌트의 자식이 부모와 독립된 고유한 경로를 갖도록 `reconciler.ts`의 두 부분을 수정했습니다. + +#### 1. 컴포넌트 업데이트 로직 수정 (`reconcile` 함수) + +- **파일**: `packages/react/src/core/reconciler.ts` +- **수정 전**: + ```typescript + // 중요: 자식 인스턴스가 업데이트될 때도 같은 path를 사용해야 훅 상태가 올바르게 유지됩니다 + const childInstance = reconcile(childParentDom, existingChildInstance || null, componentVNode, componentPath); + + instance.node = nextNode; + instance.children = childInstance ? [childInstance] : []; + ``` +- **수정 후**: `createChildPath`를 사용하여 자식의 고유 경로를 생성하도록 변경했습니다. + ```typescript + // 중요: 자식 인스턴스가 업데이트될 때도 같은 path를 사용해야 훅 상태가 올바르게 유지됩니다 + let childInstance: Instance | null = null; + if (componentVNode) { + // The rendered child needs its own path, derived from the component's path. + // A function component has a single child, so its index is effectively 0. + const childPath = createChildPath(componentPath, componentVNode.key ?? null, 0); + childInstance = reconcile(childParentDom, existingChildInstance || null, componentVNode, childPath); + } else { + // If the component returns null, unmount the existing child. + childInstance = reconcile(childParentDom, existingChildInstance || null, null, componentPath); // path doesn't matter much for unmount + } + + instance.node = nextNode; + instance.children = childInstance ? [childInstance] : []; + ``` + +#### 2. 컴포넌트 마운트 로직 수정 (`mountNode` 함수) + +- **파일**: `packages/react/src/core/reconciler.ts` +- **수정 전**: + ```typescript + const componentVNode = renderFunctionComponent(node.type, node.props, path); + const childInstance = reconcile(parentDom, null, componentVNode, path); + ``` +- **수정 후**: 업데이트 시와 동일하게, `createChildPath`를 사용하여 자식의 고유 경로를 생성하도록 변경했습니다. + ```typescript + const componentVNode = renderFunctionComponent(node.type, node.props, path); + + let childInstance: Instance | null = null; + if (componentVNode) { + const childPath = createChildPath(path, componentVNode.key ?? null, 0); + childInstance = reconcile(parentDom, null, componentVNode, childPath); + } + ``` + +--- + +### 4. 기대 효과 (Expected Outcome) + +- 이제 모든 컴포넌트는 트리 구조에 따라 고유한 경로를 부여받습니다. +- 부모와 자식 간의 훅 상태 충돌이 사라져, `useRef`와 `useState`가 렌더링 간에 상태를 올바르게 보존합니다. +- `memo` HOC가 정상적으로 동작하여, 동일한 props에 대한 불필요한 리렌더링을 방지합니다. +- `advanced.hoc.test.tsx`의 관련 테스트가 성공적으로 통과할 것입니다. diff --git a/.cursor/mockdowns/react-implementation/11_event-handling-issue-analysis.md b/.cursor/mockdowns/react-implementation/11_event-handling-issue-analysis.md new file mode 100644 index 00000000..107a9fd5 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/11_event-handling-issue-analysis.md @@ -0,0 +1,57 @@ +# Event Handling System Analysis and Fix + +## 1. 문제 상황 + +애플리케이션 전체에서 `onClick`, `onKeyDown`, `onChange` 등 모든 DOM 이벤트 핸들러가 동작하지 않습니다. 브라우저 개발자 도구의 콘솔에는 아무런 에러 메시지도 출력되지 않아 디버깅이 어려운 상황입니다. + +## 2. 원인 분석 + +핵심 파일을 분석한 결과, 문제의 원인은 커스텀 React의 이벤트 시스템 초기화 로직이 누락되었기 때문입니다. + +### `events.ts` - 이벤트 위임 시스템 + +- 우리 React는 **이벤트 위임(Event Delegation)** 패턴을 사용합니다. +- `addEventHandler` 함수는 실제 DOM 요소에 `addEventListener`를 호출하는 대신, 핸들러를 `elementEventStore`(WeakMap)에 저장합니다. +- 각 이벤트 타입(`click`, `keydown` 등)에 대한 단일 리스너가 **`rootContainer`** 라는 최상위 DOM 요소에 한 번만 부착됩니다. +- 이 `rootContainer`는 `setEventRoot(container)` 함수를 통해 반드시 설정되어야 합니다. + +### `dom.ts` - 속성 설정 로직 + +- `setDomProps`와 `updateDomProps` 함수는 `on`으로 시작하는 속성을 이벤트 핸들러로 올바르게 식별합니다. +- 식별된 핸들러는 `events.ts`의 `addEventHandler`로 전달됩니다. +- 이 부분은 정상적으로 동작하여, 메모리상의 `elementEventStore`에는 핸들러가 잘 등록되고 있습니다. + +### `render.ts` - 렌더링 로직 (문제의 핵심) + +- 애플리케이션 렌더링의 시작점인 `render` 함수를 확인한 결과, **`setEventRoot`를 호출하는 코드가 누락**되어 있었습니다. +- `rootContainer`가 설정되지 않았기 때문에, `events.ts`의 리스너 부착 로직(`rootContainer.addEventListener(...)`)이 실행되지 않았습니다. +- 결론적으로, 핸들러는 메모리에 등록되었지만 어떤 이벤트도 실제로 수신 대기하고 있지 않은 상태가 된 것입니다. + +## 3. 근본 원인 + +**`render` 함수에서 `setEventRoot`를 호출하여 이벤트 시스템의 루트 컨테이너를 설정하는 초기화 코드가 누락된 것**이 모든 이벤트가 동작하지 않는 문제의 근본 원인입니다. + +## 4. 해결 방안 제안 + +`packages/react/src/core/render.ts`의 `render` 함수 상단에 `setEventRoot`를 호출하는 로직을 추가합니다. 이 함수는 최초 렌더링 시 한 번만 실행되면 되므로, 이미 설정되었는지 확인하는 간단한 가드를 추가하여 중복 실행을 방지합니다. + +```typescript +// packages/react/src/core/render.ts + +import { setEventRoot } from "./events"; // 추가 + +// ... + +export const render = (): void => { + const root = context.root; + if (!root.container || !root.node) return; + + // 이벤트 루트가 설정되지 않았을 경우, 최초 한 번만 설정 + if (!context.eventRoot) { + setEventRoot(root.container); + context.eventRoot = root.container; // context에 플래그 저장 + } + + // ... (이하 기존 코드) +}; +``` diff --git a/.cursor/mockdowns/react-implementation/12_reconciliation-logic-flaw-analysis.md b/.cursor/mockdowns/react-implementation/12_reconciliation-logic-flaw-analysis.md new file mode 100644 index 00000000..03f9f529 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/12_reconciliation-logic-flaw-analysis.md @@ -0,0 +1,57 @@ +# Reconciliation Logic Flaw Analysis and Fix + +## 1. 문제 상황 + +이전 이벤트 핸들러 등록 문제 해결 후에도 아래와 같은 기능들이 여전히 동작하지 않음: +- E2E 테스트에서 검색창 입력 오류 발생 +- 무한 스크롤 기능 미작동 +- 헤더의 카트 버튼 클릭 시 모달창이 뜨지 않음 + +이는 상태 변경 후 UI가 올바르게 업데이트되지 않는, 즉 리렌더링 과정에 더 깊은 문제가 있음을 시사합니다. + +## 2. 원인 분석 (`codebase_investigator` 결과) + +`codebase_investigator`를 통해 분석한 결과, 문제의 핵심은 `packages/react/src/core/reconciler.ts`의 **함수형 컴포넌트(Function Component) 재조정 로직**에 있었습니다. + +전체 업데이트 흐름은 다음과 같습니다. +1. **이벤트 발생 및 상태 업데이트**: `useState`의 setter가 호출되면 상태가 변경되고, `enqueueRender`가 정상적으로 호출되어 렌더링을 스케줄링합니다. (정상) +2. **렌더링 시작**: `render` 함수가 `reconcile` 함수를 호출하여 루트부터 재조정을 시작합니다. (정상) +3. **재조정 로직 (문제 발생)**: + - `reconcile` 함수가 업데이트할 노드 타입이 `function`인 경우(즉, 함수형 컴포넌트일 때) 로직에 결함이 있습니다. + - **현재 로직**: 함수형 컴포넌트를 **먼저 실행**(`renderFunctionComponent`)하여 새로운 자식 VNode를 얻고, 이 VNode를 이전 인스턴스와 재조정하려고 시도합니다. + - **문제점**: 이 방식은 부모가 리렌더링되어도 자식 컴포넌트의 함수 자체를 다시 실행하는 과정을 건너뛰게 만듭니다. 재조정기는 '컴포넌트'가 아닌, 컴포넌트가 반환한 'DOM 엘리먼트 VNode'를 비교하게 되므로, props가 바뀌지 않는 한 아무런 변화가 없다고 판단하여 자식 컴포넌트의 업데이트를 생략합니다. + +## 3. 근본 원인 + +**`reconcile` 함수가 함수형 컴포넌트를 처리할 때, 컴포넌트 함수를 다시 실행하고 그 결과를 이전 자식 인스턴스와 비교하는 대신, 잘못된 순서로 로직을 처리하여 하위 컴포넌트 트리의 업데이트를 누락시키는 것**이 근본 원인입니다. + +## 4. 해결 방안 제안 + +`packages/react/src/core/reconciler.ts`의 `reconcile` 함수 내 `if (typeof nextNode.type === 'function')` 블록의 로직을 수정합니다. + +새로운 로직은 다음과 같은 순서로 동작해야 합니다. +1. 기존 인스턴스와 타입이 같은지 확인합니다. (`instance?.type === nextNode.type`) +2. 만약 타입이 같다면, 해당 컴포넌트의 **이전 자식 인스턴스(`instance.children[0]`)**와 컴포넌트를 **새롭게 렌더링한 결과(`renderFunctionComponent(nextNode, instance, path)`)**를 재귀적으로 `reconcile` 해야 합니다. +3. 타입이 다르다면, 완전히 새로운 컴포넌트이므로 새롭게 렌더링하고 DOM에 삽입합니다. + +이 수정을 통해 부모의 상태 변경이 자식 컴포넌트의 재실행 및 연쇄적인 리렌더링으로 올바르게 이어지게 할 수 있습니다. + +--- + +## 5. 2차 분석: 런타임 오류 지속 + +### 문제 상황 + +- `reconciler.ts` 수정 후 `pnpm test`는 모두 통과했습니다. +- 하지만 `pnpm run dev`로 앱을 실행하면 여전히 기능이 동작하지 않습니다. + +### 새로운 가설 + +단위 테스트 환경(JSDOM 등)과 실제 브라우저 런타임 환경의 차이로 인해 발생하는 문제로 추정됩니다. 특히, 재조정 로직이 실제 애플리케이션의 복잡한 **중첩 컴포넌트 구조**를 만났을 때, **자식에게 전달할 부모 DOM(`parentDom`)을 잘못 추적**하고 있을 가능성이 높습니다. + +- **가설**: 함수형 컴포넌트는 자체 DOM이 없습니다. 따라서 그 자식 컴포넌트를 재조정할 때, 부모로부터 `parentDom`을 올바르게 물려받아야 합니다. 현재 로직은 이 `parentDom`을 전달하는 과정에 결함이 있어, 메모리상에서는 VDOM이 올바르게 생성되지만 실제 DOM 트리에는 삽입/반영되지 못하는 것입니다. + +### 다음 단계 + +1. 수정된 `reconciler.ts`의 함수 컴포넌트 재조정 로직을 다시 검토하여 `parentDom` 전달 과정을 집중적으로 분석합니다. +2. 실제 앱의 컴포넌트 구조(`HomePage.jsx`)를 확인하여 가설을 검증합니다. \ No newline at end of file diff --git a/.cursor/mockdowns/react-implementation/13_event-and-reconcile-log-analysis.md b/.cursor/mockdowns/react-implementation/13_event-and-reconcile-log-analysis.md new file mode 100644 index 00000000..13f61f09 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/13_event-and-reconcile-log-analysis.md @@ -0,0 +1,65 @@ +# 이벤트 시스템 & 재조정 로그 분석 보고서 + +## 1. 로그로 확인한 사실 + +- `consolechk.md`의 `reconciler.ts` 로그를 보면 동일한 함수형 컴포넌트 경로(`root.0.0.0.1.*`)가 첫 렌더 이후에도 계속 `decision: mount`로 남아 있습니다. 즉, 부모가 상태를 갱신해도 자식 함수형 컴포넌트가 **업데이트 단계**로 진입하지 못하고 매번 새로 마운트되고 있습니다. + +``` +```133:152:.cursor/mockdowns/consolechk.md +reconciler.ts:33 [reconcile] path: root.0.0.0.1 type: string ... decision: update path: root.0.0.0.1 +reconciler.ts:33 [reconcile] path: root.0.0.0.1.0 type: function ... decision: update path: root.0.0.0.1.0 +reconciler.ts:33 [reconcile] path: root.0.0.0.1.0.0 type: string ... decision: update path: root.0.0.0.1.0.0 +reconciler.ts:33 [reconcile] path: root.0.0.0.1.0.0.0 ... decision: update path: root.0.0.0.1.0.0.0 +reconciler.ts:33 [reconcile] path: root.0.0.0.1.0.0.1 ... decision: update path: root.0.0.0.1.0.0.1 +reconciler.ts:33 [reconcile] path: root.0.0.0.1.0.0.1.0 ... decision: update path: root.0.0.0.1.0.0.1.0 +reconciler.ts:33 [reconcile] path: root.0.0.0.1.0.0.1.0.1 type: string ... decision: mount path: root.0.0.0.1.0.0.1.0.1 +``` +``` + +- `localhost-1763633857912.md`의 `insertInstance` 로그에서는 **동일한 DOM 컨테이너에 다시 렌더링할 때 `parentDom`이 비어 있는 상태**로 출력됩니다. 실제 브라우저 로그에서는 `parentDom`에 해당 DOM 객체가 별도 컬럼으로 찍히지만, 텍스트로 떨어진 로그에는 값이 빠져 있습니다. 즉, 함수형 컴포넌트가 기존 자식 DOM을 모두 치운 뒤 새 자식을 삽입하려고 했지만, 연결해야 할 부모 DOM을 잃어버린 상태라는 것을 확인할 수 있습니다. + +``` +```120:135:.cursor/mockdowns/localhost-1763633857912.md + [insertInstance] instance kind : text parentDom: domNodes to insert: [text] + [insertInstance] instance kind : host parentDom: domNodes to insert: [button.category1-filter-btn...] + [insertInstance] instance kind : text parentDom: domNodes to insert: [text] + [insertInstance] instance kind : host parentDom: domNodes to insert: [button.category1-filter-btn...] + ... +``` +``` + +## 2. 근본 원인 + +### 2.1 이벤트 시스템 초기화 누락 + +- `events.ts`는 이벤트 위임용 전역 리스너를 `rootContainer`에 부착해야 정상 동작합니다. 그러나 `render` 진입 시점에 `setEventRoot`를 호출하지 않아 `rootContainer`가 `null`로 남고, 위임 리스너가 한 번도 연결되지 않은 상태입니다. 그 결과, `addEventHandler`가 저장해둔 핸들러가 실제 브라우저 이벤트를 받을 기회가 없어 모든 `onClick`, `onChange` 계열 이벤트가 무력화되었습니다. + +### 2.2 함수형 컴포넌트 재조정 순서 오류 + +- `reconciler.ts`의 함수형 컴포넌트 분기에서 **새로운 VNode를 먼저 렌더링**한 뒤 이전 인스턴스와 비교하려고 합니다. 이때 부모 DOM을 인자로 전달하지 못하면 자식 인스턴스를 다시 DOM에 삽입할 위치를 잃어버립니다. +- 실제 로그처럼 부모 DOM 참조가 사라지면 `insertInstance`가 `parentDom` 없이 호출되고, 브라우저 콘솔에는 값이 비어 보입니다. 구현체에서는 `parentDom.appendChild` 호출 직전에 예외가 발생하고, 해당 렌더 패스가 조용히 실패하면서 UI가 갱신되지 않습니다. + +## 3. 해결 방안 + +1. **`setEventRoot` 보장 호출** + - `packages/react/src/core/render.ts` 혹은 `setup.ts`에서 루트 컨테이너가 준비되는 즉시 `setEventRoot(container)` 호출. + - 중복 호출을 막기 위해 `context.eventRoot`에 컨테이너를 캐시하여 이미 설정된 경우 스킵. + +2. **함수형 컴포넌트 재조정 순서 수정** + - `reconciler.ts` 함수형 컴포넌트 분기에서 `instance.node.type === nextNode.type`인 경우에만 업데이트 루틴으로 진입. + - 업데이트 루틴에서는 + 1. `renderFunctionComponent`로 새 VNode 생성 + 2. 이전 자식 인스턴스와 새 VNode를 `reconcile(childParentDom, prevChild, nextChild, childPath)`에 전달 + 3. `childParentDom`은 우선 이전 자식의 실제 DOM 부모(`getFirstDomFromChildren`)를 사용하고, 없으면 상위에서 받은 `parentDom`을 그대로 사용 + - 이렇게 하면 부모 DOM 참조가 끊기지 않아 `insertInstance`가 항상 유효한 `parentDom`을 받게 됩니다. + +3. **디버깅 가드 추가 (선택)** + - 개발 환경에서 `insertInstance` 호출 시 `if (!parentDom)` 분기에서 콘솔 경고를 띄우면, 추후 비슷한 회귀를 빠르게 감지할 수 있습니다. + +## 4. 다음 조치 + +- [ ] `render.ts`에 `setEventRoot` 호출/가드 추가 +- [ ] `reconciler.ts` 함수형 컴포넌트 분기 재작성 +- [ ] 수정 후 `SearchBar`, `ProductList`, `CartModal` 상호작용 수동 검증 +- [ ] 사용자에게 테스트 실행 요청 (`pnpm test`, `pnpm run dev`) + diff --git a/.cursor/mockdowns/react-implementation/14_event-system-debugging-plan.md b/.cursor/mockdowns/react-implementation/14_event-system-debugging-plan.md new file mode 100644 index 00000000..195d71a4 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/14_event-system-debugging-plan.md @@ -0,0 +1,104 @@ +# React 스타일 이벤트 시스템 전환 계획 + +## 1. 목표 + +- 현재 커스텀 React 구현의 이벤트 시스템을 **React DOM**과 동일한 철학/흐름으로 재구성 +- 추후 `react-dom`으로 교체해도 사용자 코드 변경 없이 동작하도록 준비 +- 브라우저 환경에서도 단위 테스트와 동일하게 안정적으로 이벤트가 동작하도록 보장 + +## 2. React DOM이 따르는 핵심 원칙 + +1. **createRoot 시점 단일 등록** + `ReactDOM.createRoot(container)`가 호출되면 해당 컨테이너를 이벤트 시스템에 등록하고, 이후 `root.render`는 이벤트 루트를 다시 만지지 않음. + +2. **이벤트 타입 전역 레지스트리** + 이벤트 타입이 처음 필요할 때만 네이티브 리스너를 붙이고, 이후에는 재사용. (ex. `allNativeEvents`) + +3. **Synthetic Event 디스패치 파이프라인** + 네이티브 이벤트 → Synthetic Event로 래핑 → Fiber 트리를 따라 일관된 순서로 핸들러 실행. + +## 3. 현재 시스템의 문제 지점 + +| 항목 | 현재 동작 | React DOM과의 차이 | +| --- | --- | --- | +| 이벤트 루트 설정 | `setup`/`render` 단계에서 매번 `setEventRoot` 호출 | `createRoot`에서 한 번만 설정 | +| 리스너 부착 시점 | `setEventRoot` 시점에 `delegatedListeners`가 비어있어 아무것도 붙지 않음 | `listenToNativeEvent`가 이벤트 타입 등록과 동시에 루트에 부착 | +| 전역 레지스트리 | `delegatedListeners`만 존재, 이벤트 타입과 루트 사이 관계 관리 X | 이벤트 타입별로 어떤 루트에 리스너가 붙었는지 추적 | +| Synthetic Event | 네이티브 이벤트 직접 호출 | Synthetic Event 래핑 없음 | + +## 4. 단계별 전환 계획 + +### 4.1 루트 라이프사이클 재정의 +- `packages/react/src/client/index.ts` (`createRoot`) + - `setEventRoot(container)` 호출 책임을 `createRoot`로 이동 + - `context.eventRoot = container` 저장 (React DOM과 동일) +- `setup`/`render`에서는 `eventRoot`를 **읽기만** 하도록 정리 (중복 설정 제거) + +### 4.2 전역 이벤트 레지스트리 도입 +- `events.ts`에 다음 구조 도입 + - `const registeredEvents = new Set();` + - `const rootListeners = new Map>();` +- `addEventHandler` → `registerEvent(eventName)` 호출 + - 새 이벤트 타입이면 `listenToNativeEvent(eventName, rootContainer)` 실행 + - 이미 등록된 경우 skip + +### 4.3 listenToNativeEvent 유틸 구현 +- React의 `listenToNativeEvent`를 참고해 다음 역할 수행 + 1. 이벤트 타입별 capture/bubble 핸들러 생성 + 2. 지정된 루트 컨테이너에 addEventListener 두 번 (capture/bubble) + 3. `rootListeners` 맵에 저장해 나중에 detach 가능하게 함 +- 기존 `ensureDelegatedListener` + `attachToContainer` 로직을 이 함수로 대체 + +### 4.4 루트 변경/파괴 대응 +- 새 루트가 등록되면 이전 루트에서 모든 이벤트 제거 (`rootListeners` 참조) +- `createRoot(root).unmount()` 또는 `router` 교체 시 루트 단위로 detach (React DOM과 동일 패턴) + +### 4.5 Synthetic Event 스텁 추가 (선택) +- `packages/react/src/core/events.ts`에 `createSyntheticEvent` 헬퍼 추가 +- `dispatchEvent`에서 네이티브 이벤트를 래핑하여 추후 React DOM drop-in 시 호환성 확보 +- 초기 버전에서는 최소 필드(`target`, `currentTarget`, `nativeEvent`, `preventDefault`)만 구현하고, 확장 가능하도록 설계 + +## 5. 구현 순서 + +1. `createRoot`에서 이벤트 루트 설정 책임 이관 +2. `listenToNativeEvent` 도입 및 기존 `ensureDelegatedListener` 리팩터링 +3. `registerEvent` 경로 정리 (`setDomProps`/`updateDomProps` → `addEventHandler` → `registerEvent`) +4. Synthetic Event 스텁 추가 (옵션) +5. 다중 루트나 루트 재설정 시나리오 테스트 + +## 6. 검증 플랜 + +- **단위 테스트**: 기존 테스트 유지 + 이벤트 시스템 전용 테스트 추가 (루트 교체, 이벤트 중복 등록 방지 등) +- **수동 검증**: SearchBar / ProductList / CartModal 등 실제 UI 상호작용 확인 +- **React DOM 호환 수용력**: `createRoot`/`render`/이벤트 등록 시그니처가 React와 동일한지 체크, drop-in 체크리스트 작성 + +## 7. TODO 체크리스트 +- [x] `createRoot`에서 `setEventRoot` 단 한 번 호출하도록 수정 +- [x] `listenToNativeEvent` / `registerEvent` 리팩터링 +- [x] `rootListeners`/`registeredEvents` 전역 상태 관리 +- [x] Synthetic Event 스텁 도입 (JSDOM 호환성 고려) +- [ ] 브라우저/단위 테스트로 회귀 검증 + +## 8. 구현 완료 상태 + +### 완료된 작업 (2024-12-XX) + +1. **이벤트 루트 설정 책임 이관** + - `createRoot`에서 `setEventRoot` 호출 + - `setup`에서 테스트 호환성을 위한 조건부 설정 + +2. **전역 이벤트 레지스트리 도입** + - `registeredEvents`: 등록된 이벤트 타입 추적 + - `rootListeners`: 루트 컨테이너별 리스너 매핑 + +3. **Synthetic Event 구현** + - 네이티브 이벤트 직접 사용 (JSDOM 호환성) + - `nativeEvent` 속성 추가 + - `preventDefault`/`stopPropagation` 래핑 + +4. **JSDOM 호환성 수정** + - `Object.create` 대신 네이티브 이벤트 직접 사용 + - Handler 호출 방식 변경 (`handler.call` → `handler`) + +### 참고 문서 +- `15_event-system-jsdom-fix.md`: JSDOM 호환성 수정 상세 내용 diff --git a/.cursor/mockdowns/react-implementation/15_event-system-jsdom-fix.md b/.cursor/mockdowns/react-implementation/15_event-system-jsdom-fix.md new file mode 100644 index 00000000..e4f2739b --- /dev/null +++ b/.cursor/mockdowns/react-implementation/15_event-system-jsdom-fix.md @@ -0,0 +1,80 @@ +# 이벤트 시스템 JSDOM 호환성 수정 + +## 문제 상황 + +### 발견된 오류 + +1. **단위 테스트 오류**: + - `'get target' called on an object that is not a valid instance of Event.` + - `Illegal invocation` 오류 + +2. **개발 서버 오류**: + - 카테고리 클릭 시 `Illegal invocation` 오류 + - 검색어 검색 안됨 + - 카트 버튼 클릭 안됨 + - 필터링 안됨 + +### 원인 분석 + +1. **JSDOM 호환성 문제**: + - `Object.create(nativeEvent)`로 만든 객체가 JSDOM에서 유효한 Event 인스턴스로 인식되지 않음 + - `Object.defineProperty`로 속성을 추가하는 것이 JSDOM의 내부 검증과 충돌 + +2. **Illegal invocation 오류**: + - `handler.call(current, syntheticEvent)`에서 발생 + - 또는 `e.target.getAttribute` 호출 시 `e.target`이 텍스트 노드인 경우 + +## 해결 방법 + +### 1. 네이티브 이벤트 직접 사용 + +```typescript +// Object.create 대신 네이티브 이벤트를 직접 사용 +const syntheticEvent = nativeEvent as unknown as SyntheticEvent; + +// nativeEvent 속성만 추가 +Object.defineProperty(syntheticEvent, "nativeEvent", { + value: nativeEvent, + writable: false, + enumerable: true, + configurable: false, +}); +``` + +### 2. currentTarget 처리 + +- 이벤트 위임 환경에서는 네이티브 이벤트의 `currentTarget`이 루트 컨테이너를 가리킴 +- 각 핸들러에서 필요한 경우 `event.target`을 사용하여 현재 요소 찾기 +- 또는 `closest()` 메서드 사용 + +### 3. Handler 호출 방식 + +```typescript +// handler.call 대신 직접 호출 +handler(syntheticEvent); +``` + +## 구현 상태 + +### 완료된 작업 + +- [x] 네이티브 이벤트 직접 사용으로 변경 +- [x] `nativeEvent` 속성 추가 +- [x] Handler 호출 방식 변경 (`handler.call` → `handler`) +- [x] `currentTarget` 오버라이드 제거 (JSDOM 호환성) + +### 테스트 필요 + +- [ ] 단위 테스트 통과 확인 +- [ ] 개발 서버에서 이벤트 동작 확인 +- [ ] 카테고리 클릭 동작 확인 +- [ ] 검색 기능 동작 확인 +- [ ] 카트 버튼 동작 확인 +- [ ] 필터링 동작 확인 + +## 다음 단계 + +1. 테스트 실행 및 결과 확인 +2. 필요시 추가 수정 +3. 진행도 문서 업데이트 + diff --git a/.cursor/mockdowns/react-implementation/16_partial-event-handling-issue.md b/.cursor/mockdowns/react-implementation/16_partial-event-handling-issue.md new file mode 100644 index 00000000..b9d0deb6 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/16_partial-event-handling-issue.md @@ -0,0 +1,198 @@ +# 부분 이벤트 핸들링 문제 분석 + +## 문제 상황 + +### 발견된 증상 + +1. **작동하는 이벤트**: + - `onClick` (장바구니 담기, product 카드 클릭) + - `handleMainCategoryClick` (카테고리 선택) + +2. **작동하지 않는 이벤트**: + - `onKeyDown` (검색 입력) + - `onChange` (개수, 정렬 필터링) + - `handleBreadCrumbClick` (브레드크럼 클릭) + - `handleSubCategoryClick` (2depth 카테고리 클릭) + - 카트 버튼 클릭 + +### 패턴 분석 + +- **Store 관련 기능**: 작동 (장바구니 담기, product 카드 클릭) +- **a 태그**: 작동 (라우팅) +- **일부 onClick**: 작동 (handleMainCategoryClick) +- **대부분의 이벤트**: 작동 안함 + +## 원인 분석 + +### 1. 이벤트 버블링 처리 로직 문제 + +`listenToNativeEvent` 함수에서 이벤트 버블링 여부를 확인하는 로직이 있습니다: + +```typescript +const captureListener = (event: Event) => { + if (event.bubbles && event.eventPhase !== Event.CAPTURING_PHASE) { + return; // 버블링하는 이벤트는 bubble 단계에서 처리 + } + dispatchEvent(eventName, event); +}; + +const bubbleListener = (event: Event) => { + if (!event.bubbles && event.eventPhase !== Event.BUBBLING_PHASE) { + return; // 버블링하지 않는 이벤트는 capture 단계에서 처리 + } + dispatchEvent(eventName, event); +}; +``` + +**문제점**: +- `event.eventPhase`는 이벤트가 발생한 시점의 phase를 나타냅니다 +- Capture 단계에서 발생한 이벤트는 `Event.CAPTURING_PHASE`이지만, 이벤트가 버블링하는 경우 bubble 단계에서도 발생합니다 +- 하지만 `captureListener`는 capture 단계에서만 실행되고, `bubbleListener`는 bubble 단계에서만 실행됩니다 +- 따라서 버블링하는 이벤트는 bubble 단계에서만 처리되어야 하는데, 현재 로직은 capture 단계에서도 처리하려고 시도합니다 + +### 2. 이벤트 타입별 버블링 특성 + +브라우저에서 이벤트 버블링 특성: +- `click`: 버블링함 ✓ +- `keydown`: 버블링함 ✓ +- `change`: 버블링하지 않음 ✗ + +### 3. 실제 문제 + +현재 로직의 문제: +1. **버블링하는 이벤트** (`click`, `keydown`): + - Capture 단계: `event.bubbles === true`이고 `event.eventPhase === Event.CAPTURING_PHASE`이므로 `captureListener`에서 `dispatchEvent` 호출 + - Bubble 단계: `event.bubbles === true`이고 `event.eventPhase === Event.BUBBLING_PHASE`이므로 `bubbleListener`에서 `dispatchEvent` 호출 + - **결과**: 이벤트가 두 번 디스패치될 수 있음 + +2. **버블링하지 않는 이벤트** (`change`): + - Capture 단계: `event.bubbles === false`이고 `event.eventPhase === Event.CAPTURING_PHASE`이므로 `captureListener`에서 `dispatchEvent` 호출 + - Bubble 단계: `event.bubbles === false`이므로 `bubbleListener`에서 early return + - **결과**: 정상 작동해야 함 + +하지만 실제로는 `change` 이벤트가 작동하지 않는다는 것은 다른 문제가 있을 수 있습니다. + +### 4. 가능한 추가 문제 + +1. **이벤트 등록 시점 문제**: + - `registerEvent`가 호출될 때 `rootContainer`가 설정되어 있지 않으면 리스너가 부착되지 않음 + - 이후 `setEventRoot`가 호출되어도 이미 등록된 이벤트만 부착됨 + +2. **이벤트 디스패치 문제**: + - `dispatchEvent`에서 `event.target`이 텍스트 노드인 경우 문제 발생 가능 + - `e.target.getAttribute` 호출 시 `Illegal invocation` 오류 + +## 해결 방법 + +### 1. 이벤트 버블링 처리 로직 수정 + +버블링하는 이벤트는 bubble 단계에서만 처리하고, 버블링하지 않는 이벤트는 capture 단계에서만 처리하도록 수정: + +```typescript +const listenToNativeEvent = (eventName: string, container: HTMLElement): void => { + // 이벤트 타입별 버블링 여부 확인 + // 브라우저에서 change, focus, blur 등은 버블링하지 않음 + const bubbles = eventName !== "change" && eventName !== "focus" && eventName !== "blur"; + + if (bubbles) { + // 버블링하는 이벤트: bubble 단계에서만 처리 + const bubbleListener = (event: Event) => { + dispatchEvent(eventName, event); + }; + container.addEventListener(eventName, bubbleListener, false); + // ... 저장 로직 + } else { + // 버블링하지 않는 이벤트: capture 단계에서만 처리 + const captureListener = (event: Event) => { + dispatchEvent(eventName, event); + }; + container.addEventListener(eventName, captureListener, true); + // ... 저장 로직 + } +}; +``` + +### 2. 이벤트 등록 시점 보장 + +`setEventRoot`가 호출될 때 이미 등록된 이벤트를 부착하도록 보장: + +```typescript +export const setEventRoot = (container: HTMLElement): void => { + // ... 기존 로직 + + // 기존에 등록된 모든 이벤트 리스너를 새 루트에 부착 + attachToContainer(container); +}; +``` + +### 3. 이벤트 타겟 처리 개선 + +`dispatchEvent`에서 텍스트 노드인 경우 부모 요소를 찾도록 개선: + +```typescript +const dispatchEvent = (eventName: string, event: Event) => { + if (!rootContainer) return; + + let current: Node | null = event.target as Node | null; + + while (current) { + // 텍스트 노드인 경우 부모 요소로 이동 + if (current.nodeType === Node.TEXT_NODE) { + current = current.parentNode; + continue; + } + + if (current instanceof HTMLElement) { + // ... 핸들러 실행 로직 + } + current = current.parentNode; + } +}; +``` + +## 추가 이슈 (2024-12-XX) + +- 단위 테스트 `이벤트 핸들러가 올바르게 등록되고 실행된다`에서 `mouseover` 이벤트가 작동하지 않는 문제 발생 +- 원인: 테스트에서 `new Event("mouseover")`를 사용할 때 기본으로 `bubbles: false`이기 때문에 bubble 단계 리스너가 호출되지 않음 +- 해결: 모든 이벤트 타입에 대해 capture/bubble 리스너를 동시에 등록하고, 런타임에 `event.bubbles` 값을 확인하여 어느 단계에서 처리할지 결정 + - `event.bubbles === false`이면 capture 리스너에서 처리 + - `event.bubbles === true`이면 bubble 리스너에서 처리 + +## 구현 계획 + +1. [x] 이벤트 버블링 처리 로직 수정 +2. [x] 이벤트 타입별 버블링 여부 확인 로직 추가 (런타임 판단) +3. [x] 텍스트 노드 처리 개선 +4. [ ] 테스트 및 검증 + +## 구현 완료 (2024-12-XX) + +### 수정 내용 + +1. **이벤트 버블링 처리 로직 개선**: + - 버블링하는 이벤트 (`click`, `keydown` 등): bubble 단계에서만 처리 + - 버블링하지 않는 이벤트 (`change`, `focus`, `blur`): capture 단계에서만 처리 + - 이벤트 타입별로 적절한 단계에서만 리스너 부착 + +2. **텍스트 노드 처리 개선**: + - `dispatchEvent`에서 텍스트 노드인 경우 부모 요소로 이동 + - 이벤트 핸들러는 HTMLElement에만 등록되므로 텍스트 노드는 건너뜀 + +3. **리스너 관리 개선**: + - 모든 이벤트에 대해 capture/bubble 리스너를 동시에 등록 + - 런타임에서 `event.bubbles` 값으로 처리 단계를 결정 + - 리스너 제거 시 capture/bubble을 명확하게 해제 + +### 수정된 파일 + +- `packages/react/src/core/events.ts`: + - `listenToNativeEvent`: 모든 이벤트에 대해 capture/bubble 리스너를 등록하고 런타임으로 처리 단계 결정 + - `dispatchEvent`: 텍스트 노드 처리 개선 + - `detachFromContainer`: capture/bubble 리스너를 명확하게 제거 + +## 참고 + +- React DOM의 이벤트 시스템은 모든 이벤트를 bubble 단계에서 처리합니다 +- 하지만 `change`, `focus`, `blur` 같은 이벤트는 버블링하지 않으므로 capture 단계에서 처리해야 합니다 +- 우리의 현재 구현은 이벤트 버블링 여부를 동적으로 확인하려고 하지만, 이는 복잡하고 오류가 발생하기 쉽습니다 + diff --git a/.cursor/mockdowns/react-implementation/17_event-debugging-guide.md b/.cursor/mockdowns/react-implementation/17_event-debugging-guide.md new file mode 100644 index 00000000..ace6f233 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/17_event-debugging-guide.md @@ -0,0 +1,158 @@ +# 이벤트 시스템 디버깅 가이드 + +> **상세한 단계별 가이드는 `18_event-debugging-step-by-step.md`를 참고하세요.** + +## 문제 상황 + +- 단위 테스트: 통과 +- 개발 서버: 이벤트 작동 안함 (검색 입력, 필터링 등) + +## 디버깅 방법 + +### 1. 브라우저 콘솔에서 확인할 수 있는 정보 + +개발 서버를 실행한 후 브라우저 콘솔에서 다음을 확인하세요: + +```javascript +// 1. 이벤트 루트가 설정되었는지 확인 +// 콘솔에서 실행 +window.__REACT_DEBUG__ = true; + +// 2. 등록된 이벤트 타입 확인 +// events.ts에 임시로 추가할 수 있는 디버깅 코드 +``` + +### 2. 이벤트 시스템 상태 확인을 위한 로그 추가 + +다음 파일들에 디버깅 로그를 추가하여 문제를 파악할 수 있습니다: + +#### 2.1 `packages/react/src/core/events.ts`에 로그 추가 + +```typescript +// setEventRoot 함수에 로그 추가 +export const setEventRoot = (container: HTMLElement): void => { + console.log("[EventSystem] setEventRoot called", { + container, + registeredEventsCount: registeredEvents.size, + registeredEvents: Array.from(registeredEvents), + }); + // ... 기존 코드 +}; + +// addEventHandler 함수에 로그 추가 +export const addEventHandler = (dom: HTMLElement, eventName: string, handler: EventHandler): void => { + console.log("[EventSystem] addEventHandler called", { + dom, + eventName, + hasHandler: typeof handler === "function", + rootContainer: rootContainer, + }); + // ... 기존 코드 +}; + +// dispatchEvent 함수에 로그 추가 +const dispatchEvent = (eventName: string, event: Event) => { + console.log("[EventSystem] dispatchEvent called", { + eventName, + target: event.target, + rootContainer: rootContainer, + }); + // ... 기존 코드 +}; +``` + +#### 2.2 `packages/react/src/core/dom.ts`에 로그 추가 + +```typescript +// setDomProps 함수의 이벤트 핸들러 등록 부분에 로그 추가 +if (key.startsWith("on") && typeof value === "function") { + const eventName = key.slice(2).toLowerCase(); + console.log("[DOM] Registering event handler", { + element: dom, + prop: key, + eventName, + hasValue: typeof value === "function", + }); + addEventHandler(dom, eventName, value); + return; +} +``` + +### 3. 확인해야 할 사항 + +#### 3.1 이벤트 루트 설정 시점 + +1. `createRoot`가 호출되는 시점 확인 +2. `setEventRoot`가 호출되는 시점 확인 +3. `rootContainer`가 올바르게 설정되었는지 확인 + +#### 3.2 이벤트 등록 시점 + +1. `addEventHandler`가 호출되는지 확인 +2. `registerEvent`가 호출되는지 확인 +3. `listenToNativeEvent`가 호출되는지 확인 +4. 네이티브 리스너가 실제로 부착되었는지 확인 + +#### 3.3 이벤트 디스패치 시점 + +1. 네이티브 이벤트가 발생했을 때 `dispatchEvent`가 호출되는지 확인 +2. `elementEventStore`에 핸들러가 저장되어 있는지 확인 +3. 핸들러가 실제로 실행되는지 확인 + +### 4. 브라우저 개발자 도구에서 확인 + +#### 4.1 Event Listeners 확인 + +1. 개발자 도구 → Elements 탭 +2. 이벤트가 작동하지 않는 요소 선택 (예: 검색 입력 필드) +3. 우측 패널에서 "Event Listeners" 탭 확인 +4. `click`, `keydown`, `change` 등의 이벤트 리스너가 부착되어 있는지 확인 +5. 리스너가 루트 컨테이너에 부착되어 있는지 확인 + +#### 4.2 네트워크 탭 확인 + +- 이벤트 핸들러가 API 호출을 하는 경우, 네트워크 탭에서 요청이 발생하는지 확인 + +### 5. 체크리스트 + +다음 항목들을 순서대로 확인하세요: + +- [ ] `createRoot`가 호출되었는가? +- [ ] `setEventRoot`가 호출되었는가? +- [ ] `rootContainer`가 올바르게 설정되었는가? +- [ ] 이벤트 핸들러가 `addEventHandler`를 통해 등록되었는가? +- [ ] `registerEvent`가 호출되어 이벤트 타입이 등록되었는가? +- [ ] `listenToNativeEvent`가 호출되어 네이티브 리스너가 부착되었는가? +- [ ] 네이티브 이벤트 발생 시 `dispatchEvent`가 호출되는가? +- [ ] `elementEventStore`에 핸들러가 저장되어 있는가? +- [ ] 핸들러가 실제로 실행되는가? + +### 6. 예상되는 문제 시나리오 + +#### 시나리오 1: 이벤트 루트가 설정되지 않음 + +- 증상: 모든 이벤트가 작동하지 않음 +- 원인: `createRoot`가 호출되지 않았거나, `setEventRoot`가 호출되지 않음 +- 확인: `rootContainer`가 `null`인지 확인 + +#### 시나리오 2: 이벤트 타입이 등록되지 않음 + +- 증상: 특정 이벤트 타입만 작동하지 않음 +- 원인: `registerEvent`가 호출되지 않았거나, `listenToNativeEvent`가 호출되지 않음 +- 확인: `registeredEvents`에 해당 이벤트 타입이 있는지 확인 + +#### 시나리오 3: 네이티브 리스너가 부착되지 않음 + +- 증상: 이벤트 핸들러는 등록되었지만 네이티브 이벤트가 발생하지 않음 +- 원인: `listenToNativeEvent`가 호출되지 않았거나, 리스너 부착이 실패함 +- 확인: 브라우저 개발자 도구에서 Event Listeners 확인 + +#### 시나리오 4: 이벤트 디스패치가 실패함 + +- 증상: 네이티브 이벤트는 발생하지만 핸들러가 실행되지 않음 +- 원인: `dispatchEvent`가 호출되지 않거나, `elementEventStore`에서 핸들러를 찾지 못함 +- 확인: `dispatchEvent` 로그와 `elementEventStore` 내용 확인 + +### 7. 다음 단계 + +위의 디버깅 정보를 수집한 후, 결과를 공유해주시면 더 정확한 문제 분석이 가능합니다. diff --git a/.cursor/mockdowns/react-implementation/18_event-debugging-step-by-step.md b/.cursor/mockdowns/react-implementation/18_event-debugging-step-by-step.md new file mode 100644 index 00000000..934e42e3 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/18_event-debugging-step-by-step.md @@ -0,0 +1,305 @@ +# 이벤트 시스템 디버깅 단계별 가이드 + +## 준비 단계 + +### 1. 개발 서버 실행 + +```bash +# 터미널에서 실행 +pnpm run dev +``` + +### 2. 브라우저에서 디버깅 모드 활성화 + +1. 브라우저 개발자 도구 열기 (F12 또는 Ctrl+Shift+I) +2. **Console** 탭 선택 +3. 다음 명령어 입력 후 Enter: + +```javascript +window.__REACT_DEBUG_EVENTS__ = true; +``` + +4. 페이지 새로고침 (F5 또는 Ctrl+R) + +## 확인 사항 1: 검색 입력 필드에 onKeyDown 핸들러 등록 확인 + +### 행위 + +1. 브라우저에서 개발 서버 접속 (보통 `http://localhost:5173`) +2. **Console 탭을 열어둔 상태**로 유지 +3. 검색 입력 필드(상단의 "상품명을 검색해보세요..." 입력창)를 **한 번 클릭**하여 포커스 +4. Console 탭에서 다음 로그를 확인: + +### 확인할 로그 + +``` +[DOM] updateDomProps: registering event handler +``` + +이 로그가 나타나야 하며, 다음 정보를 확인: + +- `eventName: 'keydown'` ← **이것이 있어야 함** +- `prop: 'onKeyDown'` 또는 `prop: 'onkeydown'` +- `nextValue: true` (핸들러가 함수임을 의미) + +### 예상 결과 + +- ✅ **정상**: `eventName: 'keydown'` 로그가 보임 +- ❌ **문제**: `eventName: 'keydown'` 로그가 없음 → 핸들러가 등록되지 않음 + +### 추가 확인 + +로그가 나타난 후, 다음 로그도 확인: + +``` +[EventSystem] addEventHandler called +``` + +이 로그에서도 `eventName: 'keydown'`이 있어야 함 + +--- + +## 확인 사항 2: Select 요소에 onChange 핸들러 등록 확인 + +### 행위 + +1. Console 탭을 열어둔 상태로 유지 +2. 페이지 하단의 **"개수"** 드롭다운(select)을 **한 번 클릭** +3. Console 탭에서 다음 로그를 확인: + +### 확인할 로그 + +``` +[DOM] updateDomProps: registering event handler +``` + +이 로그가 나타나야 하며, 다음 정보를 확인: + +- `eventName: 'change'` ← **이것이 있어야 함** +- `prop: 'onChange'` 또는 `prop: 'onchange'` +- `nextValue: true` + +### 예상 결과 + +- ✅ **정상**: `eventName: 'change'` 로그가 보임 +- ❌ **문제**: `eventName: 'change'` 로그가 없음 → 핸들러가 등록되지 않음 + +### 추가 확인 + +로그가 나타난 후, 다음 로그도 확인: + +``` +[EventSystem] addEventHandler called +``` + +이 로그에서도 `eventName: 'change'`가 있어야 함 + +--- + +## 확인 사항 3: dispatchEvent에서 핸들러를 찾는 과정 확인 + +### 행위 1: 검색 입력 필드에서 키 입력 + +1. Console 탭을 열어둔 상태로 유지 +2. 검색 입력 필드 클릭하여 포커스 +3. 키보드에서 **아무 키나 한 번 입력** (예: 'a' 입력) +4. Console 탭에서 다음 로그들을 순서대로 확인: + +### 확인할 로그 순서 + +1. **첫 번째 로그**: + +``` +[EventSystem] dispatchEvent called +``` + +- `eventName: 'keydown'` 확인 +- `targetType: 'INPUT'` 확인 + +2. **두 번째 로그** (핸들러 검색): + +``` +[EventSystem] Looking for handler +``` + +이 로그에서 다음 정보 확인: + +- `eventName: 'keydown'` ← 확인 +- `elementId`: 입력 필드의 ID 또는 클래스명 +- `hasHandlers`: `true` 또는 `false` ← **true여야 함** +- `handlerKeys`: 배열 형태 (예: `['keydown']`) ← **'keydown'이 포함되어야 함** +- `hasHandler`: `true` 또는 `false` ← **true여야 함** + +3. **세 번째 로그** (핸들러 실행): + +``` +[EventSystem] Executing handler +``` + +- 이 로그가 나타나면 핸들러가 실행된 것 +- 이 로그가 없으면 핸들러가 실행되지 않은 것 + +### 예상 결과 + +- ✅ **정상**: + - `hasHandlers: true` + - `handlerKeys`에 `'keydown'` 포함 + - `hasHandler: true` + - `[EventSystem] Executing handler` 로그 나타남 +- ❌ **문제**: + - `hasHandlers: false` → 핸들러가 등록되지 않음 + - `handlerKeys`에 `'keydown'` 없음 → 핸들러가 등록되지 않음 + - `hasHandler: false` → 핸들러를 찾지 못함 + - `[EventSystem] Executing handler` 로그 없음 → 핸들러가 실행되지 않음 + +### 행위 2: Select 요소에서 옵션 변경 + +1. Console 탭을 열어둔 상태로 유지 +2. "개수" 드롭다운 클릭 +3. 다른 옵션 선택 (예: 10개 → 20개) +4. Console 탭에서 다음 로그들을 순서대로 확인: + +### 확인할 로그 순서 + +1. **첫 번째 로그**: + +``` +[EventSystem] dispatchEvent called +``` + +- `eventName: 'change'` 확인 +- `targetType: 'SELECT'` 확인 + +2. **두 번째 로그** (핸들러 검색): + +``` +[EventSystem] Looking for handler +``` + +이 로그에서 다음 정보 확인: + +- `eventName: 'change'` ← 확인 +- `elementId`: select 요소의 ID 또는 클래스명 +- `hasHandlers`: `true` 또는 `false` ← **true여야 함** +- `handlerKeys`: 배열 형태 (예: `['change']`) ← **'change'가 포함되어야 함** +- `hasHandler`: `true` 또는 `false` ← **true여야 함** + +3. **세 번째 로그** (핸들러 실행): + +``` +[EventSystem] Executing handler +``` + +- 이 로그가 나타나면 핸들러가 실행된 것 + +### 예상 결과 + +- ✅ **정상**: + - `hasHandlers: true` + - `handlerKeys`에 `'change'` 포함 + - `hasHandler: true` + - `[EventSystem] Executing handler` 로그 나타남 +- ❌ **문제**: + - `hasHandlers: false` → 핸들러가 등록되지 않음 + - `handlerKeys`에 `'change'` 없음 → 핸들러가 등록되지 않음 + - `hasHandler: false` → 핸들러를 찾지 못함 + - `[EventSystem] Executing handler` 로그 없음 → 핸들러가 실행되지 않음 + +--- + +## 전체 테스트 시나리오 + +### 시나리오 1: 검색 입력 필드 테스트 + +1. 페이지 로드 후 Console 탭 열기 +2. `window.__REACT_DEBUG_EVENTS__ = true;` 실행 +3. 페이지 새로고침 +4. 검색 입력 필드 클릭 +5. Console에서 `[DOM] updateDomProps: registering event handler` 로그 확인 (keydown) +6. 검색 입력 필드에 'a' 입력 +7. Console에서 `[EventSystem] dispatchEvent called` 로그 확인 (keydown) +8. Console에서 `[EventSystem] Looking for handler` 로그 확인 +9. Console에서 `[EventSystem] Executing handler` 로그 확인 + +### 시나리오 2: Select 요소 테스트 + +1. 페이지 로드 후 Console 탭 열기 +2. `window.__REACT_DEBUG_EVENTS__ = true;` 실행 +3. 페이지 새로고침 +4. "개수" 드롭다운 클릭 +5. Console에서 `[DOM] updateDomProps: registering event handler` 로그 확인 (change) +6. 다른 옵션 선택 (예: 20개) +7. Console에서 `[EventSystem] dispatchEvent called` 로그 확인 (change) +8. Console에서 `[EventSystem] Looking for handler` 로그 확인 +9. Console에서 `[EventSystem] Executing handler` 로그 확인 + +### 시나리오 3: 카트 버튼 클릭 테스트 + +1. 페이지 로드 후 Console 탭 열기 +2. `window.__REACT_DEBUG_EVENTS__ = true;` 실행 +3. 페이지 새로고침 +4. 우측 상단의 카트 아이콘 버튼 클릭 +5. Console에서 `[EventSystem] dispatchEvent called` 로그 확인 (click) +6. Console에서 `[EventSystem] Looking for handler` 로그 확인 +7. Console에서 `[EventSystem] Executing handler` 로그 확인 + +--- + +## 로그 해석 가이드 + +### 정상적인 흐름 + +``` +1. [DOM] updateDomProps: registering event handler { eventName: 'keydown', ... } +2. [EventSystem] addEventHandler called { eventName: 'keydown', ... } +3. [EventSystem] addEventHandler completed { eventName: 'keydown', ... } +4. (사용자가 키 입력) +5. [EventSystem] dispatchEvent called { eventName: 'keydown', ... } +6. [EventSystem] Looking for handler { hasHandlers: true, handlerKeys: ['keydown'], hasHandler: true } +7. [EventSystem] Executing handler { eventName: 'keydown', ... } +``` + +### 문제가 있는 흐름 (핸들러 미등록) + +``` +1. (updateDomProps 로그 없음) +2. (addEventHandler 로그 없음) +3. (사용자가 키 입력) +4. [EventSystem] dispatchEvent called { eventName: 'keydown', ... } +5. [EventSystem] Looking for handler { hasHandlers: false, handlerKeys: [], hasHandler: false } +6. (Executing handler 로그 없음) +``` + +### 문제가 있는 흐름 (핸들러 등록되었지만 찾지 못함) + +``` +1. [DOM] updateDomProps: registering event handler { eventName: 'keydown', ... } +2. [EventSystem] addEventHandler called { eventName: 'keydown', ... } +3. (사용자가 키 입력) +4. [EventSystem] dispatchEvent called { eventName: 'keydown', ... } +5. [EventSystem] Looking for handler { hasHandlers: true, handlerKeys: ['click'], hasHandler: false } + ← handlerKeys에 'keydown'이 없음! +6. (Executing handler 로그 없음) +``` + +--- + +## 결과 공유 방법 + +테스트 후 다음 정보를 공유해주세요: + +1. **검색 입력 필드 테스트 결과**: + - `[DOM] updateDomProps` 로그에 `eventName: 'keydown'`이 있었는지 + - `[EventSystem] Looking for handler` 로그의 `hasHandlers`, `handlerKeys`, `hasHandler` 값 + - `[EventSystem] Executing handler` 로그가 나타났는지 + +2. **Select 요소 테스트 결과**: + - `[DOM] updateDomProps` 로그에 `eventName: 'change'`가 있었는지 + - `[EventSystem] Looking for handler` 로그의 `hasHandlers`, `handlerKeys`, `hasHandler` 값 + - `[EventSystem] Executing handler` 로그가 나타났는지 + +3. **카트 버튼 클릭 테스트 결과**: + - `[EventSystem] Looking for handler` 로그의 `hasHandlers`, `handlerKeys`, `hasHandler` 값 + - `[EventSystem] Executing handler` 로그가 나타났는지 + +이 정보를 바탕으로 정확한 문제 원인을 파악할 수 있습니다. diff --git a/.cursor/mockdowns/react-implementation/19_event-handler-registration-issue.md b/.cursor/mockdowns/react-implementation/19_event-handler-registration-issue.md new file mode 100644 index 00000000..c19f6050 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/19_event-handler-registration-issue.md @@ -0,0 +1,57 @@ +# 이벤트 핸들러 등록 문제 분석 + +## 문제 상황 + +로그 분석 결과: +- **모든 요소에서 `hasHandlers: false`**: 핸들러가 전혀 등록되지 않음 +- **`handlerKeys: Array(0)`**: 빈 배열 - 핸들러가 없음 +- **`[DOM] updateDomProps: registering event handler` 로그 없음**: 이벤트 핸들러 등록 과정이 실행되지 않음 + +## 원인 분석 + +### 가능한 원인 + +1. **`setDomProps`/`updateDomProps`가 호출되지 않음** + - 컴포넌트가 마운트/업데이트될 때 props가 전달되지 않음 + - reconcile 과정에서 props 업데이트가 누락됨 + +2. **이벤트 핸들러 props가 VNode에 포함되지 않음** + - JSX 변환 과정에서 이벤트 핸들러가 props로 전달되지 않음 + - 컴포넌트 렌더링 시 props가 손실됨 + +3. **조건문을 통과하지 못함** + - `key.startsWith("on")` 조건 실패 + - `typeof value === "function"` 조건 실패 + +## 해결 방법 + +### 1. 디버깅 로그 추가 + +`setDomProps`와 `updateDomProps`에 디버깅 로그를 추가하여: +- 함수가 호출되는지 확인 +- props에 이벤트 핸들러가 포함되어 있는지 확인 +- 조건문을 통과하는지 확인 + +### 2. 확인 사항 + +다음 로그들을 확인해야 합니다: + +1. **`[DOM] setDomProps called`**: + - `propsKeys`: props의 키 목록 + - `hasOnKeyDown`, `hasOnChange`, `hasOnClick`: 이벤트 핸들러 props 존재 여부 + +2. **`[DOM] updateDomProps called`**: + - `prevPropsKeys`, `nextPropsKeys`: 이전/다음 props의 키 목록 + - `hasOnKeyDown`, `hasOnChange`, `hasOnClick`: 이벤트 핸들러 props 존재 여부 + +3. **`[DOM] updateDomProps: registering event handler`**: + - 이벤트 핸들러가 실제로 등록되는지 확인 + +## 다음 단계 + +1. 페이지를 새로고침하고 Console 로그 확인 +2. `[DOM] setDomProps called` 로그에서 props 확인 +3. `[DOM] updateDomProps called` 로그에서 props 확인 +4. 이벤트 핸들러 props가 있는데도 등록되지 않으면 조건문 문제 +5. 이벤트 핸들러 props가 없으면 VNode 생성 과정 문제 + diff --git a/.cursor/mockdowns/react-implementation/20_infinite-scroll-issue-analysis.md b/.cursor/mockdowns/react-implementation/20_infinite-scroll-issue-analysis.md new file mode 100644 index 00000000..6b45073b --- /dev/null +++ b/.cursor/mockdowns/react-implementation/20_infinite-scroll-issue-analysis.md @@ -0,0 +1,398 @@ +# 무한 스크롤 문제 분석 + +## 📋 문제 개요 + +무한 스크롤 기능이 작동하지 않는 문제를 전체적으로 분석한 문서입니다. + +## 🔍 현재 구현 상태 + +### 1. 구현 위치 + +**파일**: `packages/app/src/pages/HomePage.jsx` + +```javascript +// 무한 스크롤 이벤트 등록 +let scrollHandlerRegistered = false; + +const loadNextProducts = async () => { + // 현재 라우트가 홈이 아니면 무한 스크롤 비활성화 + if (router.route?.path !== "/") { + return; + } + + if (isNearBottom(200)) { + const productState = productStore.getState(); + const hasMore = productState.products.length < state.totalCount; + + // 로딩 중이거나 더 이상 로드할 데이터가 없으면 return + if (productState.loading || !hasMore) { + return; + } + + try { + await loadMoreProducts(); + } catch (error) { + console.error("무한 스크롤 로드 실패:", error); + } + } +}; + +const registerScrollHandler = () => { + if (scrollHandlerRegistered) return; + + window.addEventListener("scroll", loadNextProducts); + scrollHandlerRegistered = true; +}; + +const unregisterScrollHandler = () => { + if (!scrollHandlerRegistered) return; + window.removeEventListener("scroll", loadNextProducts); + scrollHandlerRegistered = false; +}; + +export const HomePage = () => { + // ... + useEffect(() => { + registerScrollHandler(); + loadProductsAndCategories(); + return () => unregisterScrollHandler(); + }, []); + // ... +}; +``` + +### 2. 관련 함수들 + +**`isNearBottom`** (`packages/app/src/utils/domUtils.js`): + +```javascript +export const isNearBottom = (threshold = 200) => { + const scrollTop = window.pageYOffset || document.documentElement.scrollTop; + const windowHeight = window.innerHeight; + const documentHeight = document.documentElement.scrollHeight; + + return scrollTop + windowHeight >= documentHeight - threshold; +}; +``` + +**`loadMoreProducts`** (`packages/app/src/services/productService.js`): + +```javascript +export const loadMoreProducts = async () => { + const state = productStore.getState(); + const hasMore = state.products.length < state.totalCount; + + if (!hasMore || state.loading) { + return; + } + + router.query = { current: Number(router.query.current ?? 1) + 1 }; + await loadProducts(false); +}; +``` + +## 🐛 발견된 문제점 + +### 문제 1: 함수 참조 불일치 ⚠️ **CRITICAL** + +**위치**: `HomePage.jsx` Line 46, 52 + +**문제**: + +- `registerScrollHandler`에서 `window.addEventListener("scroll", loadNextProducts)`로 등록 +- `unregisterScrollHandler`에서 `window.removeEventListener("scroll", loadNextProducts)`로 제거 +- **함수 참조가 동일해야 `removeEventListener`가 작동하는데**, 모듈 레벨에서 정의된 함수이므로 참조는 동일해야 함 +- 하지만 컴포넌트가 리렌더링될 때 cleanup이 실행되고 다시 등록되는 과정에서 문제가 발생할 수 있음 + +**영향**: + +- 이벤트 리스너가 중복 등록될 수 있음 +- 메모리 누수 가능성 +- 이벤트 핸들러가 여러 번 실행될 수 있음 + +### 문제 2: 전역 변수 관리 문제 ⚠️ **HIGH** + +**위치**: `HomePage.jsx` Line 18 + +**문제**: + +```javascript +let scrollHandlerRegistered = false; +``` + +- 전역 변수로 이벤트 리스너 등록 상태를 관리 +- 컴포넌트가 여러 번 마운트/언마운트될 때 상태가 제대로 초기화되지 않을 수 있음 +- React의 컴포넌트 생명주기와 독립적으로 동작하여 예측 불가능한 동작 가능 + +**영향**: + +- 컴포넌트 언마운트 후에도 이벤트 리스너가 남아있을 수 있음 +- 컴포넌트 마운트 시 이벤트 리스너가 등록되지 않을 수 있음 + +### 문제 3: useEffect 의존성 배열 문제 ⚠️ **MEDIUM** + +**위치**: `HomePage.jsx` Line 70-74 + +**문제**: + +```javascript +useEffect(() => { + registerScrollHandler(); + loadProductsAndCategories(); + return () => unregisterScrollHandler(); +}, []); +``` + +- 의존성 배열이 비어있어서 컴포넌트 마운트 시에만 실행됨 +- 하지만 `loadNextProducts` 함수가 클로저로 `router.route?.path`를 참조하는데, 이 값이 변경되어도 함수가 업데이트되지 않음 +- 컴포넌트가 리렌더링될 때 cleanup이 실행되고 다시 등록되는데, 이 과정에서 문제가 발생할 수 있음 + +**영향**: + +- 라우트 변경 시 이벤트 핸들러가 최신 상태를 반영하지 못할 수 있음 +- 컴포넌트 리렌더링 시 불필요한 cleanup/등록이 발생할 수 있음 + +### 문제 4: router.query 업데이트 방식 문제 ⚠️ **MEDIUM** + +**위치**: `packages/app/src/services/productService.js` Line 87 + +**문제**: + +```javascript +router.query = { current: Number(router.query.current ?? 1) + 1 }; +``` + +- `router.query`를 직접 할당하는 방식 +- 기존 query 파라미터들이 유지되지 않고 `current`만 설정됨 +- `router.query`가 객체 참조를 유지하지 않으면 라우터가 변경을 감지하지 못할 수 있음 + +**영향**: + +- 페이지 번호가 제대로 업데이트되지 않을 수 있음 +- 검색어, 필터 등 다른 query 파라미터가 손실될 수 있음 + +### 문제 5: loadNextProducts 내부 로직 확인 ⚠️ **INFO** + +**위치**: `HomePage.jsx` Line 28 + +**확인**: + +```javascript +const hasMore = productState.products.length < productState.totalCount; +``` + +- 코드는 정상적으로 작성되어 있음 +- `productState`를 올바르게 사용하고 있음 + +**참고**: + +- 이 부분은 문제가 없지만, 로직이 정확한지 확인 필요 + +### 문제 6: React 이벤트 시스템과의 관계 ⚠️ **LOW** + +**확인 사항**: + +- React의 이벤트 시스템(`packages/react/src/core/events.ts`)은 `window` 이벤트를 처리하지 않음 +- `window.addEventListener`는 네이티브 DOM API를 직접 사용하므로 React 이벤트 시스템과 충돌하지 않음 +- **하지만** React의 렌더링 사이클과 동기화되지 않아 문제가 발생할 수 있음 + +**영향**: + +- React 컴포넌트가 리렌더링될 때 이벤트 핸들러가 최신 상태를 반영하지 못할 수 있음 + +## 🔬 문제 진단 체크리스트 + +### 1단계: 이벤트 리스너 등록 확인 + +- [ ] `registerScrollHandler`가 호출되는지 확인 +- [ ] `window.addEventListener("scroll", loadNextProducts)`가 실제로 등록되는지 확인 +- [ ] 브라우저 개발자 도구에서 이벤트 리스너 확인 + +### 2단계: 스크롤 이벤트 발생 확인 + +- [ ] 스크롤 시 `loadNextProducts` 함수가 호출되는지 확인 +- [ ] `isNearBottom(200)`이 `true`를 반환하는지 확인 +- [ ] 콘솔에 에러가 발생하는지 확인 + +### 3단계: 데이터 로드 확인 + +- [ ] `loadMoreProducts` 함수가 호출되는지 확인 +- [ ] `router.query.current`가 제대로 업데이트되는지 확인 +- [ ] API 요청이 발생하는지 확인 (Network 탭) +- [ ] `productStore`의 상태가 업데이트되는지 확인 + +### 4단계: 컴포넌트 리렌더링 확인 + +- [ ] 새로운 상품이 화면에 표시되는지 확인 +- [ ] `ProductList` 컴포넌트가 새로운 `products` prop을 받는지 확인 + +## 💡 해결 방안 + +### 해결 방안 1: 함수 참조 문제 해결 + +**문제**: 함수 참조가 일치하지 않아 `removeEventListener`가 작동하지 않을 수 있음 + +**해결**: + +```javascript +// useRef를 사용하여 함수 참조를 유지 +import { useEffect, useRef } from "react"; + +export const HomePage = () => { + const loadNextProductsRef = useRef(null); + + useEffect(() => { + const loadNextProducts = async () => { + // ... 기존 로직 + }; + + loadNextProductsRef.current = loadNextProducts; + window.addEventListener("scroll", loadNextProducts); + + return () => { + window.removeEventListener("scroll", loadNextProductsRef.current); + }; + }, []); +}; +``` + +### 해결 방안 2: 전역 변수 제거 + +**문제**: 전역 변수로 상태를 관리하여 예측 불가능한 동작 + +**해결**: + +```javascript +// useRef를 사용하여 컴포넌트 내부에서 상태 관리 +export const HomePage = () => { + const scrollHandlerRegistered = useRef(false); + + useEffect(() => { + if (scrollHandlerRegistered.current) return; + + const loadNextProducts = async () => { + // ... 기존 로직 + }; + + window.addEventListener("scroll", loadNextProducts); + scrollHandlerRegistered.current = true; + + return () => { + window.removeEventListener("scroll", loadNextProducts); + scrollHandlerRegistered.current = false; + }; + }, []); +}; +``` + +### 해결 방안 3: router.query 업데이트 방식 개선 + +**문제**: `router.query`를 직접 할당하여 기존 파라미터가 손실될 수 있음 + +**해결**: + +```javascript +// 기존 query 파라미터를 유지하면서 current만 업데이트 +export const loadMoreProducts = async () => { + const state = productStore.getState(); + const hasMore = state.products.length < state.totalCount; + + if (!hasMore || state.loading) { + return; + } + + // 기존 query 파라미터 유지 + router.query = { + ...router.query, + current: Number(router.query.current ?? 1) + 1, + }; + await loadProducts(false); +}; +``` + +### 해결 방안 4: 로직 검증 강화 + +**문제**: `hasMore` 계산 로직이 정확한지 확인 필요 + +**해결**: + +```javascript +// 더 명확한 로직 검증 +const hasMore = productState.products.length < productState.totalCount; +// 디버깅 로그 추가 (개발 환경에서만) +if (process.env.NODE_ENV !== "production") { + console.log("[InfiniteScroll] hasMore:", hasMore, { + current: productState.products.length, + total: productState.totalCount, + }); +} +``` + +### 해결 방안 5: throttle/debounce 추가 (성능 개선) + +**문제**: 스크롤 이벤트가 너무 자주 발생하여 성능 문제 + +**해결**: + +```javascript +// throttle 함수 추가 +const throttle = (func, delay) => { + let timeoutId; + let lastExecTime = 0; + return function (...args) { + const currentTime = Date.now(); + + if (currentTime - lastExecTime > delay) { + func.apply(this, args); + lastExecTime = currentTime; + } else { + clearTimeout(timeoutId); + timeoutId = setTimeout( + () => { + func.apply(this, args); + lastExecTime = Date.now(); + }, + delay - (currentTime - lastExecTime), + ); + } + }; +}; + +// 사용 +const throttledLoadNextProducts = throttle(loadNextProducts, 200); +window.addEventListener("scroll", throttledLoadNextProducts); +``` + +## 📝 우선순위별 해결 계획 + +### 1순위: 즉시 수정 필요 (Critical) + +1. ✅ **함수 참조 문제 해결**: useRef 사용하여 함수 참조 유지 +2. ✅ **전역 변수 제거**: useRef로 컴포넌트 내부에서 상태 관리 +3. ✅ **useEffect 의존성 배열 개선**: 필요한 의존성 추가 + +### 2순위: 중요 (High) + +4. ✅ **router.query 업데이트 방식 개선**: 기존 파라미터 유지 +5. ✅ **useEffect 의존성 배열 개선**: 필요한 의존성 추가 + +### 3순위: 개선 (Medium) + +6. ✅ **throttle/debounce 추가**: 성능 개선 +7. ✅ **에러 처리 개선**: 더 명확한 에러 메시지 + +## 🎯 예상 결과 + +위 해결 방안을 적용하면: + +- ✅ 이벤트 리스너가 정확히 등록/제거됨 +- ✅ 스크롤 시 무한 스크롤이 정상 작동함 +- ✅ 메모리 누수 없음 +- ✅ 성능 개선 (throttle 적용 시) +- ✅ 예측 가능한 동작 + +## 📌 참고 사항 + +- React의 이벤트 시스템은 `window` 이벤트를 처리하지 않으므로, 네이티브 DOM API를 직접 사용해야 함 +- 하지만 React의 컴포넌트 생명주기와 동기화하여 사용해야 함 +- `useEffect`의 cleanup 함수를 활용하여 이벤트 리스너를 정리해야 함 diff --git a/.cursor/mockdowns/react-implementation/21_infinite-scroll-react-issue-analysis.md b/.cursor/mockdowns/react-implementation/21_infinite-scroll-react-issue-analysis.md new file mode 100644 index 00000000..0fb212cc --- /dev/null +++ b/.cursor/mockdowns/react-implementation/21_infinite-scroll-react-issue-analysis.md @@ -0,0 +1,241 @@ +# 무한 스크롤 문제 분석 - React 쪽 원인 조사 + +## 📋 문제 개요 + +무한 스크롤이 작동하지 않는 문제를 React 쪽에서 조사한 문서입니다. +app 쪽 스크롤 로직은 정상적으로 작성되어 있다고 가정하고, React의 렌더링/이펙트 시스템에서 원인을 찾습니다. + +## 🔍 React 렌더링 사이클 분석 + +### 1. render 함수 실행 순서 + +**파일**: `packages/react/src/core/render.ts` + +```typescript +export const render = (): void => { + // 1. visited Set 초기화 + context.hooks.visited.clear(); + + // 2. reconcile 함수 호출 (컴포넌트 렌더링) + const newInstance = reconcile(root.container, root.instance, root.node, "root"); + root.instance = newInstance; + + // 3. 사용되지 않은 훅들을 정리 + cleanupUnusedHooks(); + + // 4. 이펙트 큐 실행 (비동기) + enqueue(flushEffects); +}; +``` + +### 2. useEffect cleanup 실행 시점 + +**파일**: `packages/react/src/core/hooks.ts` + +#### 시점 1: 의존성 변경 시 (Line 135-137) + +```typescript +// useEffect 내부에서 의존성이 변경되었을 때 +if (prevHook && prevHook.cleanup) { + prevHook.cleanup(); // 이전 cleanup 실행 +} +``` + +#### 시점 2: cleanupUnusedHooks에서 (Line 40-61) + +```typescript +export const cleanupUnusedHooks = () => { + for (const [path, hooks] of context.hooks.state.entries()) { + if (!context.hooks.visited.has(path)) { + // visited에 없는 경로의 cleanup 실행 + hooks.forEach((hook) => { + if (hook.kind === HookTypes.EFFECT) { + const effectHook = hook as EffectHook; + if (effectHook.cleanup && typeof effectHook.cleanup === "function") { + effectHook.cleanup(); // effect cleanup 실행 + } + } + }); + // 훅 상태 삭제 + context.hooks.state.delete(path); + context.hooks.cursor.delete(path); + } + } +}; +``` + +#### 시점 3: 컴포넌트 언마운트 시 (reconciler.ts Line 36-48) + +```typescript +if (!node) { + if (instance) { + // 컴포넌트가 언마운트될 때 이펙트 클린업 함수를 실행합니다. + const instancePath = instance.path; + const hooksForPath = context.hooks.state.get(instancePath); + if (hooksForPath) { + hooksForPath.forEach((hook) => { + if (hook.kind === HookTypes.EFFECT) { + const effectHook = hook as EffectHook; + if (effectHook.cleanup && typeof effectHook.cleanup === "function") { + effectHook.cleanup(); + } + } + }); + } + removeInstance(parentDom, instance); + } +} +``` + +## 🐛 발견된 잠재적 문제점 + +### 문제 1: cleanupUnusedHooks의 실행 타이밍 ⚠️ **CRITICAL** + +**위치**: `packages/react/src/core/render.ts` Line 36 + +**문제**: + +- `cleanupUnusedHooks`가 `reconcile` 이후에 실행됨 +- `reconcile` 과정에서 `visited` Set에 경로가 추가됨 (`renderFunctionComponent` Line 456) +- 하지만 **컴포넌트가 리렌더링될 때마다 `visited.clear()`가 먼저 실행됨** (Line 26) +- 만약 컴포넌트가 리렌더링되는 동안 `cleanupUnusedHooks`가 실행되면, 이전 렌더링의 경로가 `visited`에 없을 수 있음 + +**시나리오**: + +1. 첫 렌더링: `HomePage` 컴포넌트가 마운트되고 `useEffect`가 실행되어 스크롤 리스너 등록 +2. 상태 변경으로 리렌더링 발생 +3. `render()` 호출: + - `visited.clear()` 실행 + - `reconcile()` 실행 → `visited.add("root/...")` 실행 + - `cleanupUnusedHooks()` 실행 +4. **문제**: 만약 `reconcile` 과정에서 경로가 제대로 추가되지 않았거나, 경로가 변경되었다면 `cleanupUnusedHooks`가 cleanup을 실행할 수 있음 + +**영향**: + +- 컴포넌트가 실제로 언마운트되지 않았는데도 cleanup이 실행될 수 있음 +- 스크롤 이벤트 리스너가 제거될 수 있음 + +### 문제 2: useEffect의 cleanup 실행 조건 ⚠️ **HIGH** + +**위치**: `packages/react/src/core/hooks.ts` Line 134-137 + +**문제**: + +```typescript +// 4. 이전 클린업 함수가 있으면 먼저 실행합니다. +if (prevHook && prevHook.cleanup) { + prevHook.cleanup(); +} +``` + +- 이 cleanup은 **의존성이 변경되었을 때만** 실행됨 +- 하지만 빈 배열 `[]`의 경우 의존성이 변경되지 않으므로 이 cleanup은 실행되지 않아야 함 +- **하지만** `cleanupUnusedHooks`에서 실행될 수 있음 + +**영향**: + +- 빈 배열을 사용하는 `useEffect`의 cleanup이 예상치 못한 시점에 실행될 수 있음 + +### 문제 3: visited Set 관리 문제 ⚠️ **MEDIUM** + +**위치**: `packages/react/src/core/render.ts` Line 26, `reconciler.ts` Line 456 + +**문제**: + +- `render()` 시작 시 `visited.clear()` 실행 +- `reconcile()` 과정에서 `renderFunctionComponent`가 호출될 때만 `visited.add(path)` 실행 +- **하지만** 함수 컴포넌트가 아닌 경우 (일반 DOM 요소, Fragment 등) `visited`에 추가되지 않음 +- 이는 정상이지만, 컴포넌트 경로가 변경되면 문제가 될 수 있음 + +**영향**: + +- 경로가 변경된 컴포넌트의 cleanup이 실행될 수 있음 + +### 문제 4: flushEffects의 비동기 실행 ⚠️ **LOW** + +**위치**: `packages/react/src/core/render.ts` Line 41 + +**문제**: + +- `flushEffects`는 `enqueue`를 통해 비동기로 실행됨 +- 이는 정상이지만, cleanup이 실행된 직후에 새로운 effect가 실행되면 문제가 될 수 있음 + +**영향**: + +- cleanup과 effect 실행 사이의 타이밍 이슈 가능성 + +## 🔬 문제 진단 체크리스트 + +### 1단계: cleanup 실행 확인 + +- [ ] `cleanupUnusedHooks`가 호출되는지 확인 +- [ ] `HomePage` 컴포넌트의 경로가 `visited`에 제대로 추가되는지 확인 +- [ ] cleanup이 예상치 못한 시점에 실행되는지 확인 + +### 2단계: visited Set 관리 확인 + +- [ ] 컴포넌트 리렌더링 시 경로가 변경되는지 확인 +- [ ] `renderFunctionComponent`가 제대로 호출되는지 확인 +- [ ] `visited.add(path)`가 제대로 실행되는지 확인 + +### 3단계: useEffect 실행 확인 + +- [ ] `useEffect`가 마운트 시 실행되는지 확인 +- [ ] cleanup이 언마운트 시에만 실행되는지 확인 +- [ ] 의존성 배열이 빈 배열일 때 cleanup이 실행되지 않는지 확인 + +## 💡 해결 방안 + +### 해결 방안 1: cleanupUnusedHooks 실행 순서 개선 + +**문제**: `cleanupUnusedHooks`가 `reconcile` 이후에 실행되지만, 경로 관리에 문제가 있을 수 있음 + +**해결**: + +- `cleanupUnusedHooks`에서 cleanup을 실행하기 전에 경로가 실제로 언마운트되었는지 확인 +- 또는 cleanup 실행을 더 안전하게 처리 + +### 해결 방안 2: useEffect cleanup 실행 조건 개선 + +**문제**: cleanup이 예상치 못한 시점에 실행될 수 있음 + +**해결**: + +- `cleanupUnusedHooks`에서 cleanup을 실행할 때, 해당 경로가 실제로 언마운트되었는지 확인 +- 또는 cleanup 실행을 더 보수적으로 처리 + +### 해결 방안 3: visited Set 관리 개선 + +**문제**: 경로가 변경되면 cleanup이 실행될 수 있음 + +**해결**: + +- 경로 변경 시 이전 경로의 cleanup을 실행하는 로직 개선 +- 또는 경로 변경을 더 안전하게 처리 + +## 📝 우선순위별 해결 계획 + +### 1순위: 즉시 확인 필요 (Critical) + +1. ✅ **cleanupUnusedHooks 실행 로직 확인**: visited Set 관리가 올바른지 확인 +2. ✅ **useEffect cleanup 실행 조건 확인**: 빈 배열일 때 cleanup이 실행되지 않는지 확인 +3. ✅ **컴포넌트 경로 변경 확인**: 리렌더링 시 경로가 변경되는지 확인 + +### 2순위: 중요 (High) + +4. ✅ **디버깅 로그 추가**: cleanup 실행 시점과 조건을 로깅 +5. ✅ **visited Set 상태 확인**: 각 렌더링 사이클에서 visited Set의 상태 확인 + +## 🎯 예상 결과 + +위 해결 방안을 적용하면: + +- ✅ cleanup이 올바른 시점에만 실행됨 +- ✅ 스크롤 이벤트 리스너가 유지됨 +- ✅ 컴포넌트가 리렌더링되어도 cleanup이 실행되지 않음 + +## 📌 참고 사항 + +- React의 이벤트 시스템은 `window` 이벤트를 처리하지 않으므로, 네이티브 DOM API를 직접 사용해야 함 +- 하지만 React의 렌더링 사이클과 동기화되어야 함 +- `useEffect`의 cleanup은 컴포넌트가 실제로 언마운트될 때만 실행되어야 함 diff --git a/.cursor/mockdowns/react-implementation/22_github-pages-deployment-plan.md b/.cursor/mockdowns/react-implementation/22_github-pages-deployment-plan.md new file mode 100644 index 00000000..ac30cbcd --- /dev/null +++ b/.cursor/mockdowns/react-implementation/22_github-pages-deployment-plan.md @@ -0,0 +1,295 @@ +# GitHub Pages 자동 배포 계획 + +## 📋 목표 + +GitHub Pages에 자동 배포를 설정하여 `main` 브랜치에 푸시될 때마다 자동으로 배포되도록 구성합니다. + +**배포 링크**: https://jumoooo.github.io/front_7th_chapter2-2/ + +## 🔍 현재 상태 분석 + +### ✅ 이미 구현된 부분 + +1. **Base Path 설정** + - `packages/app/vite.config.ts`: 프로덕션 환경에서 `/front_7th_chapter2-2/` base path 설정 ✅ + - `packages/app/src/constants.js`: `BASE_URL`이 프로덕션에서 `/front_7th_chapter2-2/`로 설정 ✅ + - ✅ **확인 완료**: 배포 링크와 코드의 base path가 일치함 (언더스코어 `_` 사용) + +2. **빌드 스크립트** + - `package.json`에 `gh-pages` 스크립트 존재: `"gh-pages": "pnpm -F @hanghae-plus/shopping build && gh-pages -d ./packages/app/dist"` + - `gh-pages` 패키지가 이미 설치되어 있음 + +3. **404 페이지 처리** + - `packages/app/404.html` 파일 존재 + - Vite 빌드 설정에 404.html이 포함되어 있음 + +### ❌ 미구현 부분 + +1. **GitHub Actions 워크플로우**: 자동 배포를 위한 CI/CD 파이프라인 없음 + +## 📝 작업 계획 + +### 1단계: Base Path 확인 + +#### 1.1 배포 링크 확인 + +- 배포 링크: `https://jumoooo.github.io/front_7th_chapter2-2/` +- 실제 경로: `/front_7th_chapter2-2/` (언더스코어 사용) + +#### 1.2 코드 확인 결과 + +- ✅ `packages/app/vite.config.ts`: 이미 `/front_7th_chapter2-2/`로 올바르게 설정됨 +- ✅ `packages/app/src/constants.js`: 이미 `/front_7th_chapter2-2/`로 올바르게 설정됨 +- **수정 불필요**: Base path가 이미 올바르게 설정되어 있음 + +### 2단계: GitHub Actions 워크플로우 생성 + +#### 2.1 워크플로우 파일 생성 + +- 경로: `.github/workflows/deploy.yml` +- 트리거: `main` 브랜치에 푸시될 때 + +#### 2.2 워크플로우 단계 + +1. **체크아웃**: 소스 코드 체크아웃 +2. **Node.js 설정**: Node.js 22+ 및 pnpm 설정 +3. **의존성 설치**: `pnpm install` +4. **테스트 실행**: + - 단위 테스트: `pnpm test` + - E2E 테스트: `pnpm test:e2e` (선택적, 시간이 오래 걸릴 수 있음) +5. **빌드**: `pnpm -F @hanghae-plus/shopping build` +6. **배포**: `gh-pages`를 사용하여 `gh-pages` 브랜치에 배포 + +#### 2.3 워크플로우 구조 + +```yaml +name: Deploy to GitHub Pages + +on: + push: + branches: + - main + +jobs: + deploy: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + - uses: pnpm/action-setup@v2 + with: + version: 10 + - uses: actions/setup-node@v4 + with: + node-version: 22 + cache: "pnpm" + - run: pnpm install + - run: pnpm test + - run: pnpm -F @hanghae-plus/shopping build + - uses: peaceiris/actions-gh-pages@v3 + with: + github_token: ${{ secrets.GITHUB_TOKEN }} + publish_dir: ./packages/app/dist +``` + +### 3단계: 테스트 검증 + +#### 3.1 로컬 빌드 테스트 + +- `pnpm -F @hanghae-plus/shopping build` 실행 +- `packages/app/dist` 폴더 확인 +- `vite preview`로 로컬에서 빌드 결과 확인 + +#### 3.2 Base Path 테스트 + +- 빌드된 파일의 경로가 올바른지 확인 +- `index.html`의 asset 경로 확인 +- 라우터가 올바른 base path를 사용하는지 확인 + +#### 3.3 테스트 코드 통과 확인 + +- `pnpm test`: 단위 테스트 통과 확인 +- `pnpm test:e2e`: E2E 테스트 통과 확인 (로컬 환경에서) + +### 4단계: 배포 및 검증 + +#### 4.1 초기 배포 + +- GitHub Actions 워크플로우 실행 +- `gh-pages` 브랜치 생성 확인 +- 배포된 사이트 접속하여 기능 확인 + +#### 4.2 기능 검증 + +- 홈 페이지 로드 확인 +- 라우팅 동작 확인 +- 상품 목록 표시 확인 +- 검색 기능 확인 +- 장바구니 기능 확인 + +## ⚠️ 주의사항 + +### 테스트 코드 수정 금지 + +- `e2e/e2e.spec.js`: 수정하지 않음 +- `packages/react/src/__tests__/`: 수정하지 않음 +- 테스트 코드는 기존 그대로 유지 + +### 기존 기능 유지 + +- 모든 기존 기능이 정상 작동해야 함 +- 라우팅, 상태 관리, 이벤트 핸들러 등 모든 기능 유지 + +### Base Path 일관성 + +- ✅ 배포 링크와 코드의 base path가 이미 일치함 (`/front_7th_chapter2-2/`) + +## 📦 필요한 변경 파일 + +### 수정할 파일 + +- 없음 (Base path는 이미 올바르게 설정되어 있음) + +### 생성할 파일 + +1. `.github/workflows/deploy.yml`: GitHub Actions 워크플로우 + +### 수정하지 않을 파일 + +- `e2e/e2e.spec.js`: 수정 금지 +- `packages/react/src/__tests__/`: 수정 금지 +- 기타 테스트 파일: 수정 금지 + +## 🔄 배포 프로세스 + +1. **개발자가 코드 수정 및 커밋** +2. **main 브랜치에 푸시** +3. **GitHub Actions 자동 실행** + - 소스 코드 체크아웃 + - 의존성 설치 + - 테스트 실행 + - 빌드 실행 + - gh-pages 브랜치에 배포 +4. **배포 완료** (약 2-3분 소요) +5. **사이트 접속 확인**: https://jumoooo.github.io/front-7th-chapter2-2/ + +## ✅ 검증 체크리스트 + +- [x] Base path가 올바르게 설정되었는지 확인 (이미 올바르게 설정됨) +- [ ] 로컬 빌드가 성공하는지 확인 +- [ ] 단위 테스트가 통과하는지 확인 +- [ ] E2E 테스트가 통과하는지 확인 (로컬) +- [ ] GitHub Actions 워크플로우가 정상 실행되는지 확인 +- [ ] 배포된 사이트가 정상 작동하는지 확인 +- [ ] 라우팅이 올바르게 작동하는지 확인 +- [ ] 모든 기능이 정상 작동하는지 확인 + +## 👤 사용자가 직접 해야 할 작업 (외부 설정) + +### ⚠️ 중요: 다음 작업들은 코드 수정이 아닌 GitHub 웹사이트에서 직접 설정해야 합니다 + +#### 1. GitHub 저장소 설정 확인 + +1. **GitHub 저장소 접속** + - 저장소 URL: `https://github.com/jumoooo/front-7th-chapter2-2` (또는 실제 저장소 URL) + - 저장소가 존재하고 접근 가능한지 확인 + +2. **저장소 권한 확인** + - Settings > General > Danger Zone에서 저장소 설정 확인 + - Actions 권한이 활성화되어 있는지 확인 + +#### 2. GitHub Pages 설정 + +1. **Settings > Pages 메뉴 접속** + - 저장소의 Settings 탭 클릭 + - 왼쪽 메뉴에서 "Pages" 클릭 + +2. **Source 설정** + - Source: `Deploy from a branch` 선택 + - Branch: `gh-pages` 선택 (워크플로우가 생성한 브랜치) + - Folder: `/ (root)` 선택 + - Save 클릭 + +3. **Custom domain 설정 (선택사항)** + - 필요시 커스텀 도메인 설정 가능 + - 현재는 `jumoooo.github.io/front_7th_chapter2-2/` 사용 + +#### 3. GitHub Actions 권한 설정 + +1. **Settings > Actions > General 접속** + - 저장소의 Settings > Actions > General 메뉴로 이동 + +2. **Workflow permissions 설정** + - "Workflow permissions" 섹션 확인 + - "Read and write permissions" 선택 + - "Allow GitHub Actions to create and approve pull requests" 체크 (필요시) + - Save 버튼 클릭 + +3. **Actions 권한 확인** + - Actions 탭에서 워크플로우가 실행 가능한지 확인 + - 필요시 조직/저장소 레벨에서 Actions가 활성화되어 있는지 확인 + +#### 4. GITHUB_TOKEN 확인 + +- GitHub Actions에서 자동으로 제공되는 `GITHUB_TOKEN` 사용 +- 별도로 생성할 필요 없음 (워크플로우에서 자동 사용) +- 만약 권한 문제가 발생하면: + - Settings > Actions > General에서 권한 확인 + - Personal Access Token 생성 필요 여부 확인 + +#### 5. 초기 배포 확인 + +1. **워크플로우 실행 확인** + - 코드 푸시 후 Actions 탭에서 워크플로우 실행 확인 + - 빌드 및 배포 로그 확인 + +2. **gh-pages 브랜치 확인** + - Code 탭에서 브랜치 목록 확인 + - `gh-pages` 브랜치가 생성되었는지 확인 + - 브랜치에 배포 파일이 올바르게 있는지 확인 + +3. **배포 사이트 접속 확인** + - `https://jumoooo.github.io/front_7th_chapter2-2/` 접속 + - 사이트가 정상적으로 로드되는지 확인 + - 기능이 정상 작동하는지 확인 + +#### 6. 문제 해결 (필요시) + +1. **배포 실패 시** + - Actions 탭에서 실패한 워크플로우 클릭 + - 로그 확인하여 에러 원인 파악 + - 필요시 코드 수정 후 재푸시 + +2. **사이트가 404 에러인 경우** + - GitHub Pages 설정 확인 + - `gh-pages` 브랜치가 올바르게 설정되었는지 확인 + - Base path가 올바른지 확인 + +3. **권한 에러인 경우** + - Settings > Actions > General에서 권한 확인 + - 조직 저장소인 경우 관리자에게 권한 요청 + +## 📌 다음 단계 (작업 순서) + +### 개발자(AI)가 할 작업 + +1. ✅ Base path 확인 완료 (이미 올바르게 설정됨) +2. GitHub Actions 워크플로우 파일 생성 (`.github/workflows/deploy.yml`) +3. 로컬 빌드 및 테스트 검증 + +### 사용자가 할 작업 (외부 설정) + +4. **GitHub 저장소 설정 확인** (위의 "1. GitHub 저장소 설정 확인" 참조) +5. **GitHub Pages 설정** (위의 "2. GitHub Pages 설정" 참조) +6. **GitHub Actions 권한 설정** (위의 "3. GitHub Actions 권한 설정" 참조) + +### 공동 작업 + +7. **코드 푸시 및 배포 테스트** + - 개발자가 코드를 main 브랜치에 푸시 + - 사용자가 Actions 탭에서 워크플로우 실행 확인 + - 사용자가 gh-pages 브랜치 생성 확인 + - 사용자가 배포된 사이트 접속하여 기능 검증 + +8. **배포 검증 및 문제 해결** + - 배포된 사이트 기능 확인 + - 문제 발생 시 위의 "6. 문제 해결" 참조 diff --git a/.cursor/mockdowns/react-implementation/dom-order-issue-analysis.md b/.cursor/mockdowns/react-implementation/dom-order-issue-analysis.md new file mode 100644 index 00000000..53f40c97 --- /dev/null +++ b/.cursor/mockdowns/react-implementation/dom-order-issue-analysis.md @@ -0,0 +1,225 @@ +# DOM 순서 문제 원인 분석 보고서 + +## 🔍 문제 현상 + +- `PageWrapper`의 `

` 내부에서 `header`, `main`, `Footer` 순서로 작성했지만 +- 실제 화면에서는 `Footer`, `header`, `main` 순서로 표시됨 + +## 📊 코드 흐름 분석 + +### 1. 마운트 시 자식 삽입 과정 + +``` +PageWrapper 컴포넌트 렌더링 + ↓ +
요소 마운트 (mountNode) + ↓ +reconcileChildren(dom, [], [header, main, CartModal, Toast, Footer], path) + ↓ +newChildren.forEach((childVNode, index) => { + reconcile(parentDom, null, childVNode, ...) // 각 자식마다 호출 + ↓ + mountNode(parentDom, childVNode, ...) + ↓ + insertInstance(parentDom, newInstance) // DOM에 삽입 +}) + ↓ +재배치 로직 실행 (349-388줄) +``` + +### 2. 문제 발생 지점 + +**`reconcileChildren` 함수 (304줄):** +```typescript +const reconciledInstance = reconcile(parentDom, instanceToReconcile, childVNode, childPath); +``` + +- 마운트 시 `instanceToReconcile = null`이므로 `reconcile` 내부에서 `mountNode`가 호출됨 +- `mountNode`에서 `insertInstance(parentDom, newInstance)`가 호출되어 DOM에 삽입 +- **각 자식이 순차적으로 DOM에 삽입되지만, 순서가 보장되지 않을 수 있음** + +### 3. 재배치 로직의 문제점 + +**현재 재배치 로직 (349-388줄):** +```typescript +for (let i = newInstances.length - 1; i >= 0; i--) { + const currentFirstDom = getFirstDomFromChildren([instance]); + const nextFirstDom = nextInstance ? getFirstDomFromChildren([nextInstance]) : null; + + if (nextFirstDom) { + if (currentFirstDom.nextSibling !== nextFirstDom) { + // 재배치 + const domNodes = getDomNodes(instance); + domNodes.forEach((node) => { + parentDom.insertBefore(node, nextFirstDom); + }); + } + } +} +``` + +**문제점:** +1. **조건 검사 부정확**: `currentFirstDom.nextSibling !== nextFirstDom`만 확인 + - 현재 DOM이 nextFirstDom의 바로 이전 형제가 아니면 재배치 + - 하지만 중간에 다른 노드가 있어도 감지하지 못할 수 있음 + +2. **이미 DOM에 있는 노드 재삽입**: + - `getDomNodes(instance)`로 이미 DOM에 삽입된 노드들을 가져옴 + - `insertBefore`로 다시 삽입하면 자동으로 이동하지만, 순서가 여전히 잘못될 수 있음 + +3. **역순 순회의 문제**: + - 역순으로 순회하면서 재배치하는데, 이미 잘못된 순서로 삽입된 상태에서 재배치하면 순서가 더 꼬일 수 있음 + +## 🎯 가능성 높은 원인들 (우선순위 순) + +### 1. ⚠️ **재배치 로직의 조건 검사 부정확** (가장 가능성 높음) + +**현재 로직:** +```typescript +if (currentFirstDom.nextSibling !== nextFirstDom) { + // 재배치 +} +``` + +**문제:** +- `nextSibling`만 확인하므로, 현재 DOM이 nextFirstDom의 바로 이전 형제가 아니면 재배치 +- 하지만 이미 올바른 위치에 있지만 중간에 다른 노드가 있어도 재배치를 시도할 수 있음 +- 또는 이미 잘못된 위치에 있어도 조건이 맞지 않아 재배치되지 않을 수 있음 + +**해결책:** +- 현재 DOM이 nextFirstDom의 이전 형제인지 정확히 확인해야 함 +- 또는 현재 DOM의 위치를 더 정확하게 검증해야 함 + +### 2. ⚠️ **마운트 시 자식 삽입 순서 보장 부족** + +**현재 흐름:** +- `reconcileChildren`에서 각 자식을 `reconcile`로 처리 +- 각 `reconcile` 내부에서 `mountNode`가 호출되어 `insertInstance`로 DOM에 삽입 +- 이때 순서가 보장되지 않을 수 있음 + +**문제:** +- 각 자식이 독립적으로 DOM에 삽입되므로 순서가 보장되지 않을 수 있음 +- 재배치 로직이 실행되지만, 이미 잘못된 순서로 삽입된 상태 + +**해결책:** +- 마운트 시 자식들을 DOM에 삽입하기 전에 순서를 보장해야 함 +- 또는 재배치 로직을 더 정확하게 수정해야 함 + +### 3. ⚠️ **insertInstance의 anchor 사용 문제** + +**현재 로직:** +```typescript +export const insertInstance = (parentDom, instance, anchor = null) => { + const domNodes = getDomNodes(instance); + domNodes.forEach((node) => { + if (anchor) { + parentDom.insertBefore(node, anchor); + } else { + parentDom.appendChild(node); + } + }); +}; +``` + +**문제:** +- 마운트 시 `anchor`가 `null`이므로 `appendChild`를 사용 +- `appendChild`는 항상 마지막에 추가하므로, 순서가 보장되지 않을 수 있음 + +**해결책:** +- 마운트 시에도 anchor를 사용하여 순서를 보장해야 함 + +### 4. ⚠️ **재배치 로직의 역순 순회 문제** + +**현재 로직:** +- 역순으로 순회하면서 재배치 (i = newInstances.length - 1부터 0까지) +- 각 인스턴스에 대해 nextFirstDom을 anchor로 사용 + +**문제:** +- 역순으로 순회하면서 재배치하는데, 이미 잘못된 순서로 삽입된 상태에서 재배치하면 순서가 더 꼬일 수 있음 + +**해결책:** +- 순서대로 순회하면서 재배치하거나 +- 재배치 로직을 더 정확하게 수정해야 함 + +## 🔧 해결 방안 제안 + +### 방안 1: 재배치 로직 개선 (권장) + +재배치 로직의 조건을 더 정확하게 수정: + +```typescript +// 현재 DOM이 nextFirstDom의 이전 형제인지 정확히 확인 +let isInCorrectPosition = false; +if (nextFirstDom) { + let sibling = nextFirstDom.previousSibling; + while (sibling) { + if (sibling === currentFirstDom) { + isInCorrectPosition = true; + break; + } + sibling = sibling.previousSibling; + } + + if (!isInCorrectPosition) { + // 재배치 + } +} +``` + +### 방안 2: 마운트 시 순서 보장 + +마운트 시 자식들을 DOM에 삽입하기 전에 순서를 보장: + +```typescript +// 모든 자식을 먼저 reconcile하고, 그 다음 순서대로 DOM에 삽입 +const children = childNodes.map((childVNode, index) => + reconcile(dom, null, childVNode, createChildPath(path, childVNode.key ?? null, index)), +); + +// 순서대로 DOM에 삽입 +children.forEach((child, index) => { + if (child) { + const prevChild = index > 0 ? children[index - 1] : null; + const anchor = prevChild ? getFirstDomFromChildren([prevChild]) : null; + insertInstance(dom, child, anchor); + } +}); +``` + +### 방안 3: 재배치 로직을 순서대로 순회 + +역순이 아닌 순서대로 순회하면서 재배치: + +```typescript +// 순서대로 순회하면서 재배치 +for (let i = 0; i < newInstances.length; i++) { + const instance = newInstances[i]; + if (!instance) continue; + + const currentFirstDom = getFirstDomFromChildren([instance]); + if (!currentFirstDom) continue; + + // 이전 인스턴스의 마지막 DOM 노드를 anchor로 사용 + const prevInstance = i > 0 ? newInstances[i - 1] : null; + const prevLastDom = prevInstance ? getLastDomFromChildren([prevInstance]) : null; + + if (prevLastDom) { + // prevLastDom 다음에 있어야 함 + if (currentFirstDom.previousSibling !== prevLastDom) { + // 재배치 + } + } else { + // 첫 번째 자식이어야 함 + if (currentFirstDom.previousSibling !== null) { + // 재배치 + } + } +} +``` + +## 📝 다음 단계 + +1. 재배치 로직의 조건을 더 정확하게 수정 +2. 마운트 시 자식 삽입 순서를 보장하는 로직 추가 +3. 테스트 실행하여 문제 해결 확인 + diff --git a/.cursor/mockdowns/react-implementation/footer-order-issue-analysis.md b/.cursor/mockdowns/react-implementation/footer-order-issue-analysis.md new file mode 100644 index 00000000..aeb51c5a --- /dev/null +++ b/.cursor/mockdowns/react-implementation/footer-order-issue-analysis.md @@ -0,0 +1,275 @@ +# Footer 순서 문제 원인 분석 보고서 + +## 🔍 문제 현상 + +- `PageWrapper.jsx`에서 `Footer` 태그를 `Toast` 아래로 옮기면 +- `Footer`가 맨 위로 올라가는 오류 발생 + +## 📊 현재 코드 구조 + +### PageWrapper.jsx 자식 순서 + +**현재 (정상 작동):** + +```jsx +
...
+
...
+