docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
Antigravity Agent
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-F2362F
|
||||
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
|
||||
category: "10_Wiki/💡 Topics/Design & Experience"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 프론트엔드 컴포넌트 설계"
|
||||
---
|
||||
|
||||
# [[프론트엔드 컴포넌트 설계]]
|
||||
# [[프론트엔드 컴포넌트 설계|프론트엔드 컴포넌트 설계]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 프론트엔드 컴포넌트 설계는 웹 개발에서 특정 기능이나 UI 요소를 구현하기 위해 HTML 구조, CSS 스타일, JavaScript 동작을 하나의 기능적 단위로 묶어 다루는 개발 방식입니다 [1]. 기존의 역할 중심 분리에서 기능 중심의 모듈화로 패러다임이 전환되면서 코드의 재사용성을 높이고 독립적인 테스트를 가능하게 했습니다 [1, 2]. 하지만 프로젝트 규모가 커짐에 따라 발생하는 컴포넌트의 비대화와 강한 결합도를 해결하기 위해, 다시 계층을 나누고 관심사를 분리하는 고도화된 설계 원칙이 요구됩니다 [3, 4].
|
||||
@@ -34,11 +34,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 프론트엔드 컴포넌트
|
||||
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[관심사의 분리 (SoC)]], [[단일 책임 원칙 (SRP)]], [[아토믹 디자인 패턴 (Atomic Design Pattern)]], [[단방향 데이터 흐름]], [[FSD (Feature-Sliced Design)]]
|
||||
- **Projects/Contexts:** [[대규모 프론트엔드 애플리케이션 아키텍처 구축 및 리팩토링]]
|
||||
- **Related Topics:** [[관심사의 분리 (SoC)|관심사의 분리 (SoC)]], [[단일 책임 원칙 (SRP)|단일 책임 원칙 (SRP)]], 아토믹 디자인 패턴 (Atomic Design Pattern), 단방향 데이터 흐름, [[FSD (Feature-Sliced Design)|FSD (Feature-Sliced Design)]]
|
||||
- **Projects/Contexts:** 대규모 프론트엔드 애플리케이션 아키텍처 구축 및 리팩토링
|
||||
- **Contradictions/Notes:** 소스에서는 시각적 형태가 비슷하다고 무작정 동일한 컴포넌트로 묶는 것을 프론트엔드 개발자들이 흔히 하는 실수로 지적합니다. 데이터(도메인)가 다를 경우 결합도가 급증하여 오히려 유지보수성이 저해되므로, UI 컴포넌트와 도메인 컴포넌트를 명확히 분리해야 한다고 강조합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-18*
|
||||
- Raw Source: [[00_Raw/2026-04-20/프론트엔드 컴포넌트 설계.md]]
|
||||
- Raw Source: 00_Raw/2026-04-20/프론트엔드 컴포넌트 설계.md
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user