Next.js, React 개발시 개발과 배포의 차이를 확인하기 위한 개발자 도구
서버가 클라이언트에게 데이터나 html을 전달하면서 사용한리소스, 시간 등을 크롬 F12 개발자도구의 network 탭에서 확인할수있다.
yarn이든 npm이든 개발을 할 때는 보통 run dev 명령어로 Next 앱을 실행하는데, 이때는 사용하는 리소스, 시간 전달된 데이터 용량 등 많다. 그리고 콘솔창에서 앱에서 실행되는 내용이 출력되어 여러모로 느리다!
배포를 할때는 run build , run start 를 입력하여 .Next 폴더안에 배포용 넥스트앱을 빌드하고 실행시킨다 이때는 사용하는 리소스, 시간, 전달된 데이터 용량 등이 적다.
라우팅
https://paralleldev.tistory.com/5/sss
이 링크에서
[paralleldev.tistory.com](<http://paralleldev.tistory.com>) 은 도메인
5/sss 는 path, 그리고 path안의 각각의 5, sss는 segment라고 부른다.
어떤 컨텐츠를 어떤 방식으로 보여줄것인가를 결정하는것이 라우팅이다.
Next.js에서는 기본적으로 root페이지를 열면 layout.ts안의 RootLayout의 리턴값을 화면에 렌더링하고자하는데, 이때 그럼 children이 무엇이냐?
아무것도 지정하지 않으면 page.tsx의 내용이 children으로 들어가게된다.
이런 구조를 가지고 있다고 했을때, 내가 localhost:3000/create라는 주소로 접속을하면,
Next.js앱은 app 디렉토리 안에서 가장 먼저 create(path의 segment)라는 폴더가 있는지를 조사한다.
먼저 page.tsx 관점에서 얘기하겠다. (뒤에서 layout.tsx관점에서 얘기하겠다는 뜻)
page.tsx
- create 폴더가 있다면, 다른 폴더나 루트 디렉토리에 page.tsx가 있는지 조사하여 있다면 해당 내용을 일단 가져온다
- create 폴더가 없다면? 혹은 create 폴더만 있고 page.tsx 파일이 없다면?
2. 번 상황의 결과는 404 Error가 뜨게된다. 아래 사진처럼
그러면 이제 가져온 page.tsx로 뭘 하냐! 얘를 추가해서 최종적으로 페이지에 보여줄 layout을 찾아야한다.
layout.tsx
- create폴더에 layout.tsx 도 있다면, page를 해당 layout의 children에 집어넣은 후 클라이언트에게 준다(화면에 보여준다.)
- create폴더에 layout.tsx 는 없다면 page를 children으로 추가할 layout을 directory를 재귀적으로 부모 디렉토리로 이동하면서 찾는다.
이게 static routing의 내용이였음 근데 라우팅되는걸 확인할떄 크롬 개발자모드를 키고 보면, 페이지 라우팅 할때마다 계속 자원이 오가고 reload를 하는것을 확인할 수 있다.
next.js는 서버 사이드 렌더링(SSR)이라고 react와달리 next.js는 disable javascript를 한 상태에서도 렌더링이 가능하다!
좀더 정확히 얘기하면 react는 서버에서 받아온 javascript를 통해 웹페이지로 만들어내서 짠! 하고 보여주는거라면 next는 그냥 서버에서 짠 하고 html을 준거다.
그래서 생기는 장점은 SEO라거나 뭐 여러가지 있는데 지금은 단점이 중요하다
주소 path가 변경될때마다 다시 렌더링할 페이지(html) 전체를 다운로드해야하고,
사용자와 상호작용하여 변경되는 부분이 html 파일 내의 극히 일부더라도 다시 html 전체를 다운로드하고 렌더링한다.
이럴거면 js로 데이터 받아서 렌더링하지!(React가 렌더링 하는 방식) 뭣하러 레퍼런스도 부족한 Next.js를 쓰냐고 생각할때 검색하니까 하이퍼링크에 a 태그를 사용해서 생긴 문제라는 걸 깨달았다.
import Link from "next/link";
export default function Home({ children }: { children: React.ReactNode }) {
return (
<h1>
<a href="/">홈페이지 </a>
href 링크를 제공하는 a 태그 대신 Link태그를 사용하면 Next.js의 진가를 볼수있다.
Link 태그
a 대신 Link태그로 변경하면 Next.js가
마우스를 새로운 하이퍼링크에 갖다대는 것 만으로도 서버에서 이미 해당 html을 클라이언트(나)에게 전달해주고, 하이퍼링크를 클릭하면 새로고침 없이 받아온 html을 보여주기만하면된다, 심지어!
이미 방문한 페이지에 대해서는 다시 서버에서 html을 주지도 않는다. 당연하겠지만~
클라이언트입장에서는 해당 페이지에 대해 캐시?(정확하진 않으니 알아봐야겠다) 로 뭔가 많이 클라이언트가 html파일들을 가지고있어야하겠지만, 문제가될만큼 많지 않다면
사용자 입장에서는 빠른 렌더링 서버 입장에서는 비용 절감 효과를 낼수 있다.
여기까지가 Next.js의 정적 라우팅과 정적 라우팅을 SPA 방식으로 Next.js 하는법.
동적 라우팅
아까 하이퍼링크를 조금 수정해서 다시 가져와 설명하면,
https://paralleldev.tistory.com/asdf/2
[paralleldev.tistory.com](<http://paralleldev.tistory.com>) 은 도메인
asdf/2 부분이 나의 path이며, 특히 여기서 /2 이 세그먼트에 집중하면,
2라는 페이지를 우리가 만들어서 정적 라우팅하는 이상한 의도가 아니라면, 이는 동적 라우팅을 의미하는것이다.
예를 들면 사용자가 2번 째 글을 읽으러 왔기 때문에 2라고 나온것이다.
그럼 Next.js가 이를 알아들을 수 있어야 하는데 그 방법은 디렉토리를 보며 이해해보자
디렉토리에서 app\read\[id]에 주목해보자, 여기서 [id]부분이 아까 예시에서 /2 세그먼트에 해당하는 부분인것,
[id]폴더에는
export default function Read({ params }: { params: { id: number } }) {
return (
<>
<h2> read</h2>
{params.id}
</>
);
}
위와같이 쓰여있는데, Read function에 전달되는 params가 바로 id이다!
그리고 js와 다르게 ts는 any type의 params를 싫어한다.
만약 위 코드 대신 인터넷에 떠도는 대로,
export default function Read(params) {
return (
<>
<h2> read</h2>
{params.id}
</>
);
}
이런 식으로 작성한다면 바로 Parameter ‘params’ implicitly has an ‘any’ type 에러를 뱉을 것이다.
이는 ts가 function의 정의부를 이해해야 매개변수의 타입을 이해할 수 있고 type에 맞게 활용할 수 있다는 js의 단점을 극복하기 위해 컴파일러 차원에서 하는 일이다.
type을 직접 지정해줘야한다.
export default function Read({ params }: { params: { id: number } }) {
params의 type이 number이고, id라는 이름이다 라고 디렉토리에 맞춰서 지정해줘야 동적 라우팅이 가능함