9148c358d0
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 폴더 제거.
3.1 KiB
3.1 KiB
id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases
| id | title | category | status | source_trust_level | verification_status | created_at | updated_at | tags | tech_stack | applied_in | aliases | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| react-context-api-misuse | Context API 잘못 쓰기 | Coding | draft | B | conceptual | 2026-05-09 | 2026-05-09 |
|
|
|
Context API 잘못 쓰기
Context 는 자주 안 바뀌는 의존성 주입 도구지 글로벌 상태 매니저가 아니다. 자주 바뀌는 값을 한 Context 에 넣으면 모든 소비자가 매번 재렌더.
📖 핵심 개념
- 적합: theme, locale, auth user, feature flags, DI(API client).
- 부적합: 자주 변하는 list, 입력 값, 폼 state. → Zustand / Redux / Jotai.
- 변화 빈도와 소비자 수가 동시에 크면 split.
💻 코드 패턴
Split by frequency
const StaticContext = createContext({ apiClient, theme }); // 거의 안 바뀜
const PresenceContext = createContext({ onlineUsers }); // 자주 바뀜
<StaticContext.Provider value={static}>
<PresenceContext.Provider value={presence}>
{children}
</PresenceContext.Provider>
</StaticContext.Provider>
Selector hook
function useUserName() {
const { user } = useContext(AuthContext);
return user.name; // 그래도 user 객체가 바뀌면 모든 소비자 재렌더
}
// 진짜 selector 가 필요하면 zustand 또는 use-context-selector 라이브러리.
Provider value 안정화
function AuthProvider({ children }) {
const [user, setUser] = useState(null);
const value = useMemo(() => ({ user, setUser }), [user]); // 매 렌더 새 객체 방지
return <AuthContext.Provider value={value}>{children}</AuthContext.Provider>;
}
🤔 의사결정 기준
| 데이터 성격 | Context | 외부 store |
|---|---|---|
| 정적 설정 (theme, locale) | ✅ | ❌ |
| 인증 user | ✅ | OK either |
| 실시간 presence / cursor | ❌ | ✅ |
| Form state | ❌ | react-hook-form |
| 캐시된 서버 데이터 | ❌ | React Query / SWR |
| UI 상태 (modal open, selection) | ✅ (좁은 영역) | ✅ |
❌ 안티패턴
- value 가 매 렌더 새 객체: 모든 소비자 재렌더. useMemo / useState 결과 그대로.
- 한 Context 에 모든 글로벌 상태: GodContext. split 또는 store.
- deeply nested Provider hell (10단계+): 드릴링이 더 나을 수도. 또는 store 통합.
- Context 안의 Date/Map/Set 직접 mutate: 소비자에게 변경 안 알림. 새 인스턴스 반환.
- default value 에 throw 안 던지기: Provider 잊으면 silent default. 안전하게:
const ctx = useContext(MyContext); if (!ctx) throw new Error('useMyContext must be used within MyProvider');
🤖 LLM 활용 힌트
- 상태 라이브러리 선택지 명시: "이 데이터는 Context vs Zustand vs React Query 중 어디?"
- LLM이 큰 글로벌 state 에 Context 만 쓰려고 하면 store 권유.