필터를 눌러도 읽던 위치를 지키는 화면

필터 변경과 페이지 이동을 나눈다

이 프로필의 분야 선택은 같은 경로에서 쿼리 조건만 바꾼다. 다른 사람의 페이지를 여는 동작이 아니라, 보고 있던 작업 목록을 좁히는 동작이다. 선택값을 주소에 남기더라도 화면까지 맨 위로 돌려보낼 이유는 없었다.

수정 전 재현 기록은 선택한 결과가 나온 뒤 스크롤이 0이 됐다고 남겼다. 현재 코드는 프로필의 조건 교체에서 라우터의 자동 스크롤을 끄고, 앱의 상단 이동 처리는 경로가 바뀔 때 실행한다. 같은 경로의 필터 변경이 그 처리를 다시 부르지 않도록 역할을 나눈 것이다.

적용 기준을 모든 쿼리 변경에 똑같이 붙이지는 않는다. 같은 앱의 다른 목록에는 관심 항목이나 필터 상태가 바뀐 뒤 특정 항목 또는 목록 제목으로 초점을 안내하는 코드도 있다. 주소의 형식만 보지 말고, 조건 변경 뒤 사용자가 계속 보고 조작해야 할 대상을 먼저 정해야 한다.

스크롤 위치와 키보드 초점은 따로 확인한다

화면에 결과가 보여도 키보드로 다음 조작을 이어갈 위치는 다를 수 있다. 필터를 누른 경우에는 선택한 버튼과 결과 목록의 관계가 이어져야 한다. 다른 페이지를 연 경우에는 이전 메뉴에 남아 있는 초점보다 새 본문의 시작점이 필요한 상황이 있다.

일반 페이지 이동에서는 앱이 상단 위치를 정하고, 요청한 경로의 결과가 준비되면 본문 영역에 초점을 둔다. 본문에는 프로그램으로 초점을 받을 수 있는 설정이 있다. 이때 초점 설정이 다시 스크롤을 일으키지 않도록 preventScroll을 사용한다. 화면 위치를 정하는 코드와 초점을 정하는 코드가 서로의 결과를 바꾸지 않게 한 구성이다.

처음 주소를 직접 열었을 때의 본문 바로가기 링크도 유지했다. 키보드로 그 링크를 찾아 Enter를 누르는 길과, 앱 안에서 다른 페이지를 누른 뒤 본문으로 안내하는 길을 나눠 확인했다. 일반 클릭 때 로고를 가린다는 이유로 본문 바로가기 자체를 없애는 수정은 하지 않았다.

자동 처리를 끈 뒤에는 누가 전환을 맡는지 정해야 한다

발견 기록은 프레임워크의 자동 초점 처리와 앱의 본문 초점 처리가 겹쳤다고 설명한다. 자동 처리에서 문서 앞쪽의 바로가기 링크에 초점이 가면서 로고 위로 나타나는 문제가 있었다. 현재 이동 함수는 라우터의 자동 스크롤 처리를 끄고 앱이 관리하는 전환을 사용한다.

그러나 옵션 하나를 바꾼 첫 수정으로 끝나지 않았다. 첫 독립 재검증은 경로 이동 후 초점이 본문이 아닌 BODY에 남는다고 보고했다. 바로가기 링크가 로고를 덮는 모습이 사라져도 키보드 이동의 목적지가 정해진 것은 아니었던 것이다.

이 사례를 다른 앱에 옮길 때 scroll:false를 먼저 복사하기보다 현재 누가 위치와 초점을 관리하는지 확인할 필요가 있다. 자동 기능을 끈 뒤 앱이 어떤 전환을 대신 수행하는지, 실제로 그 전환이 실행되는지까지 확인해야 같은 빈틈을 피할 수 있다.

페이지가 다시 만들어져도 이전 경로를 알아야 했다

첫 수정본은 컴포넌트 안의 ref에 이전 경로를 보관했다. 그런데 경로 페이지가 다시 마운트되면 그 ref도 새 경로로 시작했다. 비교할 이전 값이 사라져 경로가 바뀌었다는 조건을 잡지 못하는 경우가 남았다. 이 원인은 첫 수정본과 후속 코드, 부분 실패 기록을 함께 봐야 드러난다.

