qwreey
0c9b8584ee
quad(Roblox DOMless UI 렌더러) v2 재작성을 위한 .claude/ 계획 구조를 세우고
핵심 아키텍처 결정을 정리함:
- quad v1 / rbvm / tbox / Fusion / Vide / 폐기된 quad2-try 프로토타입 리서치
- Store 책임 분리(base vs provider), process/retract 핸들러 디스패치 모델,
Ref 역할, Slot/Tween 설계 방향 등 핵심 결정 확정
- .claude/{base,research,qa-request,archive,feedback}, question.md, README.md
구조 마련 (code-docker/webmanager 패턴 참고)
- 루트 CLAUDE.md/HUMAN_TODO.md 작성
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
52 lines
3.4 KiB
Markdown
52 lines
3.4 KiB
Markdown
# 컴포넌트 순수성이 아니라 "이식성" 문제 (재정의됨)
|
|
|
|
**상태**: research — 사용자 확인 완료로 문제 자체는 명확해짐, 남은 건 문서화
|
|
강도 정도. 원본: `.claude/initreq/raw-userinput.md` "순수함수에 대한 범위를
|
|
정할 필요가 있음" / "진짜 부작용은 외부에 만들어버린다" 절.
|
|
|
|
## 정정: "순수함수 여부"가 아니라 "이식성(portability)" 문제였다
|
|
|
|
**사용자 확인 완료 — 이전 초안의 프레이밍이 부정확했음.** quad는 vdom이
|
|
없으므로 컴포넌트(Class 함수)는 **딱 한 번만 실행**된다. 모든 부작용은 그
|
|
한 번의 실행에서 전부 등록됨 — store에 의해 렌더 함수 안 특정 부분이 다시
|
|
트리거될 순 있지만, 함수 자체가 반복 실행되는 구조가 아님. 이 전제 위에서
|
|
실제로 문제였던 것은 "순수함수냐 아니냐"가 아니라 **컴포넌트가 자신이 받은
|
|
파라미터(store) 대신 전역(global) store를 직접 참조하는 경우의 이식성**이었음.
|
|
|
|
### 구체적 문제 상황
|
|
|
|
컴포넌트가 특정 store를 받아서 렌더하도록 설계되어야 하는데, 그렇게 안 하고
|
|
전역 store를 직접 참조해버리는 경우:
|
|
- 그 컴포넌트가 **한 게임 안에서 한 번만 쓰이는 존재**(예: 특정 페이지에 해당하는
|
|
컴포넌트)라면 전혀 문제 없음 — 오히려 그게 자연스러울 수 있음.
|
|
- 하지만 **여기저기서 재사용하려고 만들어둔 컴포넌트**가 전역을 건드린다면
|
|
이식성이 망가짐 — 다른 프로젝트/다른 컨텍스트에 갖다 쓸 수 없게 됨.
|
|
- **라이브러리 내부적으로만 쓰는 공유 값**(라이브러리가 의도적으로 내부에서
|
|
전역 상태를 만들어 쓰는 경우)은 문제 없을 수도 있음 — 이식성 문제는 "재사용을
|
|
의도한 컴포넌트가 자기가 받은 입력 밖의 것에 은밀히 의존하는가"에 국한됨.
|
|
|
|
### 결론: 입력받은 store만 처리하는 함수가 좋은 컴포넌트
|
|
|
|
재사용/이식을 의도하는 컴포넌트는 파라미터로 받은 store만 처리하는 게
|
|
좋다는 게 결론 — 다만 **이건 기술적으로 막을 문제가 아니라 UB로 두고 사용자에게
|
|
경고해야 할 문서화 문제**. 라이브러리가 "전역 참조 금지"를 런타임/타입
|
|
시스템으로 강제하려는 시도는 좋은 접근이 아니라고 명시적으로 판단함(과도한
|
|
엔지니어링, 정당한 유스케이스까지 막을 위험).
|
|
|
|
## 문서화 방향
|
|
|
|
- `base/store-semantics.md`("Store는 부작용을 허용하는 게 기본 디자인")와
|
|
같은 결의 문제 — Store 자체의 부작용 허용 여부와는 별개로, **컴포넌트가
|
|
"자기 입력 밖의 상태"에 의존하면 이식성이 깨진다**는 원칙을 문서에 별도로
|
|
명시.
|
|
- 가이드 문서에 "재사용 가능한 컴포넌트를 만들 땐 store를 파라미터로만
|
|
받고 전역을 직접 참조하지 말 것 — 페이지/앱 최상위 컴포넌트처럼 애초에
|
|
재사용 의도가 없다면 상관없음"이라는 원칙과, 그 이유(이식성)를 예시와 함께
|
|
기술.
|
|
- 린트 규칙이나 런타임 경고 같은 기술적 강제는 하지 않음(확정) — 순수 문서
|
|
수준의 권장.
|
|
|
|
## 열린 질문
|
|
|
|
- 문서에 이 원칙을 얼마나 두드러지게(가이드 최상단 vs 각주 수준) 배치할지 —
|
|
급하지 않음, 실제 문서 작성 단계에서 결정.
|