다운로드 목록을 정리하려고 휴지통을 눌렀는데 받은 파일까지 사라지면 사용자의 예상과 어긋날 수 있다. 업무 브라우저의 실제 개발 기록과 다운로드 코드를 읽으며, 같은 삭제라는 말 안에 섞여 있던 행동을 나눴다.
삭제할 대상의 이름부터 분명히 했다
다운로드 기록에는 이름과 상태, 받은 양과 원래 주소, 프로필과 작업 문맥이 있다. 실제 파일은 별도로 디스크에 남는다. 기존 구현의 removeDownloadHistory는 기록 배열과 저장 함수를 다루며 파일을 지우는 함수를 호출하지 않는다. 나는 이 차이가 버튼 가까이에서 이해되어야 한다고 보았다.
목록 정리가 목적이라면 기록만 제거하고 파일은 유지한다. 파일 자체를 지우는 기능이 필요하면 그 대상과 결과를 별도로 설명해야 한다. 이번 글은 고객 파일을 삭제한 경험을 꾸민 것이 아니라, 실제 구현에서 파일과 이력의 책임을 어떻게 나눴는지 설명하는 제작기다.
끝난 기록과 살아 있는 전송을 나눴다
기록 모두 삭제가 화면에 보이는 모든 것을 없애는 명령은 아니다. removableDownload는 진행 중과 일시정지, 다시 받는 중인 항목을 보존한다. 같은 프로필에서 선택한 종료 기록만 대상으로 삼는다. 전송이 살아 있는데 목록에서 사라지면 사용자는 취소와 재개를 어디서 해야 하는지 모를 수 있다.
표시된 일부 행과 실제 저장 목록의 범위도 다르다. 당시 작업 기록에는 작은 창의 표시 범위 밖에 종료 항목이 있어도 전체 삭제 가능 여부를 계산하도록 확인한 내용이 있다. 다만 이 기능의 이름만으로 모든 보관 정책과 정리 대상이 정해지는 것은 아니다. 실제 앱의 범위를 설명해야 한다.
저장 실패를 되돌릴 때 새 기록을 잃지 않는다
화면에서 기록을 뺀 뒤 저장이 실패하면 제거했던 행을 복구한다. 여기서 작업 시작 때의 배열 전체를 덮어쓰면 저장을 기다리는 동안 추가된 다운로드를 잃을 수 있다. 기존 함수는 제거한 행만 현재 배열에 다시 넣으며 같은 id와 profileId가 이미 있는지도 확인한다.
시험에는 저장 콜백이 새 진행 기록을 추가한 뒤 오류를 내는 경우가 있다. 복구 후에는 새 기록과 이전 기록, 다른 프로필의 같은 id가 모두 남아야 한다. 이 반례는 실패했다는 안내만 띄우는 것보다 더 구체적인 복원 계약이다. 실패 복구도 현재 자료를 존중해야 한다.
다시 받기는 재개와 같은 행동이 아니다
실패·취소한 기록은 저장한 네트워크 주소로 새 전송을 시작할 수 있다. 살아 있는 일시정지 전송의 재개와는 다르다. 기존 RetryDownloads는 같은 프로필에서 같은 원본을 다시 받는 요청을 직렬화하고 새 전송에 원래 탭과 프로젝트 문맥을 붙인다. 지금 보이는 다른 계정의 탭을 대신 쓰지 않는다.
원래 주소가 없는 옛 기록과 페이지 안에서만 만들어진 리소스는 무조건 재생성할 수 없다. 코드도 페이지 주소에서 파일 주소를 추측하거나 작성 요청을 재전송하지 않는다. 받은 파일을 다시 찾기 쉽게 만드는 편의 기능이 기존 작업과 계정 경계를 넓히지 않도록 한 것이다.
당시 시험과 이번 확인을 구별했다
개발 당시 보고서에는 소유한 시험 프로필과 로컬 전송 서버로 취소·재다운로드·기록 삭제·재시작을 확인한 결과가 있다. 받은 바이트와 해시, 기존 탭과 입력 보존도 포함한다. 이번 콘텐츠 작업에서는 그 보고서와 관련 함수·시험 코드를 대조했으며 같은 브라우저 시험을 새로 실행하지 않았다.
실제 사용자의 다운로드 이력을 삭제하는 검수도 하지 않았다. 원본 보고서의 시험 개수를 이번 실행 개수처럼 가져오지 않는다. 파일 이름과 계정, 실제 다운로드 주소를 공개하지 않고 새 글에서는 동작의 관계만 설명한다. 과거 검증과 현재의 자료 검토는 서로 다른 근거다.
익숙한 아이콘에도 정확한 약속이 필요하다
휴지통과 다시 시도는 익숙한 그림이라 설명을 줄이기 쉽다. 하지만 기록과 파일, 재개와 재다운로드의 차이를 생략하면 사용자가 예상하는 일이 달라질 수 있다. 나는 아이콘을 더 많이 넣는 것보다 어떤 상태에서 어떤 행동을 허용하는지 분명하게 만들고 싶었다.
기존 업로드 모듈의 조각 재개와 이번 다운로드 기능도 같은 프로그램이 아니다. 업로드는 서버가 받은 조각을 대조하고, 이 글은 네이티브 전송과 프로필별 목록을 다룬다. 공통 단어 때문에 구현을 섞지 않고 각 책임을 설명하면 다른 홈페이지의 관리자 파일 목록에도 판단을 적용할 수 있다.