docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
# [[Component-Based Design]]
|
||||
# [[Component-Based Design|Component-Based Design]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
컴포넌트 기반 디자인(Component-Based Design)은 사용자 인터페이스를 재사용 가능하고 이식성이 뛰어나며 예측 가능한 모듈식 구성 요소로 구축하는 아키텍처 접근 방식입니다 [1, 2]. 이는 거대한 단일 컴포넌트를 구성하는 방식에서 벗어나, 조합(Composition)을 통해 레이아웃과 동작을 조립함으로써 '프롭 드릴링(prop drilling)'과 숨겨진 결합도를 줄입니다 [3-5]. 단일 책임 원칙과 명시적인 API 계약을 준수함으로써, 변화하는 요구사항에 유연하게 적응하고 확장할 수 있는 확장성 높은 UI 시스템을 구축하는 데 핵심적인 역할을 합니다 [6-8].
|
||||
@@ -15,8 +15,8 @@
|
||||
- **디자인 토큰(Design Tokens) 바인딩**: 컴포넌트는 하드코딩된 리터럴 값(예: `#dc2222`)을 피하고 디자인 토큰(예: `color.error`)을 참조하여 바인딩해야 합니다 [24, 25]. 이를 통해 간격, 색상, 타이포그래피 등의 디자인 요소가 변경될 때 시스템 전체에 일관된 업데이트가 자동으로 반영됩니다 [24].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Atomic Design]], [[Compound Components]], [[Headless Components]], [[Design Tokens]], [[Feature-Sliced Design]]
|
||||
- **Projects/Contexts:** [[Uber Base Web]], [[Shopify Polaris]], [[Radix UI]]
|
||||
- **Related Topics:** [[Atomic Design|Atomic Design]], [[Compound Components|Compound Components]], [[Headless Components|Headless Components]], [[Design Tokens|Design Tokens]], [[Feature-Sliced Design|Feature-Sliced Design]]
|
||||
- **Projects/Contexts:** [[Uber Base Web|Uber Base Web]], [[Shopify Polaris|Shopify Polaris]], [[Radix UI|Radix UI]]
|
||||
- **Contradictions/Notes:** 원자적 설계(Atomic Design)는 시각적 일관성을 유지하는 데 효과적이지만, 복잡한 비즈니스 로직을 포함하는 컴포넌트를 엄격한 범주에 억지로 맞출 때 구조적 한계에 부딪힐 수 있으므로 실무에서는 기능(Feature) 기반 구조와 결합하여 사용하는 것이 권장됩니다 [26, 27]. 또한, 복합 컴포넌트 패턴은 소비자에게 막강한 유연성을 제공하지만, 너무 많은 자유를 허용하면 일관된 UI나 접근성이 훼손될 수 있으므로 디자인 시스템 차원에서 안전한 구성 경계(composition boundaries)를 문서화하는 것이 필수적입니다 [28, 29].
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user