예약 화면을 다룰 때 버튼을 다시 누르는 것이 오히려 창을 닫거나 달력을 접는 동작이 될 수 있다. 사용자가 이미 선택한 값도 있을 수 있다. 북극성의 구현에서는 어떤 분기에서 이미 보이는 제어를 확인하고 어떤 분기에는 별도 시작 순서가 남아 있는지 나누어 살폈다.

열기 버튼보다 현재 필요한 제어를 먼저 본다

예약 결과를 다시 읽는 receipt 경로에서는 카테고리 제어가 보이는지 확인한다. 없을 때만 publish-open을 눌러 옵션을 열고 저장된 카테고리를 검증한다. 현재 제어가 이미 있으면 열기 버튼을 무조건 다시 누르지 않는다. 화면의 상태를 목표로 삼고 버튼의 횟수를 목표로 삼지 않은 분기다.

이 한 분기가 모든 예약 진입점을 완전한 임의 상태 재개기로 만든 것은 아니다. 신규 발행 경로에는 목록을 닫고 입력한 뒤 옵션을 여는 순서도 있다. 나는 이 차이를 숨기지 않았다. 실제 코드가 조건부 열기를 하는 위치와 정해진 시작 순서를 전제로 하는 위치를 구분해야 동작을 정확히 설명할 수 있다.

체크된 예약을 또 누르지 않는다

발행 옵션이 준비되면 public과 scheduled의 checked를 읽고 필요한 것만 누른다. 이미 켜진 라디오를 눌렀다는 행동 기록보다 현재 선택값이 원하는 상태인지가 중요하다. 제어는 유일하고 비활성이 아니어야 한다. 이름이 비슷한 라벨을 여러 개 찾았다고 첫 번째를 택하지 않는다.

화면 상태를 읽는 순간과 입력하는 순간은 다르므로 참조를 새로 관찰하는 경로도 필요하다. 오래된 참조가 전달 전에 거절된 경우에만 제한적으로 다시 찾고, 전달 결과가 불확실한 클릭이나 최종 제출은 같은 재시도로 처리하지 않는다. 상태 확인이 중복 효과 방지와 연결되는 지점이다.

날짜가 같으면 달력을 펼칠 이유가 없다

date의 displayValue를 형식에 맞춰 비교하고 원하는 날짜와 다를 때만 날짜 제어를 누른다. 달력을 열었다면 정확한 날짜를 찾고 현재 월의 앞뒤 이동 단서가 하나로 정해져야 한다. 코드에는 이동 횟수 한도가 있어 찾지 못한 달력을 끝없이 넘기지 않는다.

시와 분도 가능한 옵션이 존재하고 비활성이 아닌지 확인한 뒤 이미 selected인지 본다. 화면에 보이는 문자열만 날짜·시각 전체의 증거로 쓰지 않고 실제 선택 상태를 읽는다. 이 예제의 예약 슬롯과 달력 구조를 다른 서비스에 그대로 강제할 수는 없지만 비교할 자료의 종류를 나누는 판단은 재사용할 수 있다.

같은 원칙은 매체 라이브러리의 토글에도 적용했다

사진을 넣기 전에는 현재 선택된 라이브러리 버튼을 명시적으로 찾는다. 열려 있을 때만 닫고 닫혔다는 상태를 다시 읽는다. 처음부터 닫혀 있는 라이브러리를 “닫기 위해” 눌러 오히려 열지 않는다. 평소 제한된 관찰에서 도구막대가 빠졌다면 필요한 대상을 별도로 찾는다.

닫은 뒤에도 확인한 원고 prefix가 같은지 비교한다. 팝업을 정리한다는 이유로 본문이나 첨부가 바뀌었다면 다음 업로드를 시작할 수 없다. 예약 창과 라이브러리는 다른 기능이지만 현재 상태를 읽지 않는 토글이 작업을 뒤로 돌릴 수 있다는 문제는 같았다.

시험의 대상과 현재 구현의 한계를 함께 남긴다

기존 라이브러리 시험은 열려 있을 때 한 번 닫고, 닫혀 있을 때는 열지 않는지 본다. 도구막대가 일반 snapshot에서 빠진 경우도 별도로 확인한다. 예약 fixture에는 비활성 날짜에서 제출하지 않는 조건이 있다. 이번에는 그 함수와 시험을 읽었으며 실제 창을 새로 열고 닫지 않았다.

이 근거를 모든 팝업과 달력의 모든 중간 상태 재개가 완성됐다는 주장으로 확대하지 않는다. 특정 제어에 대한 상태 검사와 진입점의 가정은 다르다. 다른 화면에 옮길 때는 열림을 무엇으로 관찰할지, 조회가 일부인지, 토글 후 무엇을 확인할지를 새로 정해야 한다.

작업 순서를 외우게 하기보다 현재 상태를 설명한다

사용자가 창을 어디까지 열었는지 기억하고 정확한 단계 번호를 말해야 한다면 에이전트의 도움이 줄어든다. 프로그램이 관찰 가능한 현재 상태에서 남은 선택을 설명할 수 있는 편이 낫다. 다만 관찰되지 않은 값을 채워 넣거나 불확실한 제출을 다시 하는 권한까지 생기는 것은 아니다.

나는 같은 버튼을 빠르게 여러 번 누르는 자동화보다 지금 필요한 제어가 이미 있는지 묻는 구현을 남기고 싶었다. 조건부 열기와 선택값 비교, 닫힘 재확인을 작은 함수 안에 두면 이후 실패도 어느 상태를 읽지 못했는지 구체적으로 기록할 수 있다. 현재 상태를 읽는 비용이 불필요한 왕복을 줄이는 자리다.