사용자가 짚은 "물리 마운트가 관측 이후 일괄로 밀린다"는 차이를 따져본 결과
감수하는 비용이 아니라 개선이라는 결론.
- 마운트 순서 자체는 안 바뀐다(둘 다 깊이 우선 같은 순서) — 바뀌는 건 각
Parent 대입 시점에 부기가 얼마나 완성돼 있는가뿐.
- 그 차이를 실제로 관측하는 주체가 있다: Parent 대입이 ChildAdded/
DescendantAdded를 동기 발화시키므로 사용자 핸들러가 마운트 도중에 끼어든다.
현행은 A의 ChildAdded 시점에 inner.Length가 0이고 뒤 형제 offset도 stale인
미완성 스냅샷을 보여주는데, 분해하면 첫 발화 때 서브트리 전체가 최종값이다.
slot.Length 구독자도 0→최종 두 번이 아니라 최종값으로 한 번 발화.
- "합치는 거대 함수"는 만들어도 목적을 못 이룬다 — 완전 병합은 자식 길이를
그 자식 재귀가 끝나야 알므로 C6를 못 지키고(그게 지금 코드), 부분 병합은
인터리브는 유지하지만 부모 레벨 C7 위반이 그대로 남는다. 실질 선택지는
(A) 인터리브+자기교정 / (B) 분해+일괄 둘뿐.
- 부수 이득 둘: Blocker가 materialize만 감싸게 되어 "배치 등록 게이팅"이라는
정의와 코드 범위가 일치하고, mountSlotTree가 순수 walk라 일괄 삽입이
유리한 백엔드(웹 DocumentFragment 등)가 그 함수 하나만 갈아끼울 수 있는
seam이 생긴다.
판단을 "약한 추천"에서 "추천"으로 갱신 — RC-1/RC-3/RC-4가 전부 한 함수 안의
줄 순서를 잘못 잡아 난 버그였는데, 분해하면 C2/C3/C7이 함수 경계로 강제되어
그 실수 클래스가 구조적으로 사라진다는 사용자 지적이 결정적. 다만 M6 착수 전
실제로 짜보며 확정해도 늦지 않다는 판단은 유지.
Co-authored-by: qwreey <me@qwreey.moe>
qwreey
448b961e7f
