원문: https://github.com/facebook/astryx/wiki/Component-Lifecycle · 번역 기준: 2026-09-03
"이런 컴포넌트가 필요하다"에서 "프로덕션 품질의 상태를 유지한다"까지의 전체 여정입니다. 세 개의 phase가 있고, 각각 고유의 protocol을 가지며, 전 과정에서 품질을 높게 유지하는 공유 도구들로 연결됩니다.
┌─────────────────────────────────────────────────────────────┐
│ │
│ SPECIFY ──────► BUILD ──────► HARDEN │
│ │
│ What to build Build it Make it correct, │
│ and why right complete, and polished │
│ │
│ ◄──────────────────────────────────────────────┘ │
│ Findings that exceed hardening scope │
│ route back to specification │
│ │
├─────────────────────────────────────────────────────────────┤
│ │
│ MAINTAIN (ongoing) │
│ Nightly auditor enforces conventions as the │
│ system evolves — catches drift before it ships │
│ │
└─────────────────────────────────────────────────────────────┘
모든 것이 새 컴포넌트를 필요로 하지는 않습니다. spec protocol을 시작하기 전에 다음 질문에 답하세요:
| 질문 | 예라면... |
|---|---|
| 기존 컴포넌트를 조합해서 해결할 수 있는가? | 대신 sandbox에 recipe/example을 작성하세요 |
| 필요가 한 제품에만 해당하는 도메인 특화인가? | 그것은 recipe이지 core 컴포넌트가 아닙니다 |
| 이미 존재하는 것의 시각적 variation인가? | 먼저 테마나 xstyle override를 탐색하세요 |
| 기존 컴포넌트에 동작을 추가하는가? | prop 추가를 고려하세요 (여전히 spec protocol이 필요하지만 더 가볍습니다) |
이 모든 질문의 답이 "아니오"라면 — 새 컴포넌트를 만드는 것입니다. 계속 읽으세요.
뛰어들기 전에 다음을 숙지하세요:
목표: 무엇을, 왜 만들지, API가 어떤 모습이어야 하는지를 결정합니다 — 의견이 아니라 근거에 기반해서.
Protocol: Component Specification Protocol