LabHub
배우기 러닝패스 코스

상태 관리 — 라이브러리를 직접 만들어 본다 · 늦게 온 응답이 이겼다 · 퀴즈

경합과 되돌리기 확인

LabHub 에서 이어서 보기

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

  1. 검색창에 빠르게 타자를 쳤을 때 첫 글자의 결과가 화면에 남는 이유는?

    1. 브라우저가 요청을 보낸 순서대로 큐에 쌓아 두기 때문에
    2. 첫 요청이 느려서 마지막 응답보다 늦게 도착해 그 위를 덮기 때문에
    3. React 가 첫 렌더의 결과를 우선해서 보여 주기 때문에
    4. fetch 가 같은 주소의 응답을 하나로 합치기 때문에
  2. 응답에 순번을 붙여 최신인지 견주는 방식만 썼을 때 남는 문제는?

    1. 화면에 옛 결과가 그대로 남는다
    2. 순번이 겹쳐 두 응답이 모두 반영된다
    3. 결과는 버려지지만 서버와 네트워크는 계속 일한다
    4. 메모리에 응답 본문이 무한히 쌓인다
  3. 열쇠별 중복 제거에서 끝난 약속을 표에서 지우지 않으면?

    1. 다음 호출이 영원히 같은 옛 결과나 같은 실패를 받는다
    2. 다음 호출이 두 배로 늘어난다
    3. 약속이 이중으로 해결돼 예외가 난다
    4. 열쇠가 겹쳐 다른 데이터가 섞인다
  4. 라벨을 A 로 바꾸는 갱신과 B 로 바꾸는 갱신이 함께 대기 중일 때 A 를 역연산으로 되돌리면?

    1. 라벨이 B 로 남아 의도대로 된다
    2. 두 갱신이 모두 취소된다
    3. 라벨이 B 가 아니라 그 이전 값으로 돌아간다
    4. 되돌리기가 무시되고 아무 일도 없다
  5. 낙관적 갱신을 바닥값과 대기 목록으로 나눠 들고 있을 때, 서버 응답이 왔다면?

    1. 대기 목록을 비우고 서버 상태를 그대로 화면에 쓴다
    2. 바닥값만 서버 상태로 갈고 남은 대기 갱신을 그 위에 다시 얹는다
    3. 서버 상태를 대기 목록 맨 앞에 갱신으로 넣는다
    4. 서버 상태와 현재 화면 값을 깊은 비교로 병합한다
  6. 질의 캐시에서 '낡음(stale)' 과 '버림(gc)' 을 하나의 눈금으로 합치면?

    1. 다시 받을 때마다 화면이 빈칸으로 깜박였다가 채워진다
    2. 같은 열쇠의 요청이 두 배로 나간다
    3. 캐시 열쇠가 충돌해 다른 화면의 값이 보인다
    4. 메모리 사용량이 시간에 비례해 늘어난다