브라우저 저장값의 버전 관리, 실패를 설명할 단서 남기기
로컬 저장소의 데이터 모양을 바꾼 뒤 예전 값 때문에 화면 초기화가 실패할 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
로컬 저장소의 데이터 모양을 바꾼 뒤 예전 값 때문에 화면 초기화가 실패할 수 있다.
실패했다는 사실만으로는 다음 행동을 정하기 어렵다. 어떤 입력으로 어디까지 진행했으며 무엇을 기대했는지가 함께 있어야 한다. 이번에는 성공 여부를 표시하는 데서 한 걸음 더 나아가, 다음 사람이 같은 조건을 확인할 수 있도록 관찰 항목을 정리한다.
결과와 원인을 구분하는 기록
저장값에 버전을 두고 읽을 때 형식과 허용 범위를 검증한다. 잘못된 값이 있더라도 화면 전체가 멈추지 않도록 복구 경로를 정한다.
이번에 확인할 질문: 결과만 전달받은 사람이 원래 입력과 기대 동작을 복원할 수 있는가?
작게 확인하는 예제
다음 예제는 핵심 조건을 드러내기 위한 출발점이다. 서비스의 전체 구현을 대신하지 않으므로 실제 입력 범위와 실패 처리 규칙을 함께 읽어야 한다.
function readPreference(raw) {
try {
const value = JSON.parse(raw ?? 'null');
return value?.version === 1 && ['dark', 'light'].includes(value.theme)
? value.theme : 'dark';
} catch { return 'dark'; }
}
이전 버전 값, 손상된 JSON, 허용하지 않은 테마 이름을 넣어 기본 화면으로 복구되는지 확인한다.
놓치기 쉬운 조건
localStorage 자체 접근도 브라우저 설정에 따라 실패할 수 있다. 파싱 실패와 저장 공간 접근 실패를 구분하고 비밀정보는 브라우저 저장소에 넣지 않는다.
| 확인할 부분 | 살펴볼 내용 |
|---|---|
| 기준 동작 | 이전 버전 값, 손상된 JSON, 허용하지 않은 테마 이름을 넣어 기본 화면으로 복구되는지 확인한다. |
| 비교 조건 | 입력과 실행 순서를 고정하고 한 번에 한 조건만 바꾼다. |
| 적용 범위 | 예제가 생략한 의존성과 실제 서비스의 제약을 구분한다. |
다음 변경에 적용할 순서
- 기대 결과와 실제 결과를 서로 다른 칸에 적는다.
- 개인정보나 비밀값을 제외하고 재현에 필요한 조건만 남긴다.
- 관찰 사실과 원인에 대한 가설을 구분해 후속 확인을 정한다.
기록을 많이 남기는 것과 유용하게 남기는 것은 다르다. 원인을 좁히는 데 쓰이지 않는 항목은 줄이고, 누락 때문에 다시 묻게 되는 조건은 보완한다. 관찰할 수 있는 범위가 분명해지면 실패한 상황에서도 다음 실험을 작게 잡을 수 있다.
이 이야기가 도움이 되었나요?