계산기를 처음 열었는데 이미 숫자가 채워져 있다면 누구의 값인지부터 궁금해질 수 있다. 실제 운송 도구의 예시 주소와 저장 초안 처리 코드를 읽으며, 계산 공식보다 먼저 입력의 소유권을 설명해야 한다고 생각했다.
자동 입력의 편리함에는 출처가 필요하다
기존 화면은 허용한 예시 프리셋을 먼저 적용하고, 그것이 없을 때 저장한 입력을 불러올 기회를 제공한다. 예시를 보기 위해 들어온 사람에게 지난 작업이 갑자기 나타나는 일을 피하는 구조다. 저장 여부와 현재 입력이 같은 상태는 아니다. 나는 화면이 채워졌다는 사실만으로 사용자가 직접 저장한 값이라고 읽히지 않게 하고 싶었다.
그래서 새 독립 예제에는 current와 stored, origin을 나눴다. 예시를 열어도 전달받은 저장 값은 보존하며, 저장된 초안을 자동 계산의 근거로 사용하지 않는다. 실제 브라우저 저장소를 읽거나 지우는 구현은 옮기지 않았다. 데이터가 오는 곳과 화면에 적용하는 시점을 살펴보기 위한 메모리 모델이다.
현재 입력을 바꾸는 일은 명시적인 동작이다
예시 보기, 저장값 불러오기, 현재 입력 초기화와 저장값 제거를 각각 다른 동작으로 두었다. 현재 입력을 비워도 저장 초안은 남고 저장 초안을 없애도 현재 화면은 남는다. 이 차이가 없으면 사용자가 무엇을 지웠는지 예상하기 어렵다. 이번 함수는 반환 상태를 읽으면 어느 값이 남았는지 확인할 수 있게 했다.
새 예제는 교체 동작에 로컬 revision 확인도 추가한다. 오래된 화면에서 만든 불러오기 요청이 최신 편집을 덮지 않도록 현재 번호가 일치할 때만 적용한다. 원래 업체 프로그램에 이 기능을 설치했다는 뜻은 아니다. 서버 동시 수정 방어와도 다르며 한 문서 안에서 입력을 바꾸는 작은 계약이다.
주소와 저장 형식도 마음대로 믿지 않는다
예시 주소는 알려진 preset 하나만 허용하고 중복 키와 알 수 없는 키를 거절한다. 저장 입력도 version과 허용한 필드만 받는다. 숫자처럼 보이는 텍스트를 받더라도 실제 거리나 연료로 유효한지는 별도 계산 모듈에서 검사해야 한다. 초안 저장의 성공을 측정 검증의 성공으로 부르지 않았다.
고정 실행 예제는 저장 초안이 있는 상태로 예시를 열고, 명시적으로 불러오고, 두 종류의 초기화를 수행한다. 오래된 번호의 불러오기 요청이 실패하는 경우도 있다. 개인 기록과 실제 주소는 쓰지 않았고 입력 객체가 원래 값 그대로인지 테스트했다.
편집 순서를 작은 표처럼 다시 읽는다
예시를 열고 수정한 뒤 저장값을 불러오는 순서를 생각해 보자. 저장값이 더 오래됐더라도 파일 형식은 정상일 수 있다. 형식 검사만으로 교체를 허용하면 최근 입력이 사라진다. 새 예제의 번호 확인은 값의 형식과 적용 시점을 별도로 검사한다. 올바른 값이 지금 적용해도 되는 값인지 한 번 더 묻는 것이다.
이 정책에서 저장 동작은 현재 값의 복사본을 만든다. 이후 현재 값을 바꿔도 저장된 복사본은 저절로 따라가지 않는다. 사용자가 저장을 눌렀던 순간과 지금 화면의 상태가 다를 수 있음을 모델에 남겼다. 저장 아이콘 하나가 모든 상태를 뜻하게 만들지 않는다.
실서비스에 연결한다면 저장 실패 때 현재 입력을 보존하고 실패를 알아볼 수 있게 안내해야 한다. 이번 함수의 성공 반환은 디스크에 쓰였다는 증거가 아니다. 나는 작은 상태 계약을 먼저 검산한 뒤 실제 저장 경로와 화면 안내를 붙이는 순서가 다른 사업의 입력 도구에도 재사용될 수 있다고 보았다.
초안을 보존하는 화면으로 연결할 때
모듈은 소스와 ZIP을 새로 푼 환경에서 14개 테스트를 통과했다. 실제 localStorage 복구, 브라우저 새로고침과 기기 간 동기화는 구현하지 않았다. 그것들이 필요하다면 저장 실패와 호환되지 않는 버전의 안내, 사용자가 이해하는 버튼 이름을 함께 설계해야 한다.
기존 글에서 다룬 저장 API 일반론과 달리 이번 질문은 현재 보이는 숫자가 어디서 왔고 언제 교체할 수 있는가다. 좋은 예시는 입력을 쉽게 시작하게 하면서도 사용자의 작업을 존중해야 한다. 나는 화면의 편리함을 기본값의 양보다 사용자가 다음 행동의 결과를 예측할 수 있는 정도로 판단했다.