Next.js 는 pages 라는 폴더내에 파일을 작성하면 자동으로 라우팅을 해준다. pages/manual
⇒ /manual
정적인 라우팅 이름이 아닌, 유저 이름같이 동적인 변수로 라우팅을 해주고 싶은 경우,
파일 이름을 [변수명].tsx (typescript 인 경우) 으로 해주면 된다.
이번 프로젝트에서는 유저 페이지의 경로를 <hostname>/users/[intraId]
로 정하여
S3 와 Cloudfront 를 사용해 배포했다.
그러나 여기서 문제가 발생했다.
<hostname>/users/[intraId]
로 된 페이지에서 새로고침을 하면 404 가 뜨는 것이다.
S3은 정적으로 빌드된 파일을 저장하는데 [intraId].tsx 파일로 그대로 저장되어있는 것이 문제였다.
만약 main 페이지에서 sujpark 이라는 아이디를 가진 유저페이지로 가는 링크를 클릭한다면
자바스크립트 코드가 /users/[intraId] 파일을 찾아서 /users/sujpark 페이지로 렌더링을 하지만
/users/sujpark 페이지에서 새로고침을 한다면, 즉 url을 통해 직접 접근한다면
/users 폴더에서 sujpark.tsx 파일을 찾으려고 할 것이고,
sujpark.tsx 파일은 존재하지 않기 때문에 404 에러가 뜨게 된다.
이를 해결하는 방법으로
- 동적라우팅을 사용하지 않고 변수를 url 쿼리로 처리하기
- Next.js 의 getStaticPaths, getStaticProps 함수를 사용해서 빌드시 각 유저의 정적 페이지를 모두 만들기
가 있다.
2를 사용하면 페이지를 렌더링 한 후 서버에 데이터를 요청할 필요 없이 빌드과정에서 페이지가 모두 만들어지기 때에 성능상으로 훨씬 이점을 가질 수 있다.
하지만 getStaticPaths, getStaticProps 함수를 모두 작성해야할 뿐 아니라, 모든 유저명을 보내주는 API를 서버에서 새로 만들어야한다.
동적라우팅의 문제를 알게된 시점은 출시를 앞두고 있는 상황이었기 때문에 우선 1의 방법을 사용하고, 출시 후 업데이트할 때 2의 방법을 사용하기로 했다.
[intraId].tsx 파일의 이름을 detail.tsx 로 바꾸고,
/users/detail?intraId=sujpark
라는 url 로 접근하면
const { intraId } = router.query()
코드를 통해 intraId를 받아와 유저에 대한 데이터 요청에 사용할 수 있다.
이때 유저페이지로 향하는 링크들의 href 도 모두 바꿔주는 것을 잊어서는 안된다.
// 변경 전
<Link href={`/users/${intraId}`}>...</Link>
// 변경 후
<Link href={`/users/detail?intraId=${intraId}`}>...</Link>