docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
Antigravity Agent
@@ -1,11 +1,11 @@
|
||||
# Index: Topics > 01_Frontend_Mastery
|
||||
|
||||
## 📝 Documents
|
||||
- [[React_Clean_Code_Best_Practices]]
|
||||
- [[React_Hooks_Deep_Dive]]
|
||||
- [[React_Mental_Model]]
|
||||
- [[React_Performance_Optimization]]
|
||||
- [[React_State_Management_Strategy]]
|
||||
- [[React_Testing_Strategy]]
|
||||
- [[TypeScript_Type_Safety]]
|
||||
- [[WebWorker_Performance]]
|
||||
- [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]]
|
||||
- [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]]
|
||||
- [[React_Mental_Model|React_Mental_Model]]
|
||||
- [[React_Performance_Optimization|React_Performance_Optimization]]
|
||||
- [[React_State_Management_Strategy|React_State_Management_Strategy]]
|
||||
- [[React_Testing_Strategy|React_Testing_Strategy]]
|
||||
- [[TypeScript_Type_Safety|TypeScript_Type_Safety]]
|
||||
- [[WebWorker_Performance|WebWorker_Performance]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 클린 코드 및 개발 에티켓
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Clean Code, Etiquette, Best Practice, Readable Code]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Clean_Code_Best_Practices]] (리액트 클린 코드)
|
||||
# [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]] (리액트 클린 코드)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 가독성 좋은 코드는 '컴퓨터'가 이해하는 코드가 아니라, '나중에 이 코드를 고칠 동료(혹은 미래의 나)'가 숨 쉬듯 읽어내려갈 수 있는 코드다.
|
||||
@@ -16,7 +16,7 @@ created: 2026-04-20
|
||||
- **Props Destructuring (구조 분해 할당)**:
|
||||
- `props.user.name` 처럼 경로를 길게 쓰는 대신, 함수의 인자 단계에서 `{ user: { name } }` 처럼 분해하라. 코드가 숨을 쉬기 시작한다.
|
||||
- **Explicit Naming (명시적 네이밍)**:
|
||||
- 핸들러 함수는 `handle[Action]` (예: `handle[[Search]]`), 비즈니스 함수는 `on[Action]` (예: `onSearchSubmit`)으로 구분하여 책임 소재를 명확히 한다.
|
||||
- 핸들러 함수는 `handle[Action]` (예: `handle[[Search|Search]]`), 비즈니스 함수는 `on[Action]` (예: `onSearchSubmit`)으로 구분하여 책임 소재를 명확히 한다.
|
||||
- **조건부 렌더링 에티켓**:
|
||||
- `&&` 연산자 대신 삼항 연산자(`? :`)를 권장한다. 특히 `0 && <Component />` 시 화면에 숫자 0이 출력되는 대참사를 방지하기 위함이다.
|
||||
|
||||
@@ -24,5 +24,5 @@ created: 2026-04-20
|
||||
- 과도한 추상화는 오히려 독이다. 코드가 3줄인데 함수 5개로 쪼개는 것은 가독성을 해친다. '직관성'이 '분리'보다 우선할 때가 있음을 명심하라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Collaboration_Governance]] , [[System_Debugging_Protocol]]
|
||||
- Foundation: [[React_Mental_Model]]
|
||||
- Related: [[Collaboration_Governance|Collaboration_Governance]] , [[System_Debugging_Protocol|System_Debugging_Protocol]]
|
||||
- Foundation: [[React_Mental_Model|React_Mental_Model]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 훅(Hooks) 심층 분석 및 활용
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [React, Hooks, useEffect, Custom Hooks]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Hooks_Deep_Dive]] (리액트 훅 심화)
|
||||
# [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]] (리액트 훅 심화)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 훅은 단순히 함수를 재사용하는 것이 아니라, 컴포넌트의 생애 주기와 논리를 '선언적'으로 결합하는 고도의 동기화 기제다.
|
||||
@@ -14,7 +14,7 @@ created: 2026-04-20
|
||||
- **useEffect의 올바른 관점**:
|
||||
- "마운트될 때 실행"이라는 라이프사이클 사고방식에서 벗어나라. `useEffect`는 **의존성 배열의 값과 컴포넌트 외부 시스템(API, DOM 등)을 동기화**하는 작업이다.
|
||||
- **Custom Hooks (추상화의 꽃)**:
|
||||
- 복잡한 비즈니스 로직(예: 데이터 페칭, 타이머 관리)을 `useMy[[Logic]]` 처럼 따로 빼내어 컴포넌트는 오직 UI 선언에만 집중하게 만든다. 이것이 컴포넌트의 가독성을 폭발시키는 비결이다.
|
||||
- 복잡한 비즈니스 로직(예: 데이터 페칭, 타이머 관리)을 `useMy[[Logic|Logic]]` 처럼 따로 빼내어 컴포넌트는 오직 UI 선언에만 집중하게 만든다. 이것이 컴포넌트의 가독성을 폭발시키는 비결이다.
|
||||
- **Rules of Hooks**:
|
||||
- 반드시 함수의 최상위에서만 호출되어야 한다. 그래야 리액트가 훅의 상태를 유한 상태 머신처럼 정확한 순서로 관리할 수 있다.
|
||||
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- `useEffect` 내에서 무분별하게 상태를 업데이트하면 무한 루프나 성능 저하가 발생한다. 가능하면 `useMemo`나 `useCallback`으로 계산 결과를 캐싱하거나, 상태 업데이트 로직을 `useReducer`로 위임하라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[React_Performance_Optimization]] , [[React_[[State]]_[[Management]]_Strategy]]
|
||||
- Context: [[WebWorker_Performance]]
|
||||
- Related: [[React_Performance_Optimization|React_Performance_Optimization]] , React_State_Management_Strategy
|
||||
- Context: [[WebWorker_Performance|WebWorker_Performance]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 핵심 멘탈 모델 (UI as a Function of [[State]])
|
||||
category: Software [[Architecture]]
|
||||
title: 리액트 핵심 멘탈 모델 (UI as a Function of [[State|State]])
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [React, State, Mental Model, Immutability]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Mental_Model]] (리액트 멘탈 모델)
|
||||
# [[React_Mental_Model|React_Mental_Model]] (리액트 멘탈 모델)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 리액트 개발은 DOM을 '조작(Manipulate)'하는 것이 아니라, 데이터의 흐름인 '상태(State)'를 정의하고 그 결과물을 화면에 '선언(Declare)'하는 과정이다.
|
||||
@@ -14,13 +14,13 @@ created: 2026-04-20
|
||||
- **UI = f(State)**:
|
||||
- 화면은 상태의 결과값이어야 한다. 명령형(Imperative)으로 "이 버튼의 글자를 바꿔라"라고 하는 순간 리액트의 질서는 무너진다. 오직 상태를 바꾸고 리액트가 알아서 그리게 하라.
|
||||
- **Immutability (불변성)**:
|
||||
- 리액트는 객체의 주소값이 변할 때만 렌더링을 시도한다. `arr.push(1)`이 아니라 `setArr([...arr, 1])`처럼 **새로운 원본**을 복제하여 가상 DOM([[Virtual DOM]])이 효율적으로 동작하게 돕는다.
|
||||
- 리액트는 객체의 주소값이 변할 때만 렌더링을 시도한다. `arr.push(1)`이 아니라 `setArr([...arr, 1])`처럼 **새로운 원본**을 복제하여 가상 DOM([[Virtual DOM|Virtual DOM]])이 효율적으로 동작하게 돕는다.
|
||||
- **Virtual DOM Diffing**:
|
||||
- 리액트는 실제 DOM을 직접 건드리기 전에 메모리상의 가상 DOM에서 이전 상태와 비교(Diffing)하여, 꼭 필요한 부분만 실제 화면에 반영(Commit)한다. 이것이 고성능 웹의 비결이다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 불변성 유지를 위해 매번 거대한 객체를 복사하는 것은 때로 손해다. `Immer` 같은 라이브러리를 쓰거나, 상태의 크기를 작게 쪼개어([[Normalization]]) 업데이트 비용을 최소화하는 전략이 중급 개발자의 역량이다.
|
||||
- 불변성 유지를 위해 매번 거대한 객체를 복사하는 것은 때로 손해다. `Immer` 같은 라이브러리를 쓰거나, 상태의 크기를 작게 쪼개어([[Normalization|Normalization]]) 업데이트 비용을 최소화하는 전략이 중급 개발자의 역량이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[React_Hooks_Deep_Dive]] , [[Component_Design_Patterns]]
|
||||
- Foundation: [[System_Protocol_Standard]]
|
||||
- Related: [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]] , [[Component_Design_Patterns|Component_Design_Patterns]]
|
||||
- Foundation: [[System_Protocol_Standard|System_Protocol_Standard]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 렌더링 최적화 전략
|
||||
category: Software [[Architecture]]
|
||||
tags: [Performance, Memoization, React.memo, [[Optimization]]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Performance, Memoization, React.memo, [[Optimization|Optimization]]]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Performance_Optimization]] (리액트 성능 최적화)
|
||||
# [[React_Performance_Optimization|React_Performance_Optimization]] (리액트 성능 최적화)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 가장 빠른 렌더링은 '하지 않는 렌더링'이다. 필요 없는 업데이트를 차단하고 데이터가 흐를 때만 화면이 출렁이게 하라.
|
||||
@@ -17,12 +17,12 @@ created: 2026-04-20
|
||||
- **useCallback**: 함수 객체의 변동을 막아 자식 컴포넌트의 불필요한 리렌더링을 방지한다.
|
||||
- **Windowing (가상 리스트)**:
|
||||
- 수천 개의 리스트 아이템이 있어도 사용자의 눈에 보이는 수십 개만 실제 DOM에 렌더링한다. (예: `react-window`, `react-virtualized`).
|
||||
- **상태의 위치 선정 ([[State]] Colocation)**:
|
||||
- **상태의 위치 선정 ([[State|State]] Colocation)**:
|
||||
- 전역 상태가 바뀔 때마다 앱 전체가 들썩이지 않게 하라. 상태는 그것을 사용하는 가장 하위 컴포넌트 근처로 내려라.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 모든 곳에 `memo`를 쓰는 것은 메모리 낭비다. 리액트의 기본 렌더링 성능은 이미 매우 뛰어나다. 병목 현상이 '실제로 관측'될 때만 최적화를 적용하는 것이 원칙이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[WebWorker_Performance]] , [[System_Debugging_Protocol]]
|
||||
- Foundation: [[React_Mental_Model]]
|
||||
- Related: [[WebWorker_Performance|WebWorker_Performance]] , [[System_Debugging_Protocol|System_Debugging_Protocol]]
|
||||
- Foundation: [[React_Mental_Model|React_Mental_Model]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 전략적 상태 관리 가이드 (Global & Server [[State]])
|
||||
category: Software [[Architecture]]
|
||||
tags: [State [[Management]], React Query, SSOT, Architecture]
|
||||
title: 전략적 상태 관리 가이드 (Global & Server [[State|State]])
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [State [[Management|Management]], React Query, SSOT, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_State_Management_Strategy]] (상태 관리 전략)
|
||||
# [[React_State_Management_Strategy|React_State_Management_Strategy]] (상태 관리 전략)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 상태는 '어디든' 있을 수 있지만, '아무데나' 있어서는 안 된다. 상태의 생명주기와 전파 범위에 따라 명확한 거주지를 결정하라.
|
||||
@@ -21,8 +21,8 @@ created: 2026-04-20
|
||||
- 다른 상태로부터 계산될 수 있는 값(예: `firstName`+`lastName` = `fullName`)은 절대 '상태'로 만들지 마라. 렌더링 시점에 계산하는 것이 정합성 유지의 핵심이다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 무조건적인 전역 상태 지상주의는 '[[Prop Drilling]]'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라.
|
||||
- 무조건적인 전역 상태 지상주의는 '[[Prop Drilling|Prop Drilling]]'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Single_Source_of_Truth]] , [[API_Communication_Patterns]]
|
||||
- Foundation: [[React_Hooks_Deep_Dive]]
|
||||
- Related: [[Single_Source_of_Truth|Single_Source_of_Truth]] , [[API_Communication_Patterns|API_Communication_Patterns]]
|
||||
- Foundation: [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 리액트 애플리케이션 테스트 전략
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[Testing]], Vitest, RTL, Unit Test, QA]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [[Testing|[Testing]], Vitest, RTL, Unit Test, QA]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[React_Testing_Strategy]] (리액트 테스트 전략)
|
||||
# [[React_Testing_Strategy|React_Testing_Strategy]] (리액트 테스트 전략)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 테스트는 '내가 짠 코드'를 검사하는 것이 아니라, '사용자가 경험할 가치'가 유지되고 있는지 수학적으로 증명하는 보험이다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- 테스트 커버리지 100% 집착은 생산성을 갉아먹는다. 비즈니스 핵심 로직과 사용자가 가장 많이 쓰는 '메인 시나리오'부터 견고하게 보호하는 지혜가 필요하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[System_Debugging_Protocol]] , [[Reliability_Safety_First]]
|
||||
- Tool: [[Modern_Environment_Ecosystem]]
|
||||
- Related: [[System_Debugging_Protocol|System_Debugging_Protocol]] , [[Reliability_Safety_First|Reliability_Safety_First]]
|
||||
- Tool: [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 타입스크립트 기반의 안정적 개발 (Type Safety)
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [TypeScript, Interface, Type Safety, Generic]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[TypeScript_Type_Safety]] (타입스크립트 정석)
|
||||
# [[TypeScript_Type_Safety|TypeScript_Type_Safety]] (타입스크립트 정석)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 타입스크립트는 당신을 귀찮게 하는 '잔소리꾼'이 아니라, 런타임 에러라는 '낭떠러지' 앞에서 당신을 붙잡아주는 '생명줄'이다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- `any`를 남발하는 순간 타입스크립트의 모든 이점은 사라진다. 차라리 `unknown`을 쓰고 타입을 좁히는(Narrowing) 방식을 택하라. 타입 정의에 너무 많은 시간을 뺏기는 '타입 헬(Type Hell)'을 경계하고 적절한 타협점을 찾아라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[React_Clean_Code_Best_Practices]] , [[React_Hooks_Deep_Dive]]
|
||||
- Foundation: [[System_Protocol_Standard]]
|
||||
- Related: [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]] , [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]]
|
||||
- Foundation: [[System_Protocol_Standard|System_Protocol_Standard]]
|
||||
|
||||
@@ -10,9 +10,9 @@ created: 2026-04-20
|
||||
## 🎯 개요 (Overview)
|
||||
실시간 상태 변화가 매우 빈번한 애플리케이션(예: 게임, 시뮬레이션)에서 UI 스레드와 복잡한 연산 로직을 분리하여 **프레임 드롭(Jank)**을 방지하는 아키텍처 설계 기법입니다.
|
||||
|
||||
## 🚀 주요 원칙 (Key [[Principles]])
|
||||
## 🚀 주요 원칙 (Key [[Principles|Principles]])
|
||||
- **스레드 분리 (Thread Isolation)**: 무거운 계산은 백그라운드 스레드(Web Worker)에서 수행하고, 메인 스레드는 렌더링에만 집중합니다.
|
||||
- **메시징 기반 통신 (Messaging [[Architecture]])**: `postMessage`와 `onmessage`를 통해 비동기적으로 데이터를 주고받아 결합도를 낮춥니다.
|
||||
- **메시징 기반 통신 (Messaging [[Architecture|Architecture]])**: `postMessage`와 `onmessage`를 통해 비동기적으로 데이터를 주고받아 결합도를 낮춥니다.
|
||||
|
||||
## 💡 레슨 런 (Lesson Learned)
|
||||
> [!IMPORTANT]
|
||||
@@ -20,5 +20,5 @@ created: 2026-04-20
|
||||
> 복잡한 물리 계산이나 루프가 UI 응답성을 해치지 않도록, 연산 엔진을 완전히 별도의 스레드로 격리하는 것이 부드러운 UX의 핵심입니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[Systemic_Simulation_Principles]]
|
||||
- [[Separation_of_Concerns|Separation_of_Concerns]]
|
||||
- [[Systemic_Simulation_Principles|Systemic_Simulation_Principles]]
|
||||
|
||||
Reference in New Issue
Block a user