qwreey
bcd02f1cec
- base/ref-plan.md: "PostRef" 절 신설(PreRef의 거울상 — pre-pass 공동 수집, ProcessedPostRef 센티널+전담 Handler, 동적 경로 가드, _fired, 타입 차단). 보장 범위를 명시: 자기 서브트리 완성은 보장하되 이 인스턴스가 부모에 붙기 전에 불림(React componentDidMount와 다름). - 복수 PreRef/PostRef의 계열 안 fire 순서를 "배열 index 순서 보장"에서 미보장으로 역전 — 구현이 아니라 계약만 좁힘 (archive/preref-order-guaranteed-reversed.md 신설). - research/lifecycle-hooks-plan.md → base/ 승격, OnRendered 채택 반영 (마지막 열린 항목이던 채택 여부/메커니즘/스코프/패키지 전부 확정). - dispatch-core-plan/brand/architecture/slot/modifier/typing-limits/README/ ROADMAP/question.md 전파. doc-check.py ERROR 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
63 lines
3.8 KiB
Markdown
63 lines
3.8 KiB
Markdown
# [역전됨] 복수 `PreRef` 간 fire 순서 = "배열 index 순서 그대로 보장" → 미보장
|
|
|
|
**역전 일자**: 2026-08-14 아홉 번째 세션 (원 결정: 2026-08-07 아홉 번째
|
|
세션). **현재 유효한 계약은 `base/ref-plan.md`의 "`phase` 옵션 폐기 →
|
|
위치로 표현, `PreRef` 신설" 절**(복수 `PreRef` 간 순서 항목)과 같은
|
|
문서의 "`PostRef`" 절 — 이 파일은 히스토리 보존용이라 여기 적힌 걸
|
|
근거로 코드를 짜지 말 것.
|
|
|
|
## 원문 (2026-08-07 아홉 번째 세션 확정, `bind-system-plan.md` → `ref-plan.md`)
|
|
|
|
> - **복수 `PreRef` 간 순서(2026-08-07 아홉 번째 세션, 사용자 확인) —
|
|
> 새 규칙 불필요, 배열 index 순서 그대로.** 같은 인스턴스에 `PreRef`가
|
|
> 여럿 있으면, 이 pre-pass는 위 "props 순회 순서" 절이 이미 확정해둔
|
|
> "배열 파트는 index 순서대로" 계약을 그대로 재사용해 리터럴 순서대로
|
|
> fire하면 됨 — 서로 다른 우선순위/순서 개념을 별도로 만들 필요 없음
|
|
> (호이스팅은 "PreRef 전체 대 나머지"에만 적용되는 규칙이지, "PreRef끼리"
|
|
> 에는 적용될 게 없음 — PreRef끼리는 그냥 평범한 배열 순회).
|
|
|
|
## 무엇이 뒤집혔나
|
|
|
|
**구현이 아니라 계약이 뒤집힘.** pre-pass가 배열을 index 순서로 훑는다는
|
|
구현은 그대로이고, 실제 fire 순서도 사실상 리터럴 순서일 것임 — 바뀐 건
|
|
그걸 **사용자에게 보장하느냐**임.
|
|
|
|
| | 역전 전 | 현재 |
|
|
|---|---|---|
|
|
| `PreRef`끼리의 상대 순서 | **보장**(배열 index 순서) | **보장 안 함** |
|
|
| `PostRef`끼리의 상대 순서 | (당시 `PostRef` 없음) | **보장 안 함** |
|
|
| 호이스팅("`PreRef` 전체가 나머지보다 먼저") | 보장 | 보장(**변경 없음**) |
|
|
| `PostRef`("두 패스가 전부 끝난 뒤") | (없음) | 보장 |
|
|
|
|
## 역전 이유 (사용자)
|
|
|
|
> "PreRef는 프로퍼티/자식 들어오기 전에 설정됨. 각 PreRef 간의 순서는
|
|
> 보장 안함. PostRef는 프로퍼티/자식 들어온 후 설정됨, PostRef간 순서는
|
|
> 보장 안함(실제로 하더라도, 안 한다고 두는게 버그를 차라리 덜 만든다고
|
|
> 생각함. 같은 계열 내 Ref 등록 순서에 의존하는 무언가가 생겨선 안된다는
|
|
> 생각, 그건 구조부터 잘못된거니까)"
|
|
|
|
정리하면 셋:
|
|
|
|
1. **순서에 의존하는 코드는 애초에 설계가 잘못된 것** — 두 훅의 상대
|
|
순서가 중요할 정도면 훅을 둘로 나눌 게 아니라 하나 안에서 순서대로
|
|
부르면 됨. 보장을 제공하면 그 잘못된 구조를 오히려 권장하게 됨.
|
|
2. **보장하지 않으면 구현을 바꿀 자유가 남음** — pre-pass의 순회 방식을
|
|
나중에 바꿔도(예: 최적화, 백엔드별 자료구조 차이) 계약 위반이 아님.
|
|
`base/dispatch-core-plan.md`가 "다른 백엔드가 props를 Lua 테이블이
|
|
아닌 자료구조로 표현할 수 있다"는 이유로 두 패스 순서를 **명시적
|
|
계약**으로 고정했던 것과 같은 결의 판단 — 거기선 보장이 필요해서
|
|
고정했고, 여기선 필요 없어서 안 고정함.
|
|
3. **버그가 덜 생김** — 보장이 없으면 그 순서에 기대는 사용자 코드가
|
|
애초에 안 생김.
|
|
|
|
## 영향 범위
|
|
|
|
- `base/ref-plan.md` — 해당 bullet 교체(역전 표시 + 이유), 새 "`PostRef`"
|
|
절도 같은 규칙으로 서술.
|
|
- `base/lifecycle-hooks-plan.md` — "다중 등록 가능" 절에 "같은 계열끼리
|
|
순서 미보장" 경고 추가, ② 절의 "복수 `PostRef` 간 순서는 복수 `PreRef`와
|
|
같은 원칙(배열 index 순서 그대로)" 문장 정정.
|
|
- `ROADMAP.md` M8 — "복수 `PreRef`는 배열 index 순서 그대로(별도 규칙
|
|
없음)" 체크리스트 문구 정정.
|
|
- 코드 영향 없음(구현이 안 바뀌므로) — 바뀐 건 문서화 대상 계약뿐.
|