状态管理确认

상태 라이브러리가 불변 업데이트를 강요하는 진짜 이유는?

• 함수형 스타일이 더 우아해서
• 복사를 줄여 메모리를 아끼려고
• 타입스크립트가 그렇게 요구해서
• 바뀌었는지를 참조 비교 하나(O(1))로 판단하기 위해

state.items.push(x) 로 상태를 고쳤을 때 나타나는 증상은?

• TypeError 예외가 던져진다
• 이전 배열이 남아 메모리가 샌다
• 데이터는 맞는데 화면이 가끔 안 바뀐다
• 타입 오류로 컴파일이 막힌다

구독을 해제하지 않으면?

• 참조가 끊겨 저절로 정리된다
• 다음 구독이 등록되지 않는다
• 사라진 화면이 계속 그려지고 리스너가 쌓인다
• 상태가 초기값으로 되돌아간다

{ items: [...], count: 3 } 처럼 파생값을 상태에 저장하면?

• 다시 셀 필요가 없어 빨라진다
• 둘이 어긋나는 순간이 반드시 온다
• count 의 타입이 보장돼 안전해진다
• 메모이제이션이 쉬워진다

dispatch(s => s) 로 같은 참조가 돌아왔을 때 리스너를 부르면?

• 참조가 같으니 아무 일도 없다
• 상태는 그대로인데 렌더가 돌고 무한 루프가 된다
• 상태가 초기값으로 되돌아간다
• 메모이제이션 캐시가 깨진다

React 18 의 automatic batching 이 하는 일은?

• 한 틱의 여러 상태 변경을 묶어 리스너를 한 번만 부른다
• 렌더를 여러 코어에서 병렬로 돌린다
• 네트워크 요청을 묶어 한 번에 보낸다
• 쓰지 않는 상태를 자동으로 지운다

리스너 배열을 [...listeners].forEach(...) 로 복사해 순회하는 이유는?

• 순회 중에 구독이 해제돼도 하나를 건너뛰지 않으려고
• 복사본 순회가 더 빠르기 때문에
• 리스너 배열의 메모리를 아끼려고
• 타입스크립트가 요구하기 때문에