llm-wiki/raw/official-docs/react-ui-library-official.md

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			ca-skeleton-frontend	official-doc ca-skeleton frontend react	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 범위(/learn Quick 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-summarizer dispatch 필요.
  • "declarative UI" 라는 표현 자체도 이번 fetch 범위에서 확인되지 않음 (동일하게 후속 조사 필요).
  • React 가 "client-only SPA, no server runtime" 결정에 필수적이라는 주장은 증명하지 않음 — 이 문서는 컴포넌트 모델만 설명하며, 서버 런타임 유무는 React 자체와 독립적인 배포 방식 선택(SSR/SSG 프레임워크 사용 여부)의 문제.
  • 성능, 번들 크기, 생태계 비교(Vue/Svelte/Angular 대비)는 다루지 않음.
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • 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/...]] (생성 시)