Files

T

Antigravity Agent 9148c358d0 docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거

Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.

2026-07-05 00:33:48 +09:00

2.9 KiB

Raw Blame History

id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases

title

React StrictMode 의도적 이중 실행

StrictMode 는 dev 환경에서 effect / 컴포넌트 / state initializer 를 의도적으로 두 번 실행해 cleanup 누락 / 비순수 코드를 노출. production 에선 한 번. "두 번 실행되는 게 비정상이다" 가 아니라 "두 번 실행되어도 같아야 한다" 가 맞음.

📖 핵심 개념

StrictMode 가 두 번 실행하는 것: function component body, useEffect (mount → cleanup → mount), useState/useReducer initializer, useMemo factory.

목적: idempotent + cleanup 검증. 한 번 실행과 두 번 실행 결과가 같으면 향후 React 의 offscreen 렌더 / 재마운트 최적화에 안전.

💻 코드 패턴

// ❌ 두 번 실행 시 사고
useEffect(() => {
  socket.connect(); // 두 번 호출 → 두 connection
}, []);

// ✅ cleanup 으로 idempotent
useEffect(() => {
  socket.connect();
  return () => socket.disconnect();
}, []);

// ✅ initializer 도 pure
const [counter] = useState(() => loadFromStorage()); // OK if pure read
const [id] = useState(() => Math.random()); // ❌ 두 번 실행되면 다른 id
const [id] = useState(() => crypto.randomUUID()); // 같은 문제
// → useRef 또는 lazy ref pattern
const idRef = useRef<string>();
if (idRef.current === undefined) idRef.current = crypto.randomUUID();

🤔 의사결정 기준

상황	StrictMode-friendly 패턴
WebSocket / EventSource 연결	connect/disconnect cleanup
외부 라이브러리 init (chart, map)	init/destroy cleanup
analytics ping (mount 시 1회)	useEffect 안 쓰고 onClick / 라우터 이벤트로
한 번만 실행되는 unique id	useRef 패턴
비싼 fetch (두 번 호출 부담)	React Query / SWR — 자체 dedup

❌ 안티패턴

StrictMode 끄기: 단기 회피. 사고 잠재. 켜놓고 root cause 수정.
if (didMountRef.current) return; didMountRef.current = true;: hack. 진짜 문제는 cleanup 미흡.
production 에서도 같은 문제 해결되었다고 가정: prod 는 한 번 실행 — dev StrictMode 가 미래의 unmount/remount 시뮬.
useEffect 의 cleanup 안에서 또 mutation: cleanup 도 idempotent.

🤖 LLM 활용 힌트

"StrictMode 가정. effect 가 두 번 실행되어도 안전한가?" 라고 매번 점검.
외부 라이브러리 init 코드는 cleanup destroy 와 페어로.

2.9 KiB Raw Blame History