신규 구조 상품인데 클릭하면 구 구조 /products/{id}/edit 로 간다는 이슈가 있었다. 신규면 신규 주소로 보내면 되는 간단한 일로 보였다.
Table of contents
Open Table of contents
문제 — 추측으로 제시한 경로
Vue Router 의 해시 라우터가 있으니 개별 상품 경로도 있을 것이라고 보고 #/products/{id} 형태의 주소를 제안했다. 그 링크가 실재하느냐는 되물음을 받았다.
routes.js 를 grep -rn VueRouter 로 저장소에서 찾아보니 신규 구조용 라우터가 없었다. 하나 나온 것은 구 구조 페이지의 것이었고 파일 맨 위에 // unused 라고 적혀 있었다.
원인 — 클라이언트 라우팅이 없는 구조
그러면 그 화면이 어떻게 도는지를 봤다. routes/web.php 가 Blade 템플릿을 렌더링하고 그 안에서 Vue 컴포넌트를 mount() 하는 방식이었다.
해시 라우터가 아니라 클라이언트 라우팅 자체가 없었고 개별 상품은 주소가 아니라 <ProductDialog> 로만 열리고 있었다. 개별 항목에 주소가 없는 설계라 신규 주소로 보낸다는 수정안이 성립하지 않았다.
기존 링크가 가는 곳
문제의 링크도 확인했다. Route::get('/products/{any}') 포괄 패턴에 매칭돼 구 구조 등록과 수정 페이지로 가고 있었고 이슈 내용 그대로였다.
내가 추측으로 제시한 링크는 실재하지 않았으므로 되물음이 없었으면 그 링크로 고치는 작업이 시작됐을 것이다. 그러고 나서 응답이 없다는 것을 확인하고 나서야 알았을 것이다.
조치 — 정리한 세 선택지
없다고 끝내지 않고 선택지를 정리했다. 신규 개별 수정 주소를 새로 만들거나 기존 주소에서 버전을 보고 목록으로 리다이렉트하면서 그 항목을 열게 하거나 애초에 링크로 만들지 않고 다이얼로그로 여는 방식에 맞추는 셋이다.
회신에는 두 가지 방법이 있었는데 셋 중 하나를 내가 골라 수정안으로 내는 것과 셋을 나란히 적고 결정을 요청하는 것이다. 뒤쪽을 골랐다. 이유는 어느 쪽이든 화면 설계가 바뀌는 것이라 개발자 혼자 정할 일이 아니라서다. 대신 결정이 날 때까지 이슈가 열린 채로 남는 것을 감수했다. 셋 중 하나를 먼저 정해야 링크 작업을 할 수 있으므로 이것이 신규 구조 관련 링크 작업의 전제 조건이라고 적었다. 어떻게 고치느냐가 아니라 무엇을 먼저 정해야 하느냐로 정리한 것이다.
주의 — 확인 안 한 경로를 제시한 실수
이 건에서 내 실수는 확인하지 않은 링크를 제시한 것 하나다. 해시 라우터가 있으니 그런 경로가 있을 것이라는 추론은 그럴듯하고 그런 구조가 흔하기도 하다.
그런데 흔한 것과 여기 있는 것은 다르며 routes.js 를 찾아보는 데는 30초면 된다. 제시하는 경로는 실재를 확인하고 제시하고 확인하지 않았으면 확인이 필요하다고 쓴다.
정리
- 수정안의 전제가 실재하는지 먼저 확인한다
- 보낼 대상이 없으면 그 안은 성립하지 않는다
- 흔한 구조와 여기 있는 구조는 다르다
- Blade 가 렌더링하고 Vue 컴포넌트만
mount()하면 클라이언트 라우팅이 없을 수 있다 - 개별 항목을 주소가 아니라 다이얼로그로만 여는 설계가 있다
- 없다고 끝내지 않고 선택지를 정리한다
- 어떻게 고치느냐가 아니라 무엇을 정해야 하느냐로 쓴다
- 확인 안 한 경로는 확인이 필요하다고 쓴다