페이지네이션을 적용한 gatsby 블로그에서 404 에러가 발생했다.
첫번째 페이지에선 게시글에 달린 <Link>
가 정상 작동했는데,
2번째 페이지에서부터 같은 링크를 클릭하니 404 에러가 떴다.
정상적인 게시글의 location.pathname
은 "/{article-slug}"
다.
두 번째 페이지에서 게시글을 클릭하면 "/page/2/{article-slug}"
로 이동하면서 404 에러가 뜬다.
처음엔 pagination 에러인 줄 알고 기존 프로젝트에 적용된 gatsby-paginate 플러그인의 소스 코드까지 다 읽어봤는데 문제는 router에 있었다.
gatsby만의 독특한 <Link>
의 문제였다.
Gatsby의 <Link>
의 기반이 되는 reach-router
는 location.pathname
을 디렉토리 경로처럼 이해한다.
The component follows the behavior of @reach/router by ignoring trailing slashes and treating each page as if it were a directory when resolving relative links. For example if you are on either /blog/my-great-page or /blog/my-great-page/ (note the trailing slash), a link to ../second-page will take you to /blog/second-page.
두번째 페이지의 location.pathname
은 "/page/2"
이다.
이 상태에서<Link to={article-slug}>
를 클릭하면 그 하위 디렉토리로 이동하면서 "/page/2/{article-slug}"
라는 이상한 경로가 매핑된 것이다.
sub-directory로 더 깊게 들어가지 않도록 <Link>
의 to
props를 작성해야 한다.
여기에는 2가지 방법이 있다.
<Link to="../../" + {article-slug}/>
<Link to= "/" + {article-slug}/>
둘 중에 어떤 방법이 더 좋아보이나?
내 생각엔 절대 경로 방식이 더 좋아보인다.
상대 경로를 사용하면 안 좋은 점은 다음과 같다.
<Link>
가 보여지는 장소의 location.pathname
을 프로그래머가 항상 염두에 두고 있어야 한다. paginatedPath
, prefix
, buildPath
변경 등)2번처럼 절대 경로를 이용하면, 프로그래머가 <Link>
가 보이는 장소의 location.pathname
를 몰라도 의도대로 라우팅을 할 수 있다.