상태 관리 — 라이브러리를 직접 만들어 본다 · 서버의 값을 복사해 두었다 · 퀴즈
서버 상태 확인
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
어떤 값이 서버 상태인지 가르는 기준으로 이 글이 제시한 것은?
- 네트워크로 받아 온 값인가
- JSON 으로 직렬화할 수 있는 값인가
- 나 말고 다른 누가 그 값을 바꿀 수 있는가
- 여러 화면이 함께 보는 값인가
받아 온 데이터를 기본적으로 '낡은 것' 으로 치는 설계를 고르는 이유는?
- 그쪽이 실패했을 때 값이 싸기 때문에 — 최악이 요청 한 번 더다
- 요청 수가 줄어 서버 부하가 낮아지기 때문에
- 캐시 메모리를 적게 쓰기 때문에
- 낡음 판정을 생략해 코드가 짧아지기 때문에
주문을 취소한 뒤 목록 캐시를 '지우기' 로 처리하면 화면에 무엇이 보이나?
- 옛 목록이 그대로 남아 취소가 반영되지 않는다
- 목록이 빈칸으로 깜박였다가 다시 채워진다
- 취소한 항목만 회색으로 바뀐다
- 다른 화면의 목록까지 함께 사라진다
입력 중인 글자를 질의 캐시에 넣어 두었을 때 생기는 일은?
- 캐시 열쇠가 매 글자 바뀌어 메모리가 샌다
- 다른 탭에서 같은 글자가 보인다
- 직렬화할 수 없어 예외가 난다
- 배경 재요청이 돌면서 치고 있던 글자를 덮어쓴다
서버 상태에 값과 함께 '받은 시각' 을 저장하는 이유는?
- 그게 없으면 '다시 받아야 하나' 를 물을 수 없기 때문에
- 응답을 시간순으로 정렬해 보여 주기 위해
- 서버와 클라이언트의 시계를 맞추기 위해
- 같은 열쇠의 응답을 구별하기 위해
가르는 선이 흐릿할 때 쓰라고 이 글이 제시한 실전 기준은?
- 값이 200바이트를 넘으면 서버 상태로 본다
- 탭을 두 개 열고 한쪽에서 바꿨을 때 다른 쪽이 따라와야 하면 서버 상태다
- 컴포넌트 두 개 이상이 읽으면 서버 상태로 본다
- 새로고침해도 남아 있어야 하면 서버 상태로 본다