기초
-
next.js14에 의하면 next.js App router 방식을 제공한다. App router방식은 파일과 폴더를 기반으로 라우팅이 자동으로 작동한다. app router방식에 확정된 폴더 구조라는거는 사람마다 폴더를 세팅하는게 다르기 때문에 자율적으로 하면 된다고 생각한다. 하지만 이제 app router방식의 규칙에는 따라야 한다. app router방식은 app하위에 폴더를 asdf라고 생성했다고 생각하자. 그럼 /asdf라는 주소의 페이지가 생성된다. 그 다음은 asdf하위에 page.js나 route.js라는 컴포넌트 파일을 생성하면 /asdf 주소에 반응하여 컴포넌트가 보여진다.
-
밑에 사진처럼 app router는 라우팅을 제공한다.
next.js의 component
- server component next.js에서 아무 설정 없이 만든 컴포넌트는 일반적으로 서버 컴포넌트이고 서버에서 실행되고 렌더링 된다. 특징으로는 html에 js기능과 useState와 useEffect 등을 사용이 불가 하다는 점이다. 그래서 SSR을 구현해야 할 때 쓰는 편인 거 같다. 대신 빠른 로딩 속도와 검색엔진 노출에는 유리하다.
- client component 클라이언트(브라우저)에서 실행되고 렌더링 된다. 코드의 시작 전에 ‘use client’라고 적고 시작하면 밑의 코드는 클라이언트 컴포넌트이다. 위에선 말한 js기능 onClick이나 react의 hooks인 useState, useEffect 등을 사용하려면 클라이언트 컴포넌트에서 사용 할 수 있다. 대신 js코드가 많고 hydration이 필요해서 로딩 속도가 느리다. hydration은 쉽게 말해서 server-side에서 렌더링 된 html과 번들링 된 js파일을 클라이언트에서 합치는? 매칭 시키는 과정이다.
결론 : 큰 의미에서 페이지에서는 server component를 사용하고 js기능이 필요한 부분은 분리 시켜서 client component로 만드는 게 좋은 거 같다.
route group app라우터 구조에서 문제점이 너무 많은 라우트 지점들을 생성하고 라우팅을 하다 보면 폴더 구조가 매우 복잡해진다는 것이다. 예시로 아래와 같이 폴더가 많아져서 만든 사람도 구분하기 힘들어진다.
그럴 때 route group이 유용하다. (name)이렇게 폴더를 만들고 관련된 라우트가 될 수 있는 페이지들을 그룹화 시키는 것이다. 아래처럼 역할에 따라서 그룹화 시켜 라우팅을 하면 좀 더 효율적이고 알아보기 쉽다!
