페이지가 바뀌면 클릭 연결도 바뀌어야 했다

교육 콘텐츠에는 설명 안의 특정 요소를 눌러 다음 동작을 일으키는 기능이 있었다. useClickable 같은 훅으로 클릭 가능한 요소를 찾고 이벤트를 연결하면서, 페이지가 바뀌었을 때 연결도 다시 갱신되어야 했다. React 컴포넌트 안에서 선언적으로 끝나는 버튼과는 작업 방식이 달랐다.

화면과 이벤트가 같은 속도로 바뀌지 않았다

설명 콘텐츠가 바뀌면 DOM도 바뀐다. 이전 요소에 붙인 이벤트를 그대로 두면 새 요소는 반응하지 않을 수 있다. 반대로 갱신할 때마다 등록만 하면 기존 연결의 수명을 설명할 수 없게 된다. 화면에 보이는 내용이 맞아도 클릭 동작은 이전 상태를 참조할 수 있다.

이 작업에서 중요했던 것은 클릭 여부를 저장할 useState 하나가 아니었다. 어떤 콘텐츠 버전에 대해 이벤트를 연결했는지, 언제 연결을 끊어야 하는지였다. 페이지 번호만 볼 것인지, 실제 콘텐츠 교체를 기준으로 볼 것인지도 구별해야 했다.

지금의 검토 순서

먼저 이벤트 대상이 React가 직접 만드는 요소인지 외부 콘텐츠가 만든 요소인지 확인하겠다. 전자라면 onClick으로 의도를 드러내는 편이 자연스럽다. 후자라면 안정적인 상위 요소에서 이벤트를 위임할 수 있는지 살펴보겠다. 다만 위임은 중첩 요소를 클릭했을 때 어느 대상을 찾을지, 허용된 행동만 실행할지 별도 규칙이 필요하다.

직접 등록해야 한다면 등록 때 사용한 함수와 해제 때 사용하는 함수가 같아야 한다. 이때 최신 상태를 읽는 문제까지 무심코 합치지 않겠다. 이벤트 연결의 수명과 콜백이 읽는 값의 수명을 나눠 보면 의존성 배열을 왜 그렇게 적었는지 설명하기 쉬워진다.

검증도 왕복해야 했다

첫 페이지에서 한 번 누르는 것보다 페이지 A에서 B로 갔다가 A로 돌아오는 검증이 중요하다. 같은 클릭이 몇 번 처리되는지, 더 이상 화면에 없는 콘텐츠의 동작이 남아 있는지 확인할 수 있기 때문이다. 당시에는 이런 경계를 질문하며 수정해 갔고, 모든 경우를 자동화하지 못한 아쉬움도 남았다.

나는 이 경험으로 이벤트 리스너를 단순한 함수 연결이 아니라 정리해야 할 자원으로 보게 됐다. 등록 코드 옆에서 해제 조건을 설명할 수 없다면, 페이지가 늘어날수록 버그도 찾기 어려워진다.

기술 참고: React 외부 시스템과 Effect 동기화