상태 관리 — 라이브러리를 직접 만들어 본다 · 스토어의 계약 · 퀴즈
상태 관리 확인
문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
상태 라이브러리가 불변 업데이트를 강요하는 진짜 이유는?
- 함수형 스타일이 더 우아해서
- 복사를 줄여 메모리를 아끼려고
- 타입스크립트가 그렇게 요구해서
- 바뀌었는지를 참조 비교 하나(O(1))로 판단하기 위해
`state.items.push(x)` 로 상태를 고쳤을 때 나타나는 증상은?
- TypeError 예외가 던져진다
- 이전 배열이 남아 메모리가 샌다
- 데이터는 맞는데 화면이 가끔 안 바뀐다
- 타입 오류로 컴파일이 막힌다
구독을 해제하지 않으면?
- 참조가 끊겨 저절로 정리된다
- 다음 구독이 등록되지 않는다
- 사라진 화면이 계속 그려지고 리스너가 쌓인다
- 상태가 초기값으로 되돌아간다
`{ items: [...], count: 3 }` 처럼 파생값을 상태에 저장하면?
- 다시 셀 필요가 없어 빨라진다
- 둘이 어긋나는 순간이 반드시 온다
- count 의 타입이 보장돼 안전해진다
- 메모이제이션이 쉬워진다
`dispatch(s => s)` 로 같은 참조가 돌아왔을 때 리스너를 부르면?
- 참조가 같으니 아무 일도 없다
- 상태는 그대로인데 렌더가 돌고 무한 루프가 된다
- 상태가 초기값으로 되돌아간다
- 메모이제이션 캐시가 깨진다
React 18 의 automatic batching 이 하는 일은?
- 한 틱의 여러 상태 변경을 묶어 리스너를 한 번만 부른다
- 렌더를 여러 코어에서 병렬로 돌린다
- 네트워크 요청을 묶어 한 번에 보낸다
- 쓰지 않는 상태를 자동으로 지운다
리스너 배열을 `[...listeners].forEach(...)` 로 복사해 순회하는 이유는?
- 순회 중에 구독이 해제돼도 하나를 건너뛰지 않으려고
- 복사본 순회가 더 빠르기 때문에
- 리스너 배열의 메모리를 아끼려고
- 타입스크립트가 요구하기 때문에