7.9 KiB
title, source_type, url, archive_url, related_branches, related_projects, tags, created
| title | source_type | url | archive_url | related_branches | related_projects | tags | created | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| React Official Docs — Quick Start (Component Model) | official-doc | https://react.dev/learn |
|
|
2026-07-18 |
React Official Docs — Quick Start (Component Model)
Layer:
raw/— 외부 자료(공식 문서)의 원문 발췌·출처 기록.
source_type 허용값
official-doc— React 공식 문서 (react.dev, Meta 유지보수)
Parent / 활용 branch (필수, 최소 1개+)
특정 branch 없이 foundational 조사로 수집한 경우:
- raw/project-notes/ca-skeleton-frontend-operational-contract — component-based SPA skeleton 을 만들 UI 기술로 React 를 채택하는 결정("프레임워크 / 기술 결정" §6)의 초기 근거 자료. component 모델(함수형 컴포넌트, JSX, props/state 로 데이터 전달)이 skeleton 의 컴포넌트 구성 방식을 규정.
출처 / Source
- 원본 URL: https://react.dev/learn
- 아카이브 URL: (미확보)
- 저자 / 조직: Meta (React core team) — react.dev 공식 문서
- 발행일: (react.dev 는 지속 갱신되는 living doc — 발행일 명시 없음)
- 마지막 확인일: 2026-07-18
왜 저장했는지 / Why archived
ca-skeleton-frontend 프로젝트가 client-only SPA(서버 런타임 없음) 스켈레톤을 만들 때 React 의 컴포넌트 모델(함수형 컴포넌트가 markup 반환, 컴포넌트 nesting, props 를 통한 단방향 데이터 흐름)이 skeleton 의 컴포넌트 분해·재사용 방식을 정당화하는 1차 근거. /learn 페이지는 React 공식 Quick Start 로 daily-use 개념의 80%를 다룬다고 명시한 진입점 문서.
핵심 인용 / Key quotes (verbatim, 5문장)
[Creating and Nesting Components] "React apps are built from components - pieces of UI with their own logic and appearance, ranging from buttons to entire pages." (line 18 in fetched text)
[Creating and Nesting Components] "React components are JavaScript functions that return markup:" (line 20 in fetched text)
[Creating and Nesting Components] "Components can be nested into other components:" (line 30 in fetched text)
[Creating and Nesting Components] "Important: React component names must start with a capital letter. HTML tags must be lowercase." (line 43 in fetched text)
[Sharing Data Between Components] "Pass state down as props to child components. When the parent state changes, all children receive the updated values." (line 288 in fetched text)
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| REACT-UI-C1 | React 앱은 자기만의 로직과 외형을 가진 재사용 가능한 "컴포넌트" 단위로 구성된다 (버튼부터 전체 페이지까지 스케일이 다양) | "React apps are built from components - pieces of UI with their own logic and appearance, ranging from buttons to entire pages." | official-vendor-doc |
컴포넌트 기반 UI 분해가 React 의 핵심 구성 단위라는 사실 | component-based 접근이 다른 라이브러리(Vue, Svelte 등) 대비 우월하다는 것은 증명하지 않음 |
| REACT-UI-C2 | React 컴포넌트는 markup 을 반환하는 JavaScript 함수로 정의된다 | "React components are JavaScript functions that return markup:" | official-vendor-doc |
함수형 컴포넌트가 React 의 표준 정의 방식이라는 사실(현재 공식 가이드 기준) | class 컴포넌트가 deprecated 되었는지 여부는 이 인용만으로 증명 안 됨 |
| REACT-UI-C3 | 컴포넌트는 다른 컴포넌트 안에 중첩(nest)될 수 있다 | "Components can be nested into other components:" | official-vendor-doc |
컴포넌트 합성(composition)을 통한 UI 트리 구성 가능성 | 중첩 depth 제한이나 성능 특성은 증명하지 않음 |
| REACT-UI-C4 | 컴포넌트 이름은 대문자로 시작해야 하고 HTML 태그는 소문자여야 한다 (JSX 파서가 둘을 구분하는 문법 규칙) | "Important: React component names must start with a capital letter. HTML tags must be lowercase." | official-vendor-doc |
JSX 문법 상 컴포넌트/HTML 태그 구분 규칙 | 이 규칙의 내부 구현(reconciler) 원리는 설명하지 않음 |
| REACT-UI-C5 | 부모 컴포넌트의 상태(state)는 props 로 자식 컴포넌트에 전달되며, 부모 상태가 바뀌면 모든 자식이 갱신된 값을 받는다 (단방향 데이터 흐름) | "Pass state down as props to child components. When the parent state changes, all children receive the updated values." | official-vendor-doc |
단방향(top-down) 데이터 흐름이 React 의 기본 데이터 전달 모델이라는 사실 | 전역 상태관리(Redux, Context API 등) 도구 없이 대규모 앱에서 이 패턴만으로 충분한지는 증명하지 않음 |
Strength 참고
React 공식 사이트(react.dev)는 Meta 가 직접 유지보수하는 official-vendor-doc 이므로 위 모든 claim 은 official-vendor-doc 로 분류. RFC/표준 수준(official-standard)은 아님 — React 는 표준 사양이 아니라 특정 벤더(Meta)의 라이브러리 구현체.
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
REACT-UI-C1~REACT-UI-C3: React 의 컴포넌트 모델(함수 컴포넌트 + nesting + composition)REACT-UI-C4: JSX 문법 규칙(컴포넌트/HTML 태그 대소문자 구분)REACT-UI-C5: props 를 통한 단방향 데이터 흐름
- 이 자료가 증명하지 않는 것:
- "React 는 라이브러리이지 프레임워크가 아니다"라는 명시적 진술은 이 fetch 범위(
/learnQuick Start 페이지)에서 발견되지 않음. 2차 WebFetch(targeted prompt)로 재확인했으나 해당 문장은/learn페이지 밖(예: "Start a New React Project" 또는 별도 개요 페이지)에 있을 가능성이 높고, 이번 dispatch 범위에서는 self-grep 통과 가능한 verbatim 인용을 확보하지 못했다.UNSUPPORTED_DECISION— "라이브러리 vs 프레임워크" 근거로 이 문서를 인용하지 말 것. 별도 URL(예: react.dev 개요 페이지 또는 "Start a New React Project" 섹션)에 대한 후속wiki-source-summarizerdispatch 필요. - "declarative UI" 라는 표현 자체도 이번 fetch 범위에서 확인되지 않음 (동일하게 후속 조사 필요).
- React 가 "client-only SPA, no server runtime" 결정에 필수적이라는 주장은 증명하지 않음 — 이 문서는 컴포넌트 모델만 설명하며, 서버 런타임 유무는 React 자체와 독립적인 배포 방식 선택(SSR/SSG 프레임워크 사용 여부)의 문제.
- 성능, 번들 크기, 생태계 비교(Vue/Svelte/Angular 대비)는 다루지 않음.
- "React 는 라이브러리이지 프레임워크가 아니다"라는 명시적 진술은 이 fetch 범위(
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
ca-skeleton-frontend의 실제 컴포넌트 트리 설계가 이 가이드의 nesting/props 패턴을 따르는지 로컬 검증 필요.- "라이브러리 vs 프레임워크" 및 "declarative" 공식 진술은 별도 react.dev 페이지(개요/철학 섹션)에서 재조사 후 별도 raw 문서 또는 본 문서 보강 필요.
메모 / Notes
- 인용 1 해석 후보 (미검증): 컴포넌트가 "버튼부터 전체 페이지까지" 스케일 가능하다는 서술은 skeleton 의 atomic-to-page 컴포넌트 계층 설계에 참고 가능해 보이나, 이 자료 자체가 계층 설계 방법론을 규정하진 않음.
- 추가로 봐야 할 동일 출처 페이지: react.dev 개요/철학 페이지(라이브러리 vs 프레임워크 진술),
/learn/thinking-in-react(컴포넌트 분해 방법론),/learn/describing-the-ui(declarative 표현이 있을 가능성).
Related / 관련
- 같은 주제 다른 official-doc / company-tech-blog: (현재 없음 — 첫 React 관련 raw 자료)
- 이 자료를 인용한 wiki 요약:
[[wiki/concepts/...]](생성 시)