LabHub
배우기 러닝패스 코스

상태 관리 — 라이브러리를 직접 만들어 본다 · 서버의 값을 복사해 두었다 · 퀴즈

서버 상태 확인

LabHub 에서 이어서 보기

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

  1. 어떤 값이 서버 상태인지 가르는 기준으로 이 글이 제시한 것은?

    1. 네트워크로 받아 온 값인가
    2. JSON 으로 직렬화할 수 있는 값인가
    3. 나 말고 다른 누가 그 값을 바꿀 수 있는가
    4. 여러 화면이 함께 보는 값인가
  2. 받아 온 데이터를 기본적으로 '낡은 것' 으로 치는 설계를 고르는 이유는?

    1. 그쪽이 실패했을 때 값이 싸기 때문에 — 최악이 요청 한 번 더다
    2. 요청 수가 줄어 서버 부하가 낮아지기 때문에
    3. 캐시 메모리를 적게 쓰기 때문에
    4. 낡음 판정을 생략해 코드가 짧아지기 때문에
  3. 주문을 취소한 뒤 목록 캐시를 '지우기' 로 처리하면 화면에 무엇이 보이나?

    1. 옛 목록이 그대로 남아 취소가 반영되지 않는다
    2. 목록이 빈칸으로 깜박였다가 다시 채워진다
    3. 취소한 항목만 회색으로 바뀐다
    4. 다른 화면의 목록까지 함께 사라진다
  4. 입력 중인 글자를 질의 캐시에 넣어 두었을 때 생기는 일은?

    1. 캐시 열쇠가 매 글자 바뀌어 메모리가 샌다
    2. 다른 탭에서 같은 글자가 보인다
    3. 직렬화할 수 없어 예외가 난다
    4. 배경 재요청이 돌면서 치고 있던 글자를 덮어쓴다
  5. 서버 상태에 값과 함께 '받은 시각' 을 저장하는 이유는?

    1. 그게 없으면 '다시 받아야 하나' 를 물을 수 없기 때문에
    2. 응답을 시간순으로 정렬해 보여 주기 위해
    3. 서버와 클라이언트의 시계를 맞추기 위해
    4. 같은 열쇠의 응답을 구별하기 위해
  6. 가르는 선이 흐릿할 때 쓰라고 이 글이 제시한 실전 기준은?

    1. 값이 200바이트를 넘으면 서버 상태로 본다
    2. 탭을 두 개 열고 한쪽에서 바꿨을 때 다른 쪽이 따라와야 하면 서버 상태다
    3. 컴포넌트 두 개 이상이 읽으면 서버 상태로 본다
    4. 새로고침해도 남아 있어야 하면 서버 상태로 본다