구독의 시작과 끝 짝짓기, 실패를 설명할 단서 남기기
화면을 여러 번 열고 닫은 뒤 같은 이벤트가 중복 처리되는 문제가 생길 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
화면을 여러 번 열고 닫은 뒤 같은 이벤트가 중복 처리되는 문제가 생길 수 있다.
실패했다는 사실만으로는 다음 행동을 정하기 어렵다. 어떤 입력으로 어디까지 진행했으며 무엇을 기대했는지가 함께 있어야 한다. 이번에는 성공 여부를 표시하는 데서 한 걸음 더 나아가, 다음 사람이 같은 조건을 확인할 수 있도록 관찰 항목을 정리한다.
결과와 원인을 구분하는 기록
이벤트 등록, 타이머, 구독은 생성한 위치에서 해제할 방법도 함께 작성한다. 정리 함수는 자신이 만든 자원만 해제하도록 범위를 좁힌다.
이번에 확인할 질문: 결과만 전달받은 사람이 원래 입력과 기대 동작을 복원할 수 있는가?
작게 확인하는 예제
다음 예제는 핵심 조건을 드러내기 위한 출발점이다. 서비스의 전체 구현을 대신하지 않으므로 실제 입력 범위와 실패 처리 규칙을 함께 읽어야 한다.
useEffect(() => {
const update = () => setWidth(window.innerWidth);
window.addEventListener('resize', update);
update();
return () => window.removeEventListener('resize', update);
}, []);
컴포넌트를 반복해서 마운트한 뒤 이벤트 한 번에 처리 함수가 몇 번 실행되는지 확인한다.
놓치기 쉬운 조건
등록할 때와 해제할 때 서로 다른 함수 객체를 넘기면 이벤트가 제거되지 않는다. 의존성을 생략해서 오래된 값을 읽는 문제를 숨기지 않는다.
| 확인할 부분 | 살펴볼 내용 |
|---|---|
| 기준 동작 | 컴포넌트를 반복해서 마운트한 뒤 이벤트 한 번에 처리 함수가 몇 번 실행되는지 확인한다. |
| 비교 조건 | 입력과 실행 순서를 고정하고 한 번에 한 조건만 바꾼다. |
| 적용 범위 | 예제가 생략한 의존성과 실제 서비스의 제약을 구분한다. |
다음 변경에 적용할 순서
- 기대 결과와 실제 결과를 서로 다른 칸에 적는다.
- 개인정보나 비밀값을 제외하고 재현에 필요한 조건만 남긴다.
- 관찰 사실과 원인에 대한 가설을 구분해 후속 확인을 정한다.
기록을 많이 남기는 것과 유용하게 남기는 것은 다르다. 원인을 좁히는 데 쓰이지 않는 항목은 줄이고, 누락 때문에 다시 묻게 되는 조건은 보완한다. 관찰할 수 있는 범위가 분명해지면 실패한 상황에서도 다음 실험을 작게 잡을 수 있다.
이 이야기가 도움이 되었나요?