사용자 질문("혹시 쪼갠다면 어떻게 쪼갤것 같아?")에 대한 답을 6절로 추가.
핵심은 쪼개야 하는 게 호출부에 보이는 함수가 아니라 재귀 자체라는 것 —
(B)가 요구하는 "부기는 bottom-up, 물리는 top-down"을 하려면 재귀가 두 번
돌아야 하고, 그게 "쪼갠다"의 실체다. attachSlot이라는 이름이 정당하다는
판단에 동의하므로 공개 진입점은 이름/시그니처/호출부 전부 그대로 두고
몸통만 비공개 재귀 헬퍼 둘(materializeSlotTree/mountSlotTree — 코퍼스가
이미 쓰는 unmountSlotTree/destroySlotTree의 ...SlotTree 접미사를 따름)로
나누는 안을 제시. attachSlot의 몸통은 두 줄이 된다.
setLength가 materializeSlotTree의 끝으로 가는 게 관건 — 자기 서브트리
부기가 다 끝난 뒤라 처음부터 최종값이고, 그러면서도 모든 Parent 대입보다
먼저다. 그래서 C6(최종값 등록)와 C7(부기가 물리보다 먼저)이 동시에 만족되고
배치 밖 재마운트의 부모 recompute가 2회→1회로 준다. C1~C7 전부 유지되는지
표로 재점검했고, 비용(_elements 순회 2회)과 안 고쳐지는 것(부모 등록과 자식
배치가 여전히 한 함수), 비대칭 하나(materialize의 거울상은 함수가 아니라
호출부 관용구)도 같이 적었다.
판단은 약한 추천 — 값이 틀려지는 문제가 아니라 "일반 계약을 세워놓고 자기가
예외"인 상태와 _mounted의 애매한 중간 시점(RC-3/RC-4의 출처)이 정리되는
것이 이득. M6 착수 시점에 실제로 짜보며 정해도 늦지 않다.
Co-authored-by: qwreey <me@qwreey.moe>
qwreey
6fd93c6dc2
