LabHub

상태 관리 — 라이브러리를 직접 만들어 본다 · 스토어의 계약 · 퀴즈

상태 관리 확인

LabHub 에서 이어서 보기

문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

    1. 함수형 스타일이 더 우아해서
    2. 복사를 줄여 메모리를 아끼려고
    3. 타입스크립트가 그렇게 요구해서
    4. 바뀌었는지를 참조 비교 하나(O(1))로 판단하기 위해
  2. `state.items.push(x)` 로 상태를 고쳤을 때 나타나는 증상은?

    1. TypeError 예외가 던져진다
    2. 이전 배열이 남아 메모리가 샌다
    3. 데이터는 맞는데 화면이 가끔 안 바뀐다
    4. 타입 오류로 컴파일이 막힌다
  3. 구독을 해제하지 않으면?

    1. 참조가 끊겨 저절로 정리된다
    2. 다음 구독이 등록되지 않는다
    3. 사라진 화면이 계속 그려지고 리스너가 쌓인다
    4. 상태가 초기값으로 되돌아간다
  4. `{ items: [...], count: 3 }` 처럼 파생값을 상태에 저장하면?

    1. 다시 셀 필요가 없어 빨라진다
    2. 둘이 어긋나는 순간이 반드시 온다
    3. count 의 타입이 보장돼 안전해진다
    4. 메모이제이션이 쉬워진다
  5. `dispatch(s => s)` 로 같은 참조가 돌아왔을 때 리스너를 부르면?

    1. 참조가 같으니 아무 일도 없다
    2. 상태는 그대로인데 렌더가 돌고 무한 루프가 된다
    3. 상태가 초기값으로 되돌아간다
    4. 메모이제이션 캐시가 깨진다
  6. React 18 의 automatic batching 이 하는 일은?

    1. 한 틱의 여러 상태 변경을 묶어 리스너를 한 번만 부른다
    2. 렌더를 여러 코어에서 병렬로 돌린다
    3. 네트워크 요청을 묶어 한 번에 보낸다
    4. 쓰지 않는 상태를 자동으로 지운다
  7. 리스너 배열을 `[...listeners].forEach(...)` 로 복사해 순회하는 이유는?

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