Github
Next.js를 선택하는 것은 단순히 인기가 있기 때문만은 아닙니다. 프로젝트의 목표와 요구 사항에 맞춰 가장 적합한 기술을 선정하는 것이 중요합니다. Next.js, Vite, 혹은 다른 프레임워크를 사용할지 결정할 때, 프로젝트의 방향성과 필요성을 고려해야 합니다.
Next.js는 서버 사이드 렌더링(SSR)을 통해 초기 페이지 로딩 속도를 개선하고, 검색 엔진 최적화(SEO)에 유리한 점이 특징입니다. 또한, 자동 코드 분할, 최적화된 이미지 로딩, 정적 사이트 생성(Static Site Generation, SSG)과 같은 고급 기능을 제공합니다. 이러한 기능들은 웹 애플리케이션의 성능을 향상시키고, 개발자 경험을 개선할 수 있습니다.
반면, Vite는 빠른 콜드 스타트와 모듈 재구성 시간을 제공하는 현대적인 개발 서버로, HMR(Hot Module Replacement)을 통한 빠른 개발 경험을 제공합니다. 프로젝트가 큰 규모의 애플리케이션이 아니거나, SSR보다는 빠른 개발과 테스트를 중시하는 경우 Vite가 더 적합할 수 있습니다.
따라서, 프로젝트의 필요성에 따라 Next.js의 서버 사이드 렌더링과 SEO 친화적인 특성이 필요한지, 아니면 Vite의 빠른 개발 환경이 더 큰 장점으로 작용하는지 고려해야 합니다. 이 외에도 다른 프레임워크가 프로젝트의 요구 사항을 더 잘 충족시킬 수 있는지도 검토해야 합니다. 결국, 선택하는 기술은 프로젝트의 성공을 위해 가장 적합한 도구여야 합니다.
Next.js homepage
Next.js홈페이지의 강조하는 문장
Peerless performance, efficiency and developer experience. Next.js is trusted by some of the biggest names of the web.
뛰어난 성능, 효율성, 그리고 개발자 경험. Next.js는 웹의 가장 큰 이름들에 의해 신뢰받고 있습니다.
Next.js를 설명하면 항상 나오는 단어가 있습니다. 바로 SSR입니다.
SSR(Server Side Rendering)이 어떤 장점이 있길래 다들 좋아하는 걸까?
A powerful framework for building high-performance, server rendered web applications
고성능 서버 렌더링 웹 애플리케이션을 구축하기 위한 강력한 프레임워크입니다.
위에서 본것과 같이 이전에는 Next.js는 Full-stack web applications를 강조했지만, 이제는 더 나아가 성능과 SSR이 뛰어나지 못해 강력하다는 것을 장점으로 내세우는 것을 볼 수 있습니다.
자료 출처 : https://www.smashingmagazine.com/2024/05/forensics-react-server-components/
SSR은 client(browser)가 server에 매번 data를 요청하여 서버에서 처리하는 방식입니다. 클라이언트에서 요청이 들어올 때마다 매번 서버에서 새로운 화면을 만들어 제공합니다. 다시말해, server가 화면을 그리는 주체가 되는 것 입니다.
향상된 초기 로딩 속도: SSR을 사용하면 서버에서 미리 페이지를 렌더링하여 클라이언트로 전송합니다. 이로 인해 사용자는 데이터를 기다릴 필요 없이 거의 즉시 페이지를 볼 수 있습니다. 이는 특히 초기 페이지 로딩 시간이 중요한 웹 애플리케이션에 있어 큰 이점으로 작용합니다.
검색 엔진 최적화(SEO) 개선: 서버 사이드 렌더링을 통해 생성된 페이지는 검색 엔진이 더 쉽게 크롤링하고 인덱싱할 수 있습니다. 이는 웹사이트의 검색 엔진 결과 페이지(SERP) 순위를 높일 수 있으며, 특히 동적인 데이터를 많이 사용하는 웹 애플리케이션에 있어서 중요합니다.
소셜 미디어 최적화: SSR을 사용하면 소셜 미디어 플랫폼이 웹 페이지의 메타 데이터(예: 제목, 설명, 이미지 등)를 더 잘 읽을 수 있어, 공유될 때 보다 매력적인 미리보기를 생성할 수 있습니다. 이는 사용자 참여를 증가시키고 웹사이트 트래픽을 늘리는 데 도움이 됩니다.
향상된 사용자 경험: SSR을 통해 빠른 페이지 로딩을 제공함으로써 사용자 경험이 향상됩니다. 사용자는 빠른 상호작용을 경험하게 되며, 이는 특히 모바일 사용자에게 중요합니다. 또한, SSR은 네트워크 연결이 불안정한 환경에서도 더 나은 성능을 제공할 수 있습니다.
Next.js는 이러한 SSR의 장점들을 쉽게 활용할 수 있게 해주는 프레임워크입니다. 서버 사이드 렌더링 외에도, Next.js는 정적 사이트 생성(Static Site Generation, SSG)과 클라이언트 사이드 렌더링(Client Side Rendering, CSR)을 지원하여, 개발자가 애플리케이션의 요구사항에 맞춰 최적의 렌더링 전략을 선택할 수 있도록 합니다. 이러한 유연성과 SSR의 장점을 결합한 것이 Next.js를 매우 인기 있는 선택으로 만들고 있습니다.
서버가 화면을 그리는 구조는 몇 가지 중요한 장점을 제공합니다. 첫째로, 첫 페이지 로딩 속도가 클라이언트 측 렌더링(CSR)에 비해 상당히 빠릅니다. 이는 CSR에서는 첫 페이지에 해당하는 문서만 브라우저로 전송되고, 브라우저가 렌더링을 담당하기 때문에 초기 로딩이 느린 반면, 서버 측 렌더링(SSR)에서는 서버가 화면을 미리 그려 전달하기 때문에 사용자가 보다 신속히 화면을 볼 수 있습니다. 둘째로, 검색 엔진 최적화(SEO) 측면에서 더 우수합니다. 이는 검색 엔진이 콘텐츠를 더 잘 이해하고 인덱싱할 수 있게 해줍니다.
하지만 SSR이 가진 장점만큼 단점도 존재합니다. 서버에서 화면을 그리고 전달하는 구조는 초기 로딩 이후 페이지 이동 시 속도가 다소 느릴 수 있습니다. CSR에서는 이미 클라이언트에 필요한 데이터를 렌더링해 둔 상태에서 페이지 이동이 발생할 경우, 새로운 데이터만 갈아끼우는 방식이지만, SSR에서는 서버로부터 응답을 받고 그 내용을 렌더링하는 과정이 필요하기 때문에 시간이 더 소요됩니다.
이러한 SSR의 단점을 극복하기 위해 Next.js는 'Hydration'이라는 개념을 도입했습니다. 간단히 말해, SSR과 CSR의 장점을 결합하여 사용자에게 더 나은 경험을 제공하는 것입니다. 이를 통해 SSR로 빠른 첫 페이지 로딩을 제공한 이후, 페이지 내에서의 이동은 CSR 방식으로 처리하여 사용자 인터페이스의 반응성을 높입니다.
Next.js를 학습하는 이유를 간략히 설명드렸습니다. 또한, Next.js 14버전의 앱 라우터 방식을 쉽게 이해할 수 있도록 도식화한 이미지도 함께 첨부했으니 참고하시길 바랍니다.
위 사진을 보며 하나씩 보겠습니다.
src에 있는 App아래에 모든 page들이 구성되어 있습니다. page로 구성하고 싶은 것들은 모두 Folder을 생성하고 그 안에 page.js를 생성한다라는 것을 볼 수 있습니다.
app router은 page router와 다르게 folder를 기준으로 합니다. 그렇기 때문에 page로 구성하고 싶은 것들은 folder을 page이름으로 정하고 그 안에 page.js라는 입력합니다.
그리고 page > children page을 구현하고 싶다면 main page의 folder안에 다시 folder을 생성하고 children page인 page.js를 넣습니다.
blog page의 children을 보면 다른 folder와 다르게 [ ] 대괄호을 표시한 것을 볼 수 있습니다.
Next.js에서 동적 라우팅을 구현할 때, 대괄호([ ])를 사용하는 것은 동적 페이지 경로를 정의하기 위함입니다. 예를 들어, 블로그에서 [slug]로 지정된 폴더에는 다양한 포스트가 있을 수 있고, http://localhost:3000/blog/post1 같은 URL을 통해 접근할 때 [slug]에 해당하는 post1이라는 값을 가진 페이지로 라우팅됩니다.
또한, Next.js에서는 소괄호(( ))를 사용하는 것에 대해서도 알게 되었습니다. 소괄호는 특정 폴더로의 직접적인 라우팅을 방지하는 용도로 사용됩니다. 소괄호로 묶인 폴더는 그 자체로는 라우팅 대상이 되지 않지만, 그 내부의 하위 폴더나 파일에는 접근할 수 있으므로, 그룹화를 위한 용도로 적합합니다. 이 구조를 사용하면, 소괄호로 묶인 폴더의 이름을 pathname으로 직접 추가하려고 할 때 404 에러가 발생하게 됩니다. 이러한 방식으로, 더 세밀한 라우팅 제어와 구조화된 폴더 관리를 할 수 있게 됩니다.
예시에서 언급한 것처럼, layout.js 파일의 기능을 통해 어떤 페이지는 "This is the Main Layout"을 보여주고, 다른 페이지는 "This is the Blog Layout"과 같이 다른 내용을 보여주는 것을 확인할 수 있습니다. 이는 layout.js가 앱의 메인 레이아웃을 정의하고, 그 안에 children 프로퍼티를 통해 각 페이지의 컨텐츠를 동적으로 렌더링하기 때문입니다. 따라서 모든 페이지가 메인 레이아웃을 공유하면서도, 특정 페이지에서는 추가적으로 다른 레이아웃을 보여줄 수 있게 됩니다.
이렇게 메인 레이아웃을 설정함으로써, 페이지 전체에 걸쳐 일관된 디자인과 구조를 유지할 수 있으며, 특정 페이지나 섹션에 대해 다른 레이아웃을 적용하고 싶을 때 유연하게 대응할 수 있습니다. 예를 들어, 블로그 페이지에서만 특별한 사이드바나 추가적인 요소를 포함하는 블로그 레이아웃을 적용할 수 있습니다.
export default function RootLayout({ children }) {
return (
<html lang="en">
<body className={inter.className}>
<h1>This is the Main Layout</h1>
{children}
</body>
</html>
);
}
경우에 따라 해당 page에서 children에게 보여줘야할 layout이 존재 할 수 있습니다. 그럴 경우에는 해당 folder안에 layout.js를 작성하여 해주고 children을 작성해주면 해당 folder의 children은 위 사진과 같이 "This is the Blog Layout"을 볼 수 있습니다.
const BlogLayout = ({ children }) => {
return (
<div>
<h2>This is the Blog Layout</h2>
{children}
</div>
);
};
export default BlogLayout;
비슷한 기능을 하지만 re-rendering(또는 re-mounting)이 필요한 경우에는 template.js를 사용하는 것이 좋습니다. 기본적으로 layout.js는 re-rendering을 하지 않습니다. 그러나 template.js를 사용하면 리마운팅을 할 수 있습니다. 레이아웃 기능을 유지하면서 페이지를 이동할 때마다 리마운팅이 필요할 경우 유용합니다. 예를 들어, 페이지 이동 시 구글 애널리틱스와 같은 기록이 필요한 경우에 사용됩니다.
개발을 진행할 때, 컴포넌트와 라이브러리는 app 폴더가 아닌 src 폴더에 넣는 것을 추천합니다. app 폴더 안에는 오직 페이지와 스타일만을 구성하고, 그 외의 모든 것들은 src에서 관리하는 것을 권장하고 있기 때문입니다. 이렇게 하면 프로젝트 구조가 더 깔끔해지고, 관리하기도 쉬워집니다.
Next.js learn
React Router DOM에서 자주 사용되던 ErrorComponent와 유사한 기능이 Next.js에서는 더욱 단순화되어 제공됩니다. Next.js에서는 앱 폴더 내에 error.js 파일을 만들어주기만 하면, 앱의 메인 페이지에서 오류가 발생할 경우 자동으로 해당 에러 컴포넌트로 연결하여 오류를 표시해 줍니다. error.js 파일을 사용할 때에는 "use client" 지시어를 반드시 포함시켜주어야 합니다. 이렇게 하면 클라이언트 측에서 오류 처리를 효율적으로 관리할 수 있습니다.
"use client";
const Error = () => {
return <div>⚠️Error⚠️</div>;
};
export default Error;
에러 컴포넌트가 에러를 확인하고 layout.js를 구성한 후 페이지를 호출하는 것이 아니라, 에러 컴포넌트 자체를 호출하는 과정을 확인할 수 있습니다.
에러 컴포넌트에서 등장하는 "use client"에 대해 알아보겠습니다.
Using Client Components in Next.js
To use Client Components, you can add the React "use client" directive at the top of a file, above your imports.
"use client" is used to declare a boundary between a Server and Client Component modules. This means that by defining a "use client" in a file, all other modules imported into it, including child components, are considered part of the client bundle. - Next.js Doc Client rendering
"use client"는 서버와 클라이언트 컴포넌트 모듈 간의 경계를 선언하는 데 사용됩니다. 이는 "use client"를 파일에 정의함으로써, 그 파일로 가져오는 모든 다른 모듈들, 자식 컴포넌트들을 포함하여, 모두 클라이언트 번들의 일부로 간주된다는 의미입니다.
Next.js의 공식 문서를 살펴보면, 클라이언트 렌더링의 장점을 활용한다는 것을 알 수 있습니다. React 훅을 사용하거나 이벤트와 같은 React의 문법을 사용하기 위해 "use client"를 작성하여 서버와 클라이언트 컴포넌트를 명확히 구분하고 있다는 점이 확인됩니다.
"Use client"는 클라이언트 사이드 렌더링(CSR) 또는 하이드레이션을 의미하는 용어일 수 있습니다. 이는 서버 사이드에서 렌더링된 페이지가 클라이언트(브라우저)로 전송된 후, 페이지의 일부 또는 전체가 클라이언트 사이드에서 다시 렌더링되거나 업데이트되는 과정을 가리킵니다. 특히, 에러 처리 시나리오에서 "use client" 접근 방식을 사용하면, 서버 사이드에서 발생한 에러를 클라이언트 사이드에서 적절히 처리하고 사용자에게 보다 친절한 피드백을 제공할 수 있습니다.
예를 들어, 에러 컴포넌트를 사용하여 서버에서 발생한 에러를 감지한 후, 이를 클라이언트 사이드에서 처리하여 사용자에게 에러 메시지를 보여주거나, 사용자가 다시 시도할 수 있는 옵션을 제공하는 등의 방식으로 활용할 수 있습니다. 이렇게 함으로써, 사용자 경험을 향상시키고 애플리케이션의 안정성을 높일 수 있습니다.
결론적으로, "use client"는 에러 상황에서 클라이언트 사이드의 처리를 강조하는 접근 방식을 의미하며, 이를 통해 보다 유연하고 사용자 친화적인 에러 처리가 가능해집니다.
URL 경로에 존재하지 않는 페이지로 이동할 경우, NotFound 페이지를 보여주는 것은 사용자 경험을 향상시키는 중요한 방법 중 하나입니다. Next.js는 이러한 NotFound 페이지를 보다 간편하게 구현할 수 있도록 지원합니다.
app경로 내에 not-found.js 파일을 생성하여 설정하면, Next.js는 자동으로 해당 파일을 애플리케이션의 기본 NotFound 페이지로 인식하고 사용합니다
이와 마찬가지로 위 사진을 보면 app경로안에 loading.jsx가 있습니다. Next.js에서는 앱의 로딩 경험을 개선하기 위해 매우 간단하고 효과적인 방법을 제공합니다. 특히, app 경로 내에 loading.jsx 파일을 추가함으로써, 개발자들은 사용자에게 보다 매끄러운 페이지 전환 시의 로딩 경험을 제공할 수 있습니다. Next.js는 이러한 접근 방식을 통해 개발자가 로딩 페이지를 쉽게 구성하고 관리할 수 있도록 지원합니다.
Error:
× You're importing a component that needs usePathname. It only works in a Client Component but none of its parents are marked with "use client", so they're Server Components by default.
추가적으로 개발 중에 위와 같은 에러를 발견하시면, 이는 'use client'를 의미합니다. 즉, 서버 컴포넌트가 아닌 클라이언트 컴포넌트를 변경해야 사용할 수 있다는 것을 알려줍니다.
패러렐 라우팅은 두 개의 페이지를 동시에 표시하고자 할 때 활용됩니다. 이 기법을 통해 모달 같은 UI 요소도 구현할 수 있습니다.
예를 들어, A 페이지와 B 페이지를 동시에 보여주고 싶다면, A 페이지의 layout.tsx 파일에 두 번째 속성(첫 번째 속성은 children)을 추가하여 원하는 위치에 배치해야 합니다. 그리고 B 페이지의 폴더 이름은 @로 시작해야 합니다. 중요한 점은, A 페이지와 B 페이지의 폴더가 같은 위치에 있어야 한다는 것입니다.
패러렐 라우팅을 활용할 때, '@' 폴더 내에 기본적으로 표시할 내용이 없는 경우, 'page.tsx' 대신 'default.tsx'를 사용할 수 있습니다. 'page.tsx'를 사용하는 것도 가능하지만, 특별히 표시할 내용이 없을 경우 'default.tsx'에서 null을 반환하도록 설정하는 것이 좋습니다.
인터셉팅 라우트는 폴더 이름 앞에 소괄호(), 마침표., 그리고 마침표 두 개..를 사용합니다. 이는 실제 폴더 구조와는 관계없이, 브라우저의 주소를 기준으로 합니다(라우팅 그룹()이나 병렬 라우팅@ 등은 고려하지 않음). 현재 폴더 또는 상위 폴더 내에서 같은 이름의 폴더를 찾아 대체하는 방식으로 작동합니다.
Next.js에서 사용할 파일들은 public폴더에 넣어주고 시작하면 됩니다.
The Next.js Image component extends the HTML "img"element with features for automatic image optimization.
Size Optimization: Automatically serve correctly sized images for each device, using modern image formats like WebP and AVIF.
Visual Stability: Prevent layout shift automatically when images are loading.
Faster Page Loads: Images are only loaded when they enter the viewport using native browser lazy loading, with optional blur-up placeholders.
Asset Flexibility: On-demand image resizing, even for images stored on remote servers
Next.js의 Image 컴포넌트는 자동 이미지 최적화 기능을 포함하여 HTML img 요소를 확장합니다:
Next.js에서는 next/image 컴포넌트를 통해 웹상에서 사용되는 이미지들을 최적화하고 안정성을 제공합니다. 반면, 기본 HTML img 태그를 사용할 경우, Lighthouse 검사 결과에서 볼 수 있듯이 Largest Contentful Paint(LCP)에 부정적인 영향을 미치며, 이는 곧 웹사이트의 퍼포먼스 문제로 이어질 수 있습니다.
Next.js의 next/image 컴포넌트를 사용할 때 "serve images in next-gen formats" 경고가 나타나지 않는 이유는, 이 기능이 차세대 이미지 형식을 지원하기 때문입니다. 차세대 이미지 형식이란 JPEG나 PNG와 같은 전통적인 이미지 형식보다 압축 효율이 뛰어나고 품질을 더 잘 유지하면서 웹 페이지의 로딩 속도를 향상시키는 현대적인 이미지 형식을 의미합니다. next/image는 바로 이러한 최신 이미지 형식으로의 최적화를 자동으로 처리해주기 때문에 해당 경고가 발생하지 않는 것입니다.
import Link from "next/link";
const Links = () => {
const links = [];
return (
<div>
{links.map((link) => (
<Link key={link.title} href={link.path} prefetch={false}>
{link.title}
</Link>
))}
</div>
);
};
export default Links;
Next.js learn Linkpart, Next.js Doc
Next.js에서는 우리가 사용하던 react-router-dom에서의 Link비슷한 기능을 하는 next/link가 있습니다.
Save your changes and check to see if it works in your localhost. You should now be able to navigate between the pages without seeing a full refresh.
변경 사항을 저장하고 로컬호스트에서 작동하는지 확인하세요. 이제 전체 새로 고침 없이 페이지 간 이동이 가능할 것입니다. - Next.js learn
Next.js의 next/link를 활용하면 별도의 라이브러리 없이도 페이지 라우팅을 손쉽게 할 수 있습니다. 이는 페이지를 새로 고침하지 않고도 이동이 가능하게 하여 사용자 경험을 한층 더 향상시킵니다.
next/link는 다양한 옵션을 제공하는데, 그 중 prefetch옵션이 있습니다. prefetch는 데이터를 사전에 백그라운드에서 불러와 로딩할 수 있게 해줍니다. 따라서, 이를 true로 설정하면 정적 및 동적 경로에 대한 전체 경로를 사전에 가져와, 페이지에 방문할 때 보다 빠르게 접근할 수 있습니다.
또 다른 옵션으로는 replace가 있습니다. 이는 새로운 URL을 라우터 히스토리 스택에 추가하지 않고, 현재 페이지의 경로를 새로운 URL로 대체합니다.
예를 들어, 홈에서 로그인 페이지를 거쳐 아이템 페이지로 이동한 후, router.replace를 사용하여 '마이페이지'로 이동한다면, 라우터 히스토리 스택에서 현재 페이지인 아이템이 마이페이지로 대체됩니다. 결과적으로, 히스토리 스택은 홈 > 로그인 > 마이페이지로 기록됩니다. 이 경우 마지막 페이지에서 뒤로 가기를 누르면 로그인 페이지로 돌아갑니다.
이러한 기능들을 통해 Next.js는 사용자와 개발자 모두에게 효율적이고 쾌적한 웹 경험을 제공합니다.
'use client'
import { useRouter } from 'next/navigation'
export default function Page() {
const router = useRouter()
return (
<button type="button" onClick={() => router.push('/dashboard')}>
Dashboard
</button>
)
}
useRouter은 경로를 지정하고 이를 관리하는 데 유용한 기능을 제공합니다. 이 훅을 통해 다양한 탐색 및 라우팅 작업을 수행할 수 있습니다.
router.push(href: string): 제공된 경로로 클라이언트 측 탐색을 수행하며, 브라우저 기록에 새 항목을 추가합니다.
router.replace(href: string): 브라우저의 기록 스택에 새 항목을 추가하지 않고, 제공된 경로로 클라이언트 측 탐색을 수행합니다.
router.refresh(): 현재 경로를 새로 고쳐 서버에 새 요청을 보내고, 데이터를 다시 가져오며, 서버 구성 요소를 다시 렌더링합니다. 이 과정에서 클라이언트 측 React 상태(예: useState)나 브라우저 상태(예: 스크롤 위치)는 유지되며, 업데이트된 React 서버 구성 요소 페이로드만 병합됩니다.
router.prefetch(href: string): 제공된 경로를 미리 가져와 더 빠른 클라이언트 측 전환을 가능하게 합니다.
router.back(): 브라우저의 기록 스택에서 이전 경로로 이동합니다.
router.forward(): 브라우저 기록 스택의 다음 페이지로 이동합니다.
useRouter 훅을 통해 Next.js는 보다 유연하고 강력한 라우팅 기능을 제공하여, 개발자와 사용자가 모두 만족할 수 있는 웹 애플리케이션을 구축할 수 있습니다.
'use client'
import { useParams } from 'next/navigation'
export default function ExampleClientComponent() {
const params = useParams()
return <></>
}
useParams는 현재 경로의 동적 매개변수들을 포함하는 객체를 반환하는 훅입니다. 이를 통해, 경로에 포함된 변수 값을 쉽게 추출하고 활용할 수 있습니다. 예를 들어, /app/shop/[tag]/[item]이라는 경로가 있고 실제 URL이 /shop/1/2라고 가정할 때, useParams를 사용하면 { tag: '1', item: '2' }라는 객체를 얻을 수 있습니다. 이를 통해, 경로에서 설정한 id 값이나 [slug]와 같은 동적 매개변수들을 효율적으로 가져와 사용할 수 있습니다.
이런 방식으로 useParams를 활용하면, 웹 애플리케이션에서 동적 경로를 통해 다양한 데이터를 표현하고 관리하는 것이 한층 더 용이해집니다.
'use client'
import { usePathname } from 'next/navigation'
export default function ExampleClientComponent() {
const pathname = usePathname()
return <p>Current pathname: {pathname}</p>
}
usePathname은 현재 URL의 경로명만을 반환하는 훅입니다. 이는 useParams와 달리 동적 매개변수나 [slug] 값을 포함하지 않습니다. 예를 들어, 만약 현재 URL이 /dashboard?page=2라면, usePathname을 통해 얻을 수 있는 값은 /dashboard가 됩니다.
이 훅을 사용함으로써, 쿼리 파라미터나 해시 값 등의 추가적인 URL 구성 요소 없이, 순수하게 경로명만을 추출해낼 수 있습니다.
'use client'
import { useSearchParams } from 'next/navigation'
export default function SearchBar() {
const searchParams = useSearchParams()
const search = searchParams.get('search')
return <>Search: {search}</>
}
useSearchParams는 현재 URL의 쿼리 스트링("search" 부분)에서 원하는 값을 쉽게 추출할 수 있는 훅입니다. 예를 들어 URL이 "/dashboard?search=my-project"일 경우, 이 훅을 사용하여 'search'의 값을 "my-project"로 쉽게 얻을 수 있습니다. 이를 통해 웹 애플리케이션에서 사용자의 검색 요청과 같은 쿼리 스트링 기반의 데이터를 효율적으로 관리하고 활용할 수 있습니다.
const SinglePostPage = ({ params }) => {
console.log("params를 찾습니다.", params);
return <></>
}
[slug]를 포함하는 페이지에서도 현재 경로의 동적 매개변수를 파악할 수 있습니다. 예를 들어, URL 경로가 /articles/[slug]와 같이 설정되어 있고, 실제 방문한 페이지의 URL이 /articles/react-hooks-introduction이라면, { slug: 'react-hooks-introduction' }와 같이 현재 경로의 동적 매개변수 값을 얻을 수 있습니다. 이렇게 하면 페이지 내에서 동적으로 변하는 경로 값을 효과적으로 활용할 수 있습니다.