페이지를 옮겼는데 메뉴가 처음으로 돌아가는 문제

목적지와 출발점의 맥락을 함께 본다

많은 대상을 가로로 탐색하다 뒤쪽 항목을 골랐다고 생각해 보자. 상세 페이지가 정상이어도 메뉴가 처음으로 돌아가면 다른 대상과 비교하려고 다시 길게 이동해야 한다. 내용이 맞게 열리는 기능과 그 내용을 찾아온 경로를 이어 주는 기능은 서로 다르다.

이 프로젝트의 8월 5일 대화에는 모바일에서 보았을 때 메뉴의 위치가 돌아간다는 설명이 남아 있다. 당시 데스크톱은 아직 보지 않았다는 범위도 함께 있었다. 나는 그 말을 모든 기기의 같은 결함으로 넓히지 않고, 어느 환경에서 무엇을 관찰했는지부터 구별한다.

선택한 대상과 스크롤 위치는 같은 값이 아니다

어떤 아티스트의 페이지인지 알아도 그 메뉴가 화면에서 몇 번째 위치에 보였는지는 알 수 없다. 선택 상태는 대상의 식별자로 표현할 수 있지만 스크롤 위치는 목록의 배치, 화면 폭과 사용자의 이동에 영향을 받는다. 둘을 한 값처럼 생각하면 대상은 맞는데 탐색 자리는 틀린 상태가 된다.

나는 상태를 정할 때 무엇을 기억하려는지 먼저 문장으로 적어 본다. 지금 선택한 대상인가, 메뉴에서 사용자가 보고 있던 자리인가, 사용자가 바꾼 정렬인가? 필요한 상태가 다르면 보존하는 시점과 복원하는 방법도 달라질 수 있다.

PC 목록과 모바일 목록을 두 벌로 만들던 구조가 바뀌었다

초기 템플릿 수정 기록에는 모바일 바와 데스크톱 독이 같은 아티스트 목록을 각각 출력하는 구조가 남아 있다. 이후 8월 6일 수정에서는 한 nav의 artist-rail로 통합하고 CSS로 방향을 바꾸었다. 실제 편집 입력과 파일 갱신 응답을 대조하면 이 변화가 설명 문서의 제안만은 아니었다는 것을 확인할 수 있다.

한 벌로 바꾸었다고 이전의 상태가 저절로 맞아지는 것은 아니다. 목록을 찾는 선택자, 드래그 방향과 위치를 저장하는 기준도 함께 바뀌어야 한다. 나는 화면 구조가 단순해질수록 주변 코드가 어떤 옛 가정을 가지고 있는지 확인해야 한다고 본다.

폭의 숫자보다 실제 방향을 읽는 선택

당시 JavaScript 수정은 현재 요소의 flex-direction을 읽어 가로와 세로 축을 고르는 방식이었다. CSS가 화면에 따라 방향을 정하고 있는데 JavaScript가 다른 폭 기준을 따로 갖고 있으면, 두 기준이 어긋나는 구간이 생길 수 있다. 렌더된 방향에서 사용할 축을 읽는 판단은 그 중복 기준을 줄이려는 선택이었다.

아래는 그 선택을 설명하기 위해 저장 키 이름을 일반화한 짧은 발췌다. 전체 복원 코드가 아니며 해당 프로젝트의 저장소 키를 그대로 적용하라는 뜻도 아니다. 행 반전, 열 반전, 오른쪽에서 왼쪽으로 읽는 화면을 지원한다면 이 두 방향 예제보다 더 넓은 조건을 검사해야 한다.

// The historical change chose the axis from the rendered CSS direction.
const axis = getComputedStyle(rail).flexDirection === 'column' ? 'y' : 'x';
// Use a separate stored position for horizontal and vertical navigation.
const key = axis === 'y' ? 'artist-scroll:vertical' : 'artist-scroll:horizontal';
const position = axis === 'y' ? rail.scrollTop : rail.scrollLeft;
// This excerpt illustrates the choice. It is not a complete persistence module.

가로에서 보던 자리와 세로에서 보던 자리를 나눈다

8월 6일 후속 수정 기록에서는 가로 메뉴와 세로 메뉴에 서로 다른 저장 키를 두었다. 가로 이동의 숫자를 세로 이동에 그대로 넣는다고 같은 대상을 가리키는 것은 아니다. 화면을 줄였다 넓히는 동안에도 두 탐색 자리는 다른 맥락을 가진다.

다른 사이트에 적용할 때는 복원한 값이 지금 목록 길이에서 가능한 범위인지도 확인해야 한다. 항목이 빠졌거나 순서가 바뀌면 예전 픽셀 위치가 더 이상 같은 의미가 아닐 수 있다. 화면 위치를 기억할지, 대상 식별자를 기준으로 다시 찾을지는 목록이 얼마나 자주 바뀌는지에 맞춰 정한다.

저장할 수 없는 환경도 탐색을 막지 않아야 한다

상태 보존을 새로 구현한다면 저장소 접근 실패를 별도로 다루는 편이 좋다. 브라우저 설정이나 실행 프레임에 따라 저장 기능을 쓸 수 없는 환경이 있을 수 있다. 이 경우에도 메뉴를 누르고 페이지를 읽는 기본 동작은 계속되어야 한다. 기억 기능이 없다고 탐색 자체를 실패시키는 구조가 되어서는 안 된다.

이 부분은 이번 기록에서 현재 모든 환경에 구현됐다고 확인한 기능이 아니라 다음 재사용 모듈에 반영할 조건이다. 작은 예제를 운영 기능으로 옮길 때는 저장 범위와 만료, 목록 변경, 접근 실패를 정해야 한다. 모든 방문자에게 같은 저장 방식이 가능한 것으로 전제하지 않는다.

다시 확인할 동작을 구체적으로 적는다

링크를 한 번 눌러 상세 페이지가 열리는지만 보고 끝내면 처음의 문제를 놓친다. 나는 목록 뒤쪽으로 이동한 상태에서 대상을 바꾸고, 다시 다른 대상을 고르고, 폭을 바꿨다가 돌아오는 동작을 나누어 확인하기를 권한다. 선택한 대상의 표시와 실제 메뉴 위치도 각각 읽어야 한다.

현재 확인한 것은 당시 문제 제기, 파일 갱신 기록, 최적화 문서의 방향별 저장 설명과 지금 HTML의 단일 레일 구조다. 새로 실제 휴대폰의 상태 복원까지 검사한 결과는 아니다. 다음 재사용 구현에서는 이 동작들을 실제 화면에서 확인하고 저장을 쓸 수 없는 환경도 함께 살펴볼 것이다.

1. 목록 뒤쪽 항목을 선택한 뒤 탐색 자리가 유지되는가?
2. 현재 대상 표시는 맞지만 메뉴 위치만 틀린 상태가 없는가?
3. 가로와 세로 배치로 전환했다 돌아올 때 각각의 자리가 맞는가?
4. 목록 길이·정렬·저장 접근 조건이 달라져도 기본 탐색을 계속할 수 있는가?