Trigger·Render·Commit을 한 줄로 외웠는지가 아니라, 단계별 책임을 갈라 성능 이슈를 어디서부터 좁힐지 판단할 수 있는지를 본다. 자동 배칭이나 effect 타이밍까지 자연스럽게 엮어 설명하면 깊이가 드러난다.
state·props가 바뀌면 Trigger가 걸려 업데이트가 큐에 들어간다. Render 단계에서 새 Virtual DOM을 계산하고 이전 트리와 비교하는데, 이 시점에는 DOM이 아직 안 바뀐다. Commit 단계에서야 diff 결과를 실제 DOM에 반영하고 ref·effect가 발화된다. 같은 이벤트 안의 여러 setState는 자동 배칭으로 한 번의 Render·Commit으로 묶인다. 성능 병목이 'Render가 비싼지'와 'Commit이 비싼지' 중 어느 쪽인지 갈라야 해결 방향이 갈린다.
Profiler를 켜고 Render와 Commit 중 어느 쪽이 비쌌는지 직접 갈라 본 경험이 있다면 그 추적 과정을 그대로 풀어낼 수 있다
React.memo나 key 조정으로 리렌더 범위를 좁혔던 경험이 있다면 어떤 단계의 비용을 줄인 건지 설명할 수 있다
여러 setState를 한 핸들러에 모았더니 렌더 횟수가 줄었던 사례가 있다면 자동 배칭이 Trigger를 어떻게 합치는지와 연결할 수 있다
useEffect 안에서 DOM을 읽어야 했던 경험이 있다면 Commit 이후에 effect가 도는 타이밍과 묶어 말할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.