후속 수정은 클라이언트 effect 안에서 이전 경로를 모듈 수명의 값으로 이어 보게 했다. 컴포넌트가 다시 만들어지는 순간에도 이전 경로와 새 경로를 비교하고, 본문 준비 상태를 기다린 뒤 예정한 초점을 적용한다. 이것은 이 앱의 연결 구조에 맞춘 처리다. 새로고침 뒤의 읽던 위치나 모든 뒤로 가기 동작을 저장하는 기능으로 설명하지 않는다.

늦게 끝난 데이터 갱신이 사용자의 입력을 가로채지 않도록 한 조건도 있다. 이미 본문 안의 다른 조작부에 초점이 있다면 본문 영역으로 다시 빼앗지 않는다. 로딩이 끝났다는 사실만으로 사용자가 방금 시작한 편집보다 초점 이동을 앞세우지 않으려는 선택이다.

다시 눌러 보는 검수는 결과와 위치를 함께 읽는다

최종 독립 보고서는 작은 화면에서 분야 선택값, 결과 개수와 버튼 초점, 목록의 위치를 함께 확인했다. 다른 페이지로 이동하는 순서에서는 로딩 뒤 본문에 초점이 오는지도 확인했다. 화면 폭은 320·390·768·1440px로 범위를 나눴지만 각 폭에서 모든 조합을 같은 깊이로 검사한 기록은 아니다.

필터 전후 스크롤 좌표가 언제나 정확히 같다고도 해석하지 않는다. 보고서에는 검사 도구가 대상을 보이게 스크롤한 구간이 표시돼 있다. 여기서 읽은 핵심은 필터 선택 때문에 의도치 않게 맨 위로 보내지지 않고, 선택 버튼과 결과를 이어서 확인할 수 있었는가다. 좌표 한 숫자와 사용 흐름의 확인을 구별한다.

증거의 버전도 나눴다. 첫 독립 검사에는 화면 캡처가 있고, 최종 초점 수정 뒤 검사에는 캡처 도구 시간 초과로 새 이미지가 없다. 최종 클릭·초점·문서 폭은 DOM과 접근성 정보의 관찰로 남아 있다. 앞선 캡처를 마지막 코드에서 새로 찍은 화면으로 바꾸어 표시하지 않는다.

여기까지는 기존 보고서와 코드 구간을 대조한 결과다. 이번에는 원래 서비스의 시험이나 배포·브라우저 클릭을 다시 실행하지 않았다. 물리 휴대폰의 터치·키보드, 모든 링크 조합, 실제 가입·메일·지원 업무는 이 글의 확인 범위에 포함하지 않는다.

버튼마다 다음에 읽을 곳을 적어 본다

다른 서비스에 적용하려면 각 버튼과 링크가 사용자를 어디에 남겨야 하는지 적어 본다. 같은 목록을 좁히는지, 다른 화면을 여는지, 항목을 지운 뒤 대체 초점이 필요한지 구분하고 실제 라우터와 앱 처리에 연결한다.

아래는 이 사례에서 가져온 전환 기준을 정리한 설명이다. 복사해서 실행하는 범용 라우터나 새 모듈은 아니다. 기존의 검색 조건 보존 기능은 그대로 쓰되, 화면 위치와 초점의 규칙은 사용하는 앱의 전환 과정에 맞춰 확인해야 한다.

1. 선택값과 결과가 함께 바뀌며, 결과를 보려고 처음부터 다시 이동하지 않는가.
2. 마우스로 보기 좋은 위치와 키보드로 이어갈 위치를 각각 확인했는가.
3. 페이지 재마운트와 늦은 데이터 응답에서도 정한 전환이 실행되는가.
4. 자동 처리와 앱 코드 중 누가 각 동작을 맡는지 설명할 수 있는가.
5. 앞선 화면 캡처와 최종 버전의 클릭·초점 기록을 구별해 남겼는가.

같은 프로필의 분야 선택
  조건을 주소에 반영 → 목록 변경 → 선택 버튼과 결과를 이어서 확인

다른 페이지로 이동
  경로 변경 → 앱이 정한 시작 위치 → 새 본문 준비 → 본문 초점

처음 주소를 직접 열기
  초기 화면 → 키보드 Tab → 본문 바로가기 → Enter → 본문 초점

데이터를 기다리는 중 사용자가 입력을 시작함
  현재 입력 초점 보존 → 늦은 갱신으로 초점을 다시 빼앗지 않기