chacha_fe.log https://velog.io/ 나는야 프린이 Sat, 17 Jun 2023 13:16:54 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed chacha_fe.log https://velog.velcdn.com/images/chacha_fe/profile/4e177b9b-1734-4fbc-a830-f933bc111ff5/image.jpeg https://velog.io/ Copyright (C) 2019. chacha_fe.log. All rights reserved. <![CDATA[[ File Conventions ] Files]]> https://velog.io/@chacha_fe/File-Conventions-Files https://velog.io/@chacha_fe/File-Conventions-Files Sat, 17 Jun 2023 13:16:54 GMT error.js

error.js는 경로 세그먼트에 대한 오류 UI 경계를 정의한다.

// app/dashboard/error.tsx

'use client' // Error components must be Client Components

import { useEffect } from 'react'

export default function Error({
  error,
  reset,
}: {
  error: Error
  reset: () => void
}) {
  useEffect(() => {
    // Log the error to an error reporting service
    console.error(error)
  }, [error])

  return (
    <div>
      <h2>Something went wrong!</h2>
      <button
        onClick={
          // Attempt to recover by trying to re-render the segment
          () => reset()
        }
      >
        Try again
      </button>
    </div>
  )
}

Props

error

error 객체의 인스턴스다. 이 오류는 서버나 클라이언트에서 발생할 수 있다.

reset

응답을 반환하지 않는 error boundary를 재설정하는 함수다.

알아두면 좋은 사항

  • error.js boundary는 클라이언트 컴포넌트여야 한다.

  • error.js boundary는 같은 세그먼트의 layout.js 컴포넌트에서 발생한 오류를 처리하지 않는다. 이는 error boundary가 해당 레이아웃 컴포넌트 내에 중첩되어 있기 때문이다.

  • 특정 레이아웃의 오류를 처리하려면 error.js 파일을 레이아웃의 상위 세그먼트에 배치한다.

  • 루트 레이아웃이나 템플릿 내에서 오류를 처리하려면 error.js의 변형인 app/global-error.js를 사용한다.


global-error.js

root layout.js에서 발생하는 오류를 특별히 처리하려면, 루트 app 디렉토리에 위치한 error.js의 변형인 app/global-error.js를 사용한다.

// app/global-error.js

'use client'

export default function GlobalError({
  error,
  reset,
}: {
  error: Error
  reset: () => void
}) {
  return (
    <html>
      <body>
        <h2>Something went wrong!</h2>
        <button onClick={() => reset()}>Try again</button>
      </body>
    </html>
  )
}

알아두면 좋은 사항

  • global-error.js는 활성화되었을 때 루트 layout.js를 대체하므로 자체 <html> 및 <body> 태그를 정의해야 한다.
  • 오류 UI를 디자인하는 동안, React 개발자 도구를 사용하여 오류 경계(Error boundaries)를 수동으로 전환하는 것이 도움이 될 수 있다.

layout.js

레이아웃은 라우트 간에 공유되는 UI다.

// app/dashboard/layout.tsx

export default function DashboardLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return <section>{children}</section>
}

루트 레이아웃은 루트 앱 디렉토리에서 가장 상위에 위치한 레이아웃이다. <html> 및 <body> 태그 및 다른 전역적으로 공유되는 UI를 정의하는 데 사용된다.

// app/layout.tsx

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  )
}

Props

children ( 필수적 )

레이아웃 컴포넌트는 children prop을 받아서 사용해야 한다. 렌더링 중에 children은 레이아웃이 감싸고 있는 라우트 세그먼트로 채워진다. 주로 자식 레이아웃 (있는 경우) 또는 페이지의 컴포넌트일 것이다. 그러나 해당되는 경우 Loading이나 Error와 같은 다른 특수 파일일 수도 있다.

params ( 선택적 )

루트 세그먼트에서 해당 레이아웃까지의 동적 라우트 매개변수 객체다.

Example URL params
app/dashboard/[team]/layout.js /dashboard/1 { team: '1' }
app/shop/[tag]/[item]/layout.js /shop/1/2 { tag: '1', item: '2' }
app/blog/[...slug]/layout.js /blog/1/2 { slug: ['1', '2'] } 
// app/shop/[tag]/[item]/layout.tsx

export default function ShopLayout({
  children,
  params,
}: {
  children: React.ReactNode
  params: {
    tag: string
    item: string
  }
}) {
  // URL -> /shop/shoes/nike-air-max-97
  // `params` -> { tag: 'shoes', item: 'nike-air-max-97' }
  return <section>{children}</section>
}

알아두면 좋은 점

레이아웃은 searchParams prop을 받지 않는다.

page와 달리 layout 컴포넌트는 searchParams prop을 받지 않는다. 이는 공유된 레이아웃이 탐색 중에 다시 렌더링되지 않기 때문에 navigation 사이에 오래된 searchParams가 발생할 수 있기 때문이다.

클라이언트 측 navigation을 사용할 때, Next.js는 두 라우트 사이에서 공통 레이아웃 아래에 있는 페이지의 일부만 자동으로 렌더링한다.


다음 디렉토리 구조의 예를 들어보면, dashboard/layout.tsx는 /dashboard/settings 및 /dashboard/analytics의 공통 레이아웃이다.

app
└── dashboard
    ├── layout.tsx
    ├── settings
    │   └── page.tsx
    └── analytics
        └── page.js

/dashboard/settings에서 /dashboard/analytics로 이동할 때, /dashboard/analytics의 page.tsx가 서버에서 렌더링된다. 왜냐하면 이것은 변경된 UI이기 때문이다.

반면, dashboard/layout.tsx는 두 라우트 사이에서 공통으로 사용되기 때문에 다시 렌더링되지 않는다.

이 성능 최적화는 레이아웃을 공유하는 페이지 간의 navigation을 빠르게 만들어준다. 왜냐하면 해당 페이지의 데이터 가져오기와 렌더링만 실행하면 되기 때문에 공유 레이아웃이 자체 데이터를 가져오는 라우트 전체를 실행할 필요가 없기 때문이다.

dashboard/layout.tsx가 다시 렌더링되지 않기 때문에, 레이아웃 서버 컴포넌트의 searchParams prop은 navigation 후에 오래된(stale) 상태가 될 수 있다.

대신에, Page의 searchParams prop이나 Client 컴포넌트에서 useSearchParams 훅을 사용하여 클라이언트에서 최신 searchParams와 함께 다시 렌더링되도록 한다.


RootLayout

  • app 디렉토리에는 루트 app/layout.js가 포함되어야 한다.

  • 루트 레이아웃은 <html> 및 <body> 태그를 정의해야 한다.

  • 루트 레이아웃에는 수동으로 <title> 및 <meta>와 같은 <head> 태그를 추가해서는 안된다. 대신에 <head> 요소의 스트리밍과 중복 제거와 같은 고급 요구 사항을 자동으로 처리하는 Metadata API를 사용해야 한다.

  • route groups를 사용하여 여러 개의 루트 레이아웃을 생성할 수 있다.

  • 여러 개의 루트 레이아웃을 통해 navigation할 경우 전체 페이지 로드가 발생합니다(클라이언트 측 navigation이 아닌 경우). 예를 들어, app/(shop)/layout.js를 사용하는 /cart에서 app/(marketing)/layout.js를 사용하는 /blog로 이동할 경우 전체 페이지 로드가 발생합니다. 이는 여러 개의 루트 레이아웃에만 해당됩니다.


loading.js

loading.js는 Suspense를 기반으로 한 즉시 로딩 상태를 생성할 수 있다.

기본적으로 이 파일은 서버 컴포넌트다. 그러나 "use client" 지시문을 통해 클라이언트 컴포넌트로 사용할 수도 있다.

// app/feed/loading.js

export default function Loading() {
  // Or a custom loading skeleton component
  return <p>'Loading...'</p>
}

not-found.js

not-found.js은 라우트 세그먼트 내에서 notFound 함수가 throw될 때 UI를 렌더링하는 데 사용된다. 커스텀 UI를 제공하는 것 외에도, Next.js는 404 HTTP 상태 코드를 반환한다.

// app/blog/not-found.js

import Link from 'next/link'

export default function NotFound() {
  return (
    <div>
      <h2>Not Found</h2>
      <p>Could not find requested resource</p>
      <p>
        View <Link href="/blog">all posts</Link>
      </p>
    </div>
  )
}

알아두어야 할 점

notFound() 오류를 예상하여 catch하는 것 외에도, 루트 app/not-found.js 파일은 전체 애플리케이션에서 일치하지 않는 URL을 처리한다. 이는 사용자가 앱에서 처리되지 않은 URL을 방문할 경우 app/not-found.js 파일에서 내보낸 UI가 표시됨을 의미한다.


page.js

page는 라우트에 고유한 UI다.

params(선택적)

루트 세그먼트부터 해당 페이지까지의 동적 라우트 매개변수를 담고 있는 객체다. 예를 들면 다음과 같다.

Example URL params
app/shop/[slug]/page.js /shop/1 { slug: '1' }
app/shop/[category]/[item]/page.js /shop/1/2 { category: '1', item: '2' }
app/shop/[...slug]/page.js /shop/1/2 { slug: ['1', '2'] }

searchParams(선택적)

현재 URL의 검색 매개변수를 포함하는 객체다. 예를 들면 다음과 같다.

URL searchParams
/shop?a=1 { a: '1' }
/shop?a=1&b=2 { a: '1', b: '2' }
/shop?a=1&a=2 { a: ['1', '2'] }

알아두어야 할 점

  • searchParams는 값을 미리 알 수 없는 동적 API다. 이를 사용하면 페이지가 요청 시 동적 렌더링으로 선택된다.

  • searchParams는 URLSearchParams 인스턴스가 아닌 일반 JavaScript 객체를 반환한다.


route.js

Route Handlers를 사용하면 Web 요청 및 응답 API를 사용하여 특정 라우트에 대한 사용자 정의 요청 핸들러를 만들 수 있다.

HTTP Methods

route.js을 사용하면 특정 라우트에 대한 사용자 정의 요청 핸들러를 생성할 수 있다. 다음 HTTP 메서드가 지원된다. GET, POST, PUT, PATCH, DELETE, HEAD 및 OPTIONS.

// route.js

export async function GET(request: Request) {}

export async function HEAD(request: Request) {}

export async function POST(request: Request) {}

export async function PUT(request: Request) {}

export async function DELETE(request: Request) {}

export async function PATCH(request: Request) {}

// If `OPTIONS` is not defined, Next.js will automatically implement `OPTIONS` and  set the appropriate Response `Allow` header depending on the other methods defined in the route handler.
export async function OPTIONS(request: Request) {}

Route Handlers는 app 디렉토리 내에서만 사용할 수 있다. API Routes (pages)와 Route Handlers (app)를 함께 사용할 필요는 없으며, Route Handlers는 모든 사용 사례를 처리할 수 있어야 한다.


Parameters

request (선택적)

request 객체는 NextRequest 객체로, Web 요청 API의 확장이다. NextRequest를 사용하면 수신된 요청에 대한 추가적인 제어를 할 수 있다. 이를 통해 cookies에 쉽게 액세스하고 확장된 파싱된 URL 객체인 nextUrl에 쉽게 접근할 수 있다.

context (선택적)

// app/dashboard/[team]/route.js

export async function GET(request, context: { params }) {
  const team = params.team // '1'
}

현재 context의 유일한 값은 params이며, 이는 현재 라우트의 동적 라우트 매개변수를 포함하는 객체다.

NextResponse

Route Handlers는 NextResponse 객체를 반환함으로써 Web 응답 API를 확장할 수 있다. 이를 통해 쿠키 설정, 헤더 설정, 리다이렉트 및 리라이트를 쉽게 처리할 수 있다.


Route Segment Config

Route Segment 옵션은 다음 변수들을 직접 내보내는 방식으로 Page, Layout 또는 Route Handler의 동작을 구성할 수 있도록 한다.

Option Type Default
https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#dynamic 'auto' 'force-dynamic'
https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#dynamicparams boolean true
https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#revalidate false 'force-cache'
https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#fetchcache 'auto' 'default-cache'
https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#runtime 'nodejs' 'edge'
https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#preferredregion 'auto' 'global' 
// layout.tsx / page.tsx / route.ts

export const dynamic = 'auto'
export const dynamicParams = true
export const revalidate = false
export const fetchCache = 'auto'
export const runtime = 'nodejs'
export const preferredRegion = 'auto'

export default function MyComponent() {}

현재 구성 옵션의 값은 정적으로 분석 가능해야 한다. 예를 들어, revalidate = 600은 유효하지만 revalidate = 60 * 10은 유효하지 않다.


Options

dynamic

레이아웃이나 페이지의 동적 동작을 완전히 정적으로 또는 완전히 동적으로 변경한다.

// layout.tsx / page.tsx / route.ts

export const dynamic = 'auto'
// 'auto' | 'force-dynamic' | 'error' | 'force-static'

app 디렉토리의 새로운 모델은 page 디렉토리의 getServerSideProps와 getStaticProps의 바이너리 all-of-nothing 모델보다는 fetch 요청 수준의 세분화된 캐싱 제어를 선호한다. dynamic 옵션은 이전 모델로의 편리한 복귀 방법이며 간단한 마이그레이션 경로를 제공한다.

  • *auto (기본값) * 동적 동작으로 전환하지 않는 한 모든 컴포넌트가 동적 동작에 참여하지 않도록 최대한 캐싱한다.

  • force-dynamic 모든 fetch 요청의 캐싱을 비활성화하고 항상 재검증하여 레이아웃이나 페이지의 동적 렌더링과 동적 데이터 가져오기를 강제한다. 이 옵션은 다음과 동일하다.

    • pages 디렉토리의 getServerSideProps()
    • 레이아웃이나 페이지의 모든 fetch() 요청의 옵션을 { cache: 'no-store', next: { revalidate: 0 } }로 설정하기.
    • 세그먼트 구성을 export const fetchCache = 'force-no-store'로 설정하기.

  • error 동적 함수나 동적 fetch 사용 시 오류가 발생하여 레이아웃이나 페이지의 정적 렌더링과 정적 데이터 가져오기를 강제한다. 이 옵션은 다음과 동일하다.

    • pages 디렉토리의 getStaticProps()
    • 레이아웃이나 페이지의 모든 fetch() 요청의 옵션을 { cache: 'force-cache' }로 설정하기.
    • 세그먼트 구성을 fetchCache = 'only-cache', dynamicParams = false로 설정하기.
    • dynamic = 'error'는 dynamicParams의 기본값을 true에서 false로 변경한다. generateStaticParams에 의해 생성되지 않은 동적 매개변수를 가진 동적으로 렌더링되는 페이지로 다시 돌아가려면 dynamicParams = true를 수동으로 설정해야 한다.

  • force-static cookies(), headers(), useSearchParams()를 비워진 값으로 반환하여 레이아웃이나 페이지의 정적 렌더링과 정적 데이터 가져오기를 강제한다.


dynamicParams

generateStaticParams로 생성되지 않은 동적 세그먼트가 방문될 때 어떤 동작이 수행되는지를 제어한다.

// layout.tsx / page.tsx

export const dynamicParams = true // true | false,

  • true (기본값) generateStaticParams`에 포함되지 않은 동적 세그먼트는 필요할 때 생성된다.

  • false generateStaticParams에 포함되지 않은 동적 세그먼트는 404를 반환한다.

  • 이 옵션은 페이지 디렉토리의 getStaticPaths의 fallback: true | false | blocking 옵션을 대체한다.

  • dynamicParams = true인 경우 세그먼트는 스트리밍 서버 렌더링을 사용한다.

  • dynamic = 'error'와 dynamic = 'force-static'을 사용하면 dynamicParams의 기본값이 false로 변경된다.

revalidate

레이아웃이나 페이지의 기본 재유효화 시간을 설정한다. 이 옵션은 개별 fetch 요청에서 설정한 revalidate 값에 대체되지 않는다.

// layout.tsx / page.tsx / route.ts

export const revalidate = false
// false | 'force-cache' | 0 | number

  • false (기본값) 'force-cache'로 캐시 옵션을 설정하거나 동적 함수가 사용되기 전에 발견된 모든 fetch 요청을 캐시하는 기본 heuristic. 사실상 revalidate: Infinity와 동일하며, 리소스를 무기한으로 캐시해야 함을 의미한다. 개별 fetch 요청에서 cache: 'no-store' 또는 revalidate: 0을 사용하여 캐시를 피하고 라우트를 동적으로 렌더링하는 것도 가능하다. 또는 revalidate을 라우트의 기본값보다 작은 양의 양수로 설정하여 라우트의 재유효화 빈도를 증가시킬 수 있다.

  • 0 동적 함수나 동적 데이터 가져오기가 발견되지 않아도 레이아웃이나 페이지가 항상 동적으로 렌더링되도록 보장한다. 이 옵션은 캐시 옵션을 설정하지 않은 fetch 요청의 기본값을 'no-store'로 변경하지만, 'force-cache'로 옵트인하거나 양수 revalidate를 사용하는 fetch 요청은 변경하지 않는다.

  • number (초 단위) 레이아웃이나 페이지의 기본 재유효화 빈도를 n초로 설정한다.


revalidate 빈도

  • 단일 라우트의 각 레이아웃과 페이지에서 가장 낮은 revalidate 값이 전체 라우트의 재유효화 빈도를 결정한다. 이를 통해 하위 페이지도 상위 레이아웃과 동일한 빈도로 재유효화된다.
  • 개별 fetch 요청은 라우트의 기본 revalidate보다 낮은 revalidate를 설정하여 전체 라우트의 재유효화 빈도를 증가시킬 수 있다. 이를 통해 특정 기준에 따라 특정 라우트에 대해 동적으로 더 빈번한 재유효화를 선택적으로 사용할 수 있다.

runtime

// layout.tsx / page.tsx / route.ts

export const runtime = 'nodejs'
// 'edge' | 'nodejs'

preferredRegion

// layout.tsx / page.tsx / route.ts

export const preferredRegion = 'auto'
// 'auto' | 'global' | 'home' | ['iad1', 'sfo1']

preferredRegion 및 지원되는 지역에 대한 지원은 배포 플랫폼에 따라 다르다.

preferredRegion이 지정되지 않은 경우, 가장 가까운 상위 레이아웃의 옵션을 상속한다. 루트 레이아웃은 모든 지역을 기본값으로 갖는다.


generateStaticParams

generateStaticParams 함수는 동적 라우트 세그먼트와 함께 사용하여, 요청 시간이 아닌 빌드 시간에 정적으로 생성될 경로 세그먼트 매개변수 목록을 정의하는 데 사용될 수 있다.

Metadata Files API Reference

파일 기반의 메타데이터는 라우트 세그먼트에 특수한 메타데이터 파일을 추가하여 정의할 수 있다.

각 파일 규칙은 정적 파일(예: opengraph-image.jpg) 또는 코드를 사용하여 파일을 생성하는 동적 변형(예: opengraph-image.js)을 사용하여 정의할 수 있다.

파일이 정의되면 Next.js는 자동으로 파일을 제공하며 (생산 환경에서는 캐싱을 위해 해시가 포함됨) 관련된 헤드 요소를 올바른 메타데이터로 업데이트한다. 이는 자산의 URL, 파일 유형 및 이미지 크기와 같은 정보를 포함한다.

File Conventions: Metadata Files

[출처] https://nextjs.org/docs/app/api-reference/file-conventions

]]> <![CDATA[[ Components ] <Script/>]]> https://velog.io/@chacha_fe/Components-Script https://velog.io/@chacha_fe/Components-Script Thu, 15 Jun 2023 12:45:41 GMT // app/dashboard/page.tsx import Script from 'next/script' export default function Dashboard() { return ( <> <Script src="https://example.com/script.js" /> </> ) }

Props

아래는 <Script>에서 사용 가능한 요소들이다.

Prop Example Type Required
https://nextjs.org/docs/app/api-reference/components/script#src src="http://example.com/script" String Required unless inline script is used
https://nextjs.org/docs/app/api-reference/components/script#strategy strategy="lazyOnload" String -
https://nextjs.org/docs/app/api-reference/components/script#onload onLoad={onLoadFunc} Function -
https://nextjs.org/docs/app/api-reference/components/script#onready onReady={onReadyFunc} Function -
https://nextjs.org/docs/app/api-reference/components/script#onerror onError={onErrorFunc} Function -

필수적인 Props

<Script /> 컴포넌트는 다음과 같은 속성이 필요하다.

src

외부 스크립트의 URL을 지정하는 경로 문자열이다. 이는 절대 외부 URL이나 내부 경로일 수 있다. src 속성은 인라인 스크립트를 사용하지 않는 한 필수다.


선택적인 Props

아래는 <Script /> 의 선택적인 요소들이다.

strategy

스크립트의 로딩 전략이다. 사용할 수 있는 네 가지 다른 전략이 있다.

  • beforeInteractive : Next.js 코드 및 페이지 하이드레이션 이전에 로드된다.
  • afterInteractive : (default) 일부 하이드레이션 이후에 로드된다.
  • lazyOnload : 브라우저가 비활성 상태일 때 로드된다.
  • worker : (실험적인) 웹 워커에서 로드된다.

beforInteractive

beforeInteractive 전략으로 로드되는 스크립트는 초기에 서버로부터 HTML에 삽입되며, Next.js 모듈 이전에 다운로드되고 페이지 하이드레이션 이전에 순서대로 실행된다.

이 전략으로 표시된 스크립트는 처음부터 사전로드되고 가져와진다. 그러나 실행은 페이지 하이드레이션을 차단하지 않는다.

beforeInteractive 스크립트는 루트 레이아웃(app/layout.tsx) 내에 배치되어야 하며, 전체 사이트에서 필요한 스크립트를 로드하는 데 사용된다 (즉, 응용 프로그램의 어떤 페이지가 서버 측에서 로드되었을 때 스크립트가 로드된다).

이 전략은 페이지의 어떤 부분이 상호 작용 가능해지기 전에 가져와야 하는 중요한 스크립트에만 사용해야 한다.

beforeInteractive로 설정된 스크립트는 컴포넌트 내에서 어디에 배치되었는지와 상관없이 항상 HTML 문서의 헤드(head)에 삽입된다.

// app/layout.tsx

import Script from 'next/script'

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body>{children}</body>
      <Script
        src="https://example.com/script.js"
        strategy="beforeInteractive"
      />
    </html>
  )
}

beforeInteractive를 사용하여 가능한 빨리 로드되어야 하는 몇 가지 스크립트의 예시는 다음과 같다.

  • 봇 감지기 (Bot detectors)
  • 쿠키 동의 관리자 (Cookie consent managers)

afterInteractive

afterInteractive 전략을 사용하는 스크립트는 HTML에 클라이언트 측에서 삽입되며, 페이지의 일부 (또는 전체) 하이드레이션 이후에 로드된다. 이것은 Script 컴포넌트의 기본 전략이며, 가능한 빨리 로드되어야 하지만 first-party Next.js 코드 이전에는 로드되지 않아야 하는 스크립트에 사용해야 한다.

afterInteractive 스크립트는 어떤 페이지나 레이아웃에도 배치할 수 있으며, 해당 페이지 (또는 페이지 그룹)가 브라우저에서 열릴 때만 로드되고 실행된다.

// app/page.js

import Script from 'next/script'

export default function Page() {
  return (
    <>
      <Script src="https://example.com/script.js" strategy="afterInteractive" />
    </>
  )
}

afterInteractive에 적합한 스크립트의 몇 가지 예시는 다음과 같다.

  • 태그 관리자 (Tag managers)
  • 분석 도구 (Analytics)

lazyOnload

lazyOnload 전략을 사용하는 스크립트는 브라우저가 비활성 상태일 때 HTML에 클라이언트 측에서 삽입되며, 페이지의 모든 리소스가 가져온 후에 로드된다. 이 전략은 조금 뒤에 로드되어도 되는 백그라운드 또는 우선순위가 낮은 스크립트에 사용해야 한다.

lazyOnload 스크립트는 어떤 페이지나 레이아웃에도 배치할 수 있으며, 해당 페이지 (또는 페이지 그룹)가 브라우저에서 열릴 때만 로드되고 실행된다.

import Script from 'next/script'

export default function Page() {
  return (
    <>
      <Script src="https://example.com/script.js" strategy="lazyOnload" />
    </>
  )
}

즉시 로드할 필요가 없고 lazyOnload로 가져올 수 있는 스크립트의 예시로는 다음이 있습니다:

  • 채팅 지원 플러그인 (Chat support plugins)
  • 소셜 미디어 위젯 (Social media widgets)

worker

worker 전략은 아직 안정화되지 않았으며, app 디렉토리에서는 아직 작동하지 않는다.

worker 전략을 사용하는 스크립트는 주 스레드에서 벗어나 웹 워커로 전달되어 주 스레드를 해제하고 중요한 first-party 리소스만 처리되도록 한다. 이 전략은 모든 스크립트에 사용할 수 있지만, 모든 타사 스크립트를 지원하는 것이 보장되지 않는 고급 사용 사례다.

전략으로 worker를 사용하려면 next.config.js에서 nextScriptWorkers 플래그를 활성화해야 한다.

// next.config.js

module.exports = {
  experimental: {
    nextScriptWorkers: true,
  },
}

현재 worker 스크립트는 pages/ 디렉토리에서만 사용할 수 있다.

// pages/home.tsx

import Script from 'next/script'

export default function Home() {
  return (
    <>
      <Script src="https://example.com/script.js" strategy="worker" />
    </>
  )
}

onLoad

onLoad는 아직 서버 컴포넌트에서 작동하지 않으며 클라이언트 컴포넌트에서만 사용할 수 있다. 또한, onLoad는 beforeInteractive와 함께 사용할 수 없다. 대신 onReady를 사용하는 것을 고려하라.

일부 타사 스크립트는 스크립트가 로드된 후에 콘텐츠를 인스턴스화하거나 함수를 호출하기 위해 사용자가 JavaScript 코드를 한 번 실행해야 하는 경우가 있다. 로딩 전략으로 afterInteractive 또는 lazyOnload를 사용하여 스크립트를 로드하는 경우, onLoad 속성을 사용하여 로드된 후에 코드를 실행할 수 있다.


다음은 lodash 라이브러리가 로드된 후에만 lodash 메서드를 실행하는 예시다.

// app/page.tsx

'use client'

import { useRef } from 'react'
import Script from 'next/script'

export default function Page() {
  const mapRef = useRef()

  return (
    <>
      <div ref={mapRef}></div>
      <Script
        id="google-maps"
        src="https://maps.googleapis.com/maps/api/js"
        onReady={() => {
          new google.maps.Map(mapRef.current, {
            center: { lat: -34.397, lng: 150.644 },
            zoom: 8,
          })
        }}
      />
    </>
  )
}

onReady

onReady는 아직 Server Components에서 작동하지 않으며, Client Components에서만 사용할 수 있다.

일부 타사 스크립트는 스크립트가 로드되고 컴포넌트가 재마운트될 때마다 (예: 라우트 이동 후) 사용자가 JavaScript 코드를 실행해야 하는 경우가 있다. onReady 속성을 사용하여 스크립트가 처음 로드될 때와 이후의 모든 컴포넌트 재마운트 후에 코드를 실행할 수 있다.


다음은 컴포넌트가 재마운트될 때마다 Google Maps JS embed를 다시 인스턴스화하는 예시다.

// app/page.tsx

'use client'

import { useRef } from 'react'
import Script from 'next/script'

export default function Page() {
  const mapRef = useRef()

  return (
    <>
      <div ref={mapRef}></div>
      <Script
        id="google-maps"
        src="https://maps.googleapis.com/maps/api/js"
        onReady={() => {
          new google.maps.Map(mapRef.current, {
            center: { lat: -34.397, lng: 150.644 },
            zoom: 8,
          })
        }}
      />
    </>
  )
}

onError

onError는 아직 Server Components에서 작동하지 않으며, Client Components에서만 사용할 수 있다. onError는 beforeInteractive 로딩 전략과 함께 사용할 수 없다.

때로는 스크립트 로드에 실패했을 때 이를 감지하는 것이 유용할 수 있다. onError 속성을 사용하여 이러한 오류를 처리할 수 있다.

// app/page.tsx

'use client'

import Script from 'next/script'

export default function Page() {
  return (
    <>
      <Script
        src="https://example.com/script.js"
        onError={(e: Error) => {
          console.error('Script failed to load', e)
        }}
      />
    </>
  )
}

[출처] https://nextjs.org/docs/app/api-reference/components/script

]]> <![CDATA[[ Compontents ] <Link/>]]> https://velog.io/@chacha_fe/Compontents-Link https://velog.io/@chacha_fe/Compontents-Link Thu, 15 Jun 2023 12:42:26 GMT <Link>는 React 컴포넌트로, HTML <a> 요소를 확장하여 prefetching(사전로드) 및 클라이언트 측에서 라우트 간 탐색을 제공한다. 이는 Next.js에서 라우트 간 탐색을 위한 주요 방법이다.

Next.js 애플리케이션에서 <Link>를 사용하면 클라이언트 측 렌더링 및 탐색을 자동으로 처리한다. 즉, 사용자가 <Link> 컴포넌트를 클릭하면 브라우저 전체 새로고침 없이 페이지 전환이 발생한다. 이로 인해 더 빠르고 원활한 사용자 경험이 가능해진다.


다음은 Next.js에서 <Link> 컴포넌트를 사용하는 예시다.

import Link from 'next/link'

export default function Page() {
  return <Link href="/dashboard">Dashboard</Link>
}

Props

<Link/>의 구성 요소는 아래와 같다.

Prop Example Type Required
https://nextjs.org/docs/app/api-reference/components/link#href-required href="/dashboard" String or Object Yes
https://nextjs.org/docs/app/api-reference/components/link#replace replace={false} Boolean -
https://nextjs.org/docs/app/api-reference/components/link#prefetch prefetch={false} Boolean -

<Link>에는 className이나 target="_blank"와 같은 <a> 태그 속성을 props로 추가할 수 있으며, 이러한 속성은 내부의 <a> 요소로 전달된다.

href

이동할 경로 또는 URL이며 필수적인 요소다.

<Link href="/dashboard">Dashboard</Link>

href 는 object를 허용한다. 

// Navigate to /about?name=test
<Link
  href={{
    pathname: '/about',
    query: { name: 'test' },
  }}
>
  About
</Link>

replace

기본값은 false다. true로 설정할 경우, next/link는 브라우저의 기록 스택에 새 URL을 추가하는 대신 현재의 기록 상태를 대체한다.

import Link from 'next/link'

export default function Page() {
  return (
    <Link href="/dashboard" replace>
      Dashboard
    </Link>
  )
}

prefetch

기본값은 true다. true로 설정할 경우, next/link는 백그라운드에서 페이지(prefetch={false})를 사전로드한다. 이는 클라이언트 측 탐색의 성능을 향상시키는 데 유용하다. 뷰포트에 있는 <Link />(초기에나 스크롤을 통해)는 사전로드된다.

prefetch={false}를 전달하여 사전로드 기능을 비활성화할 수 있다. 사전로드 기능은 프로덕션 환경에서만 활성화된다.


예시

동적 라우트 연결

동적 라우트의 경우, 링크의 경로를 생성하기 위해 템플릿 리터럴을 사용하는 것이 편리할 수 있다.


예를 들어, 동적 라우트 `app/blog/[slug]/page.js`에 대한 링크 목록을 생성할 수 있다. 
// app/blog/page.js

import Link from 'next/link'

function Page({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>
          <Link href={`/blog/${post.slug}`}>{post.title}</Link>
        </li>
      ))}
    </ul>
  )
}

Middleware

인증 또는 사용자를 다른 페이지로 리다이렉션하는 등 다른 목적을 위해 미들웨어를 사용하는 것이 일반적이다. 미들웨어를 와 함께 <Link/> 컴포넌트로 제대로 된 사전로드와 리다이렉트를 하기 위해서는 Next.js에게 표시할 URL과 사전로드할 URL을 모두 알려주어야 한다. 이렇게 하면 미들웨어에 필요한 올바른 경로를 사전로드하기 위해 불필요한 fetch를 방지할 수 있다.

예를 들어, 인증 및 방문자 뷰를 가진 /dashboard 경로를 제공하려는 경우, 다음과 같이 미들웨어에 다음과 유사한 내용을 추가하여 사용자를 올바른 페이지로 리디렉션할 수 있다.

// middleware.js

export function middleware(req) {
  const nextUrl = req.nextUrl
  if (nextUrl.pathname === '/dashboard') {
    if (req.cookies.authToken) {
      return NextResponse.rewrite(new URL('/auth/dashboard', req.url))
    } else {
      return NextResponse.rewrite(new URL('/public/dashboard', req.url))
    }
  }
}

이 경우, 컴포넌트에서 다음 코드를 사용하면 된다.

import Link from 'next/link'
import useIsAuthed from './hooks/useIsAuthed'

export default function Page() {
  const isAuthed = useIsAuthed()
  const path = isAuthed ? '/auth/dashboard' : '/dashboard'
  return (
    <Link as="/dashboard" href={path}>
      Dashboard
    </Link>
  )
}

[출처] https://nextjs.org/docs/app/api-reference/components

]]> <![CDATA[함수와 일급 객체]]> https://velog.io/@chacha_fe/%ED%95%A8%EC%88%98%EC%99%80-%EC%9D%BC%EA%B8%89-%EA%B0%9D%EC%B2%B4 https://velog.io/@chacha_fe/%ED%95%A8%EC%88%98%EC%99%80-%EC%9D%BC%EA%B8%89-%EA%B0%9D%EC%B2%B4 Tue, 30 May 2023 14:40:24 GMT 일급 객체

다음과 같은 조건을 만족하는 객체를 일급 객체라 한다.

  1. 무명의 리터럴로 생성할 수 있다. 즉, 런타임에 생성이 가능하다.

  2. 변수나 자료구조(객체, 배열)에 저장할 수 있다.

  3. 함수의 매개변수에 전달할 수 있다.

  4. 함수의 반환값으로 사용할 수 있다.


자바스크립트의 함수는 일급 객체다.

// 1. 함수는 무명의 리터럴로 생성할 수 있다.
// 2. 함수는 변수에 저장할 수 있다.
// 런타임에 함수 리터럴이 평가되어 함수 객체가 생성되고 변수에 할당된다.
const increase = function(num){
    return ++num;
}

const perdicates = { increase };

// 3. 함수의 매개변수에 전달할 수 있다.
// 4. 함수의 반환값으로 사용할 수 있다.
function makeCounter(predicate){
    let num = 0;

    return function () {
        num = predicate(num);
        return num;
    };
}

const increaser = makeCounter(predicates.increase);
console.log(increaser()); // 1
console.log(increase()); // 2

함수가 일급 객체라는 것은 함수를 객체와 동일하게 사용할 수 있다는 의미다. 객체는 값이므로 함수는 값과 동일하게 취급할 수 있다.

일급 객체로서 함수가 가지는 가장 큰 특징은 일반 객체와 같이 함수의 매개변수에 전달할 수 있으며, 함수의 반환값으로 사용할 수도 있다는 것이다.


함수 객체의 프로퍼티

함수 객체는 arguments, caller, length, name, prototype이라는 일반 객체에 없는 고유의 프로퍼티를 가진다.


1. arguments 프로퍼티

함수 객체의 arguments 프로퍼티 값은 arguments 객체다. arguments 객체는 함수 호출시 전달된 인수들의 정보를 담고 있는 순회 가능한 유사 배열 객체이며, 함수 내부에서 지역 변수처럼 사용된다.

function multiply(x,y){
    console.log(arguments);
    return x * y;
}

multiply(1,2);

  • arguments의 프로퍼티 키는 인수의 순서, 프로퍼티 값은 인수의 값을 나타낸다.

  • arguments의 callee 프로퍼티는 호출한 함수를 가리킨다.

  • arguments의 length 프로퍼티는 인수의 개수를 나타낸다.


매개변수의 개수보다 인수를 더 많이 전달한 경우 초과된 인수는 무시된다. 그렇다고 초과된 인수가 그냥 버려지는 것은 아니다. 모든 인수는 암묵적으로 arguments 객체의 프로퍼티로 보관된다.


arguments 객체는 매개변수 개수를 확정할 수 없는 가변 인자 함수를 구현할 때 유용하다.

arguments 객체는 유사 배열 객체다. 유사 배열 객체란 length 프로퍼티를 가진 객체로 for 문으로 순회할 수 있는 객체를 말한다.

function sum(){
    let res = 0;

    // arguments 객체는 length 프로퍼티가 있는 유사 배열 객체이므로 for 문으로 순회할 수 있다.
    for(let i = 0; i < arguments.length; i++){
        res += arguments[i];
    }
    return res;
}

console.log(sum()); // 0
console.log(sum(1,2)); // 3
console.log(sum(1,2,3)); // 6

2. caller 프로퍼티

caller 프로퍼티는 ECMAScript 사양에 포함되지 않은 비표준 프로퍼티다.

함수 객체의 caller 프로퍼티는 함수 자신을 호출한 함수를 가리킨다.

function foo(func){
    return func();
}

function bar(){
    return 'caller' + bar.caller;
}

// 브라우저 실행 결과
console.log(foo(bar)); // caller: function foo(func){...}
console.log(bar()); // caller: null

3. length 프로퍼티

함수 객체의 length 프로퍼티는 함수를 정의할 때 선언한 매개변수의 개수를 가리킨다.

function foo(){}
console.log(foo.length); // 0

function bar(a,b,c){}
console.log(bar.length); // 3

arguments 객체의 length 프로펕티는 인자의 개수를 가리킨다. 하지만 함수 객체의 length 프로퍼티는 매개변수의 개수를 가리킨다.


4. name 프로퍼티

함수 객체의 name 프로퍼티는 함수 이름을 나타낸다. name 프로퍼티는 ES6 이전까지는 비표준이었다가 ES6에서 정식 표준이 되었다.

ES5와 ES6에서 동작의 차이가 있다.

// 기명 함수 표현식
var namedFunc = function foo(){};
console.log(namedFunc.name); // foo

// 익명 함수 표현식
var anonymousFunc = function (){};
// ES5 : name 프로퍼티는 빈 문자열을 값으로 갖는다.
// ES6 : name 프로퍼티는 함수 객체를 가리키는 변수 이름을 값으로 갖는다.
console.log(anonymousFunc.name); // anonymousFunc

5. proto 접근자 프로퍼티

모든 객체는 [[Prototype]] 이라는 내부 슬롯을 갖는다. [[Prototype]] 내부 슬롯은 객체지향 프로그래밍의 상속을 구현하는 프로토타입 객체를 가리킨다.

__proto__ 프로퍼티는 [[Prototype]] 내부 슬롯이 가리키는 프로토타입 객체에 간접적으로 접근하기 위해 사용하는 접근자 프로퍼티다. 

const obj = { a: 1 };

// 객체 리터럴 방식으로 생성한 객체의 프로토타입 객체는 Object.prototypedlek.
console.log(obj.__proto__ === Object.prototype); // true

// 객체 리터럴 방식으로 생성한 객체는 프로토타입 객체인 Object.prototype의 프로퍼티를 상속받는다.
// hasOwnProperty 메서드는 Object.prototype의 메서드다.
console.log(obj.hasOwnProperty('a')); // true
console.log(obj.hasOwnProperty('__proto__')); // false

💡 hasOwnProperty 메소드

hasOwnProperty 메서드는 이름에서 알 수 있듯이 인수로 전달받은 프로퍼티 키가 객체 고유의 프로퍼티 키인 경우에만 true를 반환하고 상속받은 프로토타입의 프로퍼티 키인 경우 false를 반환한다.


6. prototype 프로퍼티

prototype 프로퍼티는 생성자 함수로 호출할 수 있는 함수 객체, 즉 constructor만이 소유하는 프로퍼티다.

일반 객체와 생성자 함수로 호출할 수 없는 non-constructor에는 prototype 프로퍼티가 없다.

// 함수 객체는 prototype 프로퍼티를 소유한다.
(function () {}).hasOwnProperty('prototype'); // true

// 일반 객체는 prototype 프로퍼티를 소유하지 않는다.
({}).hasOwnProperty('prototype'); // false

prototype 프로퍼티는 함수가 객체를 생성하는 생성자 함수로 호출될 때 생성자 함수가 생성할 인스턴스의 프로토타입 객체를 가리킨다.

]]> <![CDATA[생성자 함수에 의한 객체 생성]]> https://velog.io/@chacha_fe/%EC%83%9D%EC%84%B1%EC%9E%90-%ED%95%A8%EC%88%98%EC%97%90-%EC%9D%98%ED%95%9C-%EA%B0%9D%EC%B2%B4-%EC%83%9D%EC%84%B1 https://velog.io/@chacha_fe/%EC%83%9D%EC%84%B1%EC%9E%90-%ED%95%A8%EC%88%98%EC%97%90-%EC%9D%98%ED%95%9C-%EA%B0%9D%EC%B2%B4-%EC%83%9D%EC%84%B1 Tue, 30 May 2023 11:59:38 GMT 객체 리터럴에 의한 객체 생성 방식은 가장 일반적이고 간단한 객체 생성 방식이다. 객체는 객체 리터럴 이외에도 다양한 방법으로 생성할 수 있다.

객체 리터럴을 사용하여 객체를 생성하는 방식과 생성자 함수를 사용하여 객체를 생성하는 방식과의 장단점을 알아보자.


Object 생성자 함수

new 연산자와 함께 Object 생성자 함수를 호출하면 빈 객체를 생성하여 반환한다. 빈 객체를 생성한 이후 프로퍼티 또는 메서드를 추가하여 객체를 완성시킬 수 있다.

// 빈 객체의 생성
const person = new Object();

person.name = 'Han';

console.log(person); // { name: "Han" }

생성자 함수란 new 연산자와 함께 호출하여 객체(인스턴스)를 생성하는 함수를 말한다. 생성자 함수에 의해 생성된 객체를 인스턴스라 한다.

자바스크립트는 이외에도 String, Number, Boolean, Function, Array, Date, RegExp, Promise 등의 빌트인 생성자 함수를 제공한다.


생성자 함수

1. 객체 리터럴에 의한 객체 생성 방식의 문제점

객체 리터럴에 의한 객체 생성 방식은 직관적이고 간편하다. 하지만 객체 리터럴에 의한 객체 생성 방식은 단 하나의 객체만 생성한다. 따라서 동일한 프로퍼티를 갖는 객체를 여러 개 생성해야 하는 경우 매번 같은 프로퍼티를 기술해야 하기 때문에 비효율적이다.

const circle1 = {
    raduis: 5,
    getDiameter(){
        return 2 * this.radius    
    }
}

const circle2 = {
    raduis: 10,
    getDiameter(){
        return 2 * this.radius    
    }
}

2. 생성자 함수에 의한 객체 생성 방식의 장점

생성자 함수에 의한 객체 생성 방식은 마치 객체(인스턴스)를 생성하기 위한 템플릿(클래스)처럼 생성자 함수를 사용하여 프로퍼티 구조가 동일한 객체 여러 개를 간편하게 생성할 수 있다.

// 생성자 함수
function Circle(radius){
    // 생성자 함수 내부의 this는 생성자 함수가 생성할 인스턴스를 가리킨다.
    this.radius = radius;
    this.getDiameter = function () {
        return 2 * this.radius;
    }
}

// 인스턴스 생성
const circle1 = Circle(5);
const circle2 = Circle(10);

만약 new 연산자와 함께 생성자 함수를 호출하지 않으면 생성자 함수가 아닌 일반 함수로 동작한다.

const circle3 = Circle(15);

// 일반 함수로서 호출된 Circle은 반환문이 없으므로 암묵적으로 undefined를 반환한다.
console.log(circle3);

// 일반 함수로서 호출된 Circle 내의 this는 전역 객체를 가리킨다.
console.log(radius); // 15

3. 생성자 함수의 인스턴스 생성 과정

생성자 함수의 역할은 프로퍼티 구조가 동일한 인스턴스를 생성하기 위한 템플릿(클래스)으로서 동작하여 인스턴스를 생성하는 것과 생성된 인스턴스를 초기화(인스턴스 프로퍼티 추가 및 초기값 할당)하는 것이다.

생성자 함수가 인스턴스를 생성하는 것은 필수적이고, 생성된 인스턴스를 초기화하는 것은 옵션이다.

// 생성자 함수
function Circle(radius){
    // 인스턴스 초기화
    this.radius = radius;
    this.getDiameter = function () {
        return 2 * this.radius;
    }
}

// 인스턴스 생성
const circle1 = new Circle(5);

생성자 함수 내부 코드를 살펴보면 this에 프로퍼티를 추가하고 전달된 인수를 프로퍼티 초기 값으로 할당하여 인스턴스를 처기화 한다. 하지만 인스턴스를 생성하고 반환하는 코드는 보이지 않는다. (예 : return { … } )


자바스크립트 엔진은 암묵적으로 인스턴스를 생성하고 인스턴스를 초기화한 후 암묵적으로 인스턴스를 반환한다.


1) 인스턴스 생성과 this 바인딩

암묵적으로 빈 객체(인스턴스)가 생성되고 this에 바인딩된다. 이 처리는 런타임 이전에 실행된다.

function Circle(radius){
    // 암묵적으로 인스턴스가 생성되고 this에 바인딩된다.
    console.log(this);

    this.radius = radius;
    this.getDiameter = function () {
        return 2 * this.radius;
    }
}

2) 인스턴스 초기화

생성자 함수에 기술되어 있는 코드가 실행되어 this에 바인딩 되어 있는 인스턴스를 초기화한다.

function Circle(radius){
    // 1. 암묵적으로 인스턴스가 생성되고 this에 바인딩된다.
    console.log(this);

    // 2. this에 바인딩되어 있는 인스턴스를 초기화한다.
    this.radius = radius;
    this.getDiameter = function () {
        return 2 * this.radius;
    }
}

3) 인스턴스 반환

생성자 함수 내부의 모든 처리가 끝나면 완성된 인스턴스가 바인딩된 this를 암묵적으로 반환한다.

function Circle(radius){
    // 1. 암묵적으로 인스턴스가 생성되고 this에 바인딩된다.

    // 2. this에 바인딩되어 있는 인스턴스를 초기화한다.
    this.radius = radius;
    this.getDiameter = function () {
        return 2 * this.radius;
    }

    // 3. 완성된 인스턴스가 바인딩된 this를 암묵적으로 반환한다.
}

만약 this가 아닌 다른 객체를 명시적으로 반환하면 this가 반환되지 못하고 return 문에 명시한 객체가 반환된다.

function Circle(radius){
    this.radius = radius;
    this.getDiameter = function () {
        return 2 * this.radius;
    }

    // 명시적으로 객체를 반환하면 암묵적인 this 반환이 무시된다.
    return {};
}

const circle = new Circle(1);
console.log(circle); // {};

하지만 명시적으로 원시 값을 반환하면 원시 값 반환은 무시되고 암묵적으로 this가 반환된다.

function Circle(radius){
    this.radius = radius;
    this.getDiameter = function () {
        return 2 * this.radius;
    }

    // 명시적으로 원시 값 반환 시에 암묵적으로 this가 반환된다.
    return 100;
}

const circle = new Circle(1);
console.log(circle); // Circle {radius:1, getDiameter:f}

생성자 함수 내부에서 명시적으로 this가 아닌 다른 값을 반환하는 것은 생성자 함수의 기본 동작을 훼손한다. 따라서 생성자 함수 내부에서 return 문을 반드시 생략한다.

]]> <![CDATA[프로퍼티 어트리뷰트]]> https://velog.io/@chacha_fe/%ED%94%84%EB%A1%9C%ED%8D%BC%ED%8B%B0-%EC%96%B4%ED%8A%B8%EB%A6%AC%EB%B7%B0%ED%8A%B8 https://velog.io/@chacha_fe/%ED%94%84%EB%A1%9C%ED%8D%BC%ED%8B%B0-%EC%96%B4%ED%8A%B8%EB%A6%AC%EB%B7%B0%ED%8A%B8 Sun, 28 May 2023 14:40:12 GMT 내부 슬롯과 내부 메서드

내부 슬롯과 내부 메서드는 자바스크립트 엔진의 구현 알고리즘을 설명하기 위해 ECMAScript 사양에서 사용하는 의사 프로퍼티와 의사 메서드다. ([[ … ]]) 이중 대괄호로 감싼 이름들이 내부 슬롯과 내부 메서드다.

내부 슬롯과 내부 메서드는 자바스크립트 엔진의 내부 로직이므로 원칙적으로 자바스크립트는 내부 슬롯과 내부 메서드에 직접적으로 접근하거나 호출할 수 있는 방법을 제공하지 않는다. 단, 일부 내부 슬롯과 내부 메서드에 한하여 직접적으로 접근할 수 있는 수단을 제공하기는 한다.

const o = {};

o.[[Prototype]] // Uncaught SyntaxError

o.__proto__ // Object.prototype

프로퍼티 어트리뷰트와 프로퍼티 디스크립터 객체

자바스크립트 엔진은 프로퍼티를 생성할 때 프로퍼티의 상태를 나타내는 프로퍼티 어트리뷰터를 기본값으로 자동 정의한다.

프로퍼티 어트리뷰트는 자바스크립트의 엔진이 관리하는 내부 상태 값인 아래의 내부 슬롯이다.

  • [[Value]]

  • [[Writable]]

  • [[Enumerable]]

  • [[Configurable]]

따라서 프로퍼티 어트리뷰트에 직접 접근할 수 없지만 Object.getOwnPropertyDescriptor 메서드를 사용하여 간접적으로 확인할 수는 있다.


Object.getOwnPropertyDescriptor 메서드를 호출할 때 첫 번째 매개변수에는 객체의 참조를 전달하고, 두 번째 매개변수에는 프로퍼티 키를 문자열로 전달한다.

이 때 Object.getOwnPropertyDescriptor 메서드는 프로퍼티 어트리뷰트 정보를 제공하는 프로퍼티 디스크립터 객체를 반환한다.

const person = { name:'Lee' };

person.age = 20;

console.log(Object.getOwnPropertyDescriptor(person, 'name'));
// { value:'Lee', writable: true, enumerable: true, configurable: true }

// Object.getOwnPropertyDescriptors 메서드를 사용하면 모든 프로퍼티의 프로퍼티 어트리뷰트
// 정보를 제공하는 프로퍼티 디스크립터 객체들을 반환한다.
console.log(Object.getOwnPropertyDescriptor(person);
/*
    {
        name: { value:'Lee', writable: true, enumerable: true, configurable: true },
        age: { value:20, writable: true, enumerable: true, configurable: true } 
    }
*/

데이터 프로퍼티와 접근자 프로퍼티

프로퍼티는 데이터 프로퍼티와 접근자 프로퍼티로 구분할 수 있다.


1. 데이터 프로퍼티

키와 값으로 구성된 일반적인 프로퍼티다.

데이터 프로퍼티는 다음과 같은 프로퍼티 어트리뷰트를 갖는다. 이 프로퍼티 어트리뷰트는 자바스크립트 인젠이 프로퍼티를 생성할 때 기본값으로 자동 정의된다.

  1. [[Value]]

  • 프로퍼티 디스크립터 객체의 프로퍼티는 value다.

  • 프로퍼티 키를 통해 프로퍼티 값에 접근하면 반환되는 값이다.

  • 프로퍼티 키를 통해 값을 변경하면 [[Value]]에 값을 재할당한다. 이때 프로퍼티가 없으면 프로퍼티를 동적 생성하고 생성된 프로퍼티의 [[Value]] 에 값을 저장한다.


  1. [[Writable]]

  • 프로퍼티 디스크립터 객체의 프로퍼티는 writable다.

  • 프로퍼티 값의 변경 가능 여부를 나타내며 불리언 값을 갖는다.

  • [[Writable]] 의 값이 false인 경우 값을 변경할 수 없는 읽기 전용 프로퍼티가 된다.


  1. [[Enumerable]]

  • 프로퍼티 디스크립터 객체의 프로퍼티는 enumerable다.

  • 프로퍼티의 열거 가능 여부를 나타내며 불리언 값을 갖는다.

  • 값이 false인 경우 for…in문이나 Object.keys 메서드 등으로 열거할 수 없다.


  1. [[Configurable]]

  • 프로퍼티 디스크립터 객체의 프로퍼티는 configurable다.

  • 프로퍼티 재정의 가능 여부를 나타내며 불리언 값을 갖는다.

  • 값이 false인 경우 해당 프로퍼티 삭제, 값의 변경이 금지된다. 단, true인 경우 값의 변경과 writable을 false로 변경하는 것은 허용된다.


2. 접근자 프로퍼티

자체적으로 값을 갖지 않고 다른 데이터 프로퍼티의 값을 읽거나 저장할 때 호출되는 접근자 함수로 구성된 프로퍼티다. 아래와 같은 프로퍼티 어트리뷰를 갖는다.

  1. [[Get]]

  • 프로퍼티 디스크립터 객체의 프로퍼티는 get다.

  • 접근자 프로퍼티를 통해 데이터 프로퍼티의 값을 읽을 때 호출되는 접근자 함수다. 즉, 접근자 프로퍼티 키로 프로퍼티 값에 접근하면 프로퍼티 어트리뷰트 [[Get]] 의 값, 즉 getter 함수가 호출되고 그 결과가 프로퍼티 값으로 반환된다.


  1. [[Set]]
  • 프로퍼티 디스크립터 객체의 프로퍼티는 set다.
  • 접근자 프로퍼티를 통해 데이터 프로퍼티의 값을 저장할 때 호출되는 접근자 함수다. 접근자 프로퍼티 키로 프로퍼티 값을 저장하면 setter 함수가 호출되고 그 결과가 프로퍼티 값으로 저장된다.

  1. [[Enumerable]]
  • 데이터 프로퍼티와 동일하다.

  1. [[Configurable]]
  • 데이터 프로퍼티와 동일하다.

접근자 함수는 getter/setter 함수라고도 부른다.

const person = {
    // 데이터 프로퍼티
    firstName: 'minsu',
    lastName: 'kim',

    // fullName은 접근자 함수로 구성된 접근자 프로퍼티다.
    // getter 함수
    get fullName(){
        return `${this.firstName} ${this.lastName}`
    }

    // setter 함수
    set fullName(name){
    [this.firstName, this.lastName] = name.split(" ");
    }
}

console.log(person.fullName); // minsu kim

person.fullName = 'sejun han';
console.log(person); // { firstName: 'sejun', lastName: 'han' }

접근자 프로퍼티는 자체적으로 값을 가지지 않으며 다만 데이터 프로퍼티의 값을 읽거나 저장할 때 관여할 뿐이다.


프로퍼티 정의

프로퍼티 정의란 새로운 프로퍼티를 추가하면서 프로퍼티 어트리뷰트를 명시적으로 정의하거나, 기존 프로퍼티의 프로퍼티 어트리뷰트를 재정의하는 것을 말한다.


Object.defineProperty메서드를 사용하면 프로퍼티의 어트리뷰트를 정의할 수 있다.

const person = {}'

Object.defineProperty(person,'firstName',{
    value:'sejun',
    writable:true,
    enumable:true.
    configurable
})

객체 변경 방지

자바스크립트는 객체의 변경을 방지하는 다양한 메서드를 제공하낟. 객체 변경 방지 메서드들은 객체의 변경을 금지하는 강도가 다르다.


1. 객체 확장 금지

Object.preventExtensions 메서드는 객체의 확장을 금지한다. 즉, 금지된 객체는 프로퍼티 추가가 금지된다.

const person = {
    name:'sejun'
}

// 확장 금지
Object.preventExtensions(person); 

person.age = 20;

console.log(person); // { name: 'sejun' }

객체 밀봉

Object.seal 메서드는 객체를 밀봉한다. 밀봉된 객체는 읽기와 쓰기만 가능하다.

const person = {
    name:'sejun'
}

// 밀봉
Object.seal(person);

// 추가 및 삭제는 불가능하다.
person.age = 20;
delete person.name
console.log(person); // { name: 'sejun' }

// 수정은 가능하다.
person.name = 'ing';
console.log(person); // { name: 'ing' }

객체 동결

Object.freeze 메서드는 객체를 동결한다. 동결된 객체는 읽기만 가능하다.

const person = {
    name:'sejun'
}

// 동결
Object.freeze(person);

// 추가, 삭제, 수정 불가능하다.
person.age = 20;
delete person.name
person.name = 'ing';
console.log(person); // { name: 'sejun' }
]]> <![CDATA[[ Components ] <Image/>]]> https://velog.io/@chacha_fe/Components-Image-8ynwab5c https://velog.io/@chacha_fe/Components-Image-8ynwab5c Thu, 25 May 2023 16:24:00 GMT import Image from 'next/image'; export default function Page() { return ( <Image src="/profile.png" width={500} height={500} alt="Picture of the author" /> ); }

Props

아래는 <Image> 컴포넌트에서 사용 가능한 props다.

Prop Example Type Required
https://nextjs.org/docs/app/api-reference/components/image#src src="/profile.png" String Yes
https://nextjs.org/docs/app/api-reference/components/image#width width={500} Integer (px) Yes
https://nextjs.org/docs/app/api-reference/components/image#height height={500} Integer (px) Yes
https://nextjs.org/docs/app/api-reference/components/image#alt alt="Picture of the author" String Yes
https://nextjs.org/docs/app/api-reference/components/image#loader loader={imageLoader} Function -
https://nextjs.org/docs/app/api-reference/components/image#fill fill={true} Boolean -
https://nextjs.org/docs/app/api-reference/components/image#sizes sizes="(max-width: 768px) 100vw" String -
https://nextjs.org/docs/app/api-reference/components/image#quality quality={80} Integer (1-100) -
https://nextjs.org/docs/app/api-reference/components/image#priority priority={true} Boolean -
https://nextjs.org/docs/app/api-reference/components/image#placeholder placeholder="blur" String -
https://nextjs.org/docs/app/api-reference/components/image#style style={{objectFit: "contain"}} Object -
https://nextjs.org/docs/app/api-reference/components/image#onloadingcomplete onLoadingComplete={img => done())} Function -
https://nextjs.org/docs/app/api-reference/components/image#onload onLoad={event => done())} Function -
https://nextjs.org/docs/app/api-reference/components/image#onerror onError(event => fail()} Function -
https://nextjs.org/docs/app/api-reference/components/image#loading loading="lazy" String -
https://nextjs.org/docs/app/api-reference/components/image#blurdataurl blurDataURL="data:image/jpeg..." String -

필수적인 Props

이미지 컴포넌트에는 src, width, height, alt 속성이 필요하다.

import Image from 'next/image';

export default function Page() {
  return (
    <div>
      <Image
        src="/profile.png"
        width={500}
        height={500}
        alt="Picture of the author"
      />
    </div>
  );
}

src

src 속성에는 정적으로 가져온 이미지 파일 또는 경로 문자열을 사용해야한다. loader 속성에 따라 절대적인 외부 URL 또는 내부 경로가 될 수 있다. 외부 URL을 사용하는 경우 next.config.js의 remotePatterns에 추가해야 한다.


width

width 속성은 픽셀로 표시된 렌더링된 너비를 나타내므로 이미지의 크기에 영향을 준다.

정적으로 가져온 이미지이거나 fill 속성이 있는 이미지를 제외하고는 필수다.


height

height 속성은 픽셀로 표시된 렌더링된 높이를 나타내므로 이미지의 크기에 영향을 줍니다.

정적으로 가져온 이미지이거나 fill 속성이 있는 이미지를 제외하고는 필수다.


alt

alt 속성은 스크린 리더 및 검색 엔진을 위해 이미지를 설명하는 데 사용된다. 이미지가 비활성화되었거나 이미지 로드 중에 오류가 발생한 경우 대체 텍스트로 사용된다.

이미지의 의미를 변경하지 않고 이미지를 대체할 수 있는 텍스트를 포함해야 한다. 이미지를 보충하기 위한 것이 아니며 이미지 위 또는 아래의 캡션에서 이미 제공된 정보를 반복해서는 안된다.

이미지가 순전히 장식적인 목적으로 사용되거나 사용자를 위한 것이 아닌 경우, alt 속성은 빈 문자열 (alt="")이어야 한다.


선택적인 Props

<Image /> 컴포넌트는 필수 속성 이외에도 여러 가지 추가 속성을 받을 수 있다.


loader

이미지 URL을 해결하는 데 사용되는 사용자 정의 함수다.

loader는 다음 매개변수를 사용하여 이미지에 대한 URL 문자열을 반환하는 함수다.

  • src

  • width

  • quality


사용자 정의 로더를 사용하는 예시는 다음과 같다.

import Image from 'next/image';

const imageLoader = ({ src, width, quality }) => {
  return `https://example.com/${src}?w=${width}&q=${quality || 75}`;
};

export default function Page() {
  return (
    <Image
      loader={imageLoader}
      src="me.png"
      alt="Picture of the author"
      width={500}
      height={500}
    />
  );
}

또한 prop을 전달하지 않고 애플리케이션의 모든 next/image 인스턴스를 구성하기 위해 next.config.js의 loaderFile 구성을 사용할 수도 있다.


fill

부모 요소를 채우도록 이미지를 크기 조정하는 boolean 값이다. 이를 사용하면 width와 height를 설정하는 대신 이미지가 부모 요소를 채우게 된다.

fill={true} // {true} | {false}

부모 요소는 position: "relative", position: "fixed" 또는 position: "absolute" 스타일을 지정해야 한다.

기본적으로 img 요소는 자동으로 position: "absolute" 스타일이 지정된다.

기본 이미지 맞춤 동작은 이미지를 컨테이너에 맞게 늘리는 것이다. 컨테이너에 맞게 letterbox 처리된 이미지에는 object-fit: "contain"을 설정하는 것이 좋다. 이렇게 하면 이미지의 가로세로 비율을 유지한 채로 컨테이너에 맞게 표시된다.

또는 object-fit: "cover"를 사용하면 이미지가 전체 컨테이너를 채우고 가로세로 비율을 유지하기 위해 잘린다. 이를 올바르게 보이려면 overflow: "hidden" 스타일을 부모 요소에 지정해야 한다.


sizes

이미지의 다양한 브레이크포인트에서 이미지의 너비에 대한 정보를 제공하는 문자열이다. sizes의 값은 fill을 사용하는 이미지나 반응형 크기를 가진 이미지의 성능에 큰 영향을 미친다.


sizes 속성은 이미지 성능과 관련하여 두 가지 중요한 목적을 제공한다.

  1. sizes의 값은 브라우저가 next/image의 자동 생성 소스 세트에서 어떤 크기의 이미지를 다운로드할지 결정하는 데 사용된다. 브라우저가 선택할 때, 페이지에서 이미지의 크기를 아직 알지 못하므로, 뷰포트와 동일한 크기 또는 더 큰 크기의 이미지를 선택한다. sizes 속성을 사용하여 실제로 이미지가 전체 화면보다 작을 것임을 브라우저에 알릴 수 있다. fill 속성이 있는 이미지에서 sizes 값이 지정되지 않은 경우, 기본값으로 100vw(전체 화면 너비)가 사용된다.

  2. sizes 속성은 next/image가 자동으로 이미지 소스 세트를 생성하는 방식을 구성한다. sizes 값이 없는 경우, 고정 크기 이미지에 적합한 작은 소스 세트가 생성된다. sizes가 정의된 경우, 반응형 이미지에 적합한 큰 소스 세트가 생성된다. sizes 속성에 50vw와 같이 뷰포트 너비의 백분율을 나타내는 크기가 포함된 경우, 소스 세트는 필요하지 않은 값은 포함하지 않도록 자르게 된다.


예를 들어, 스타일링이 모바일 장치에서는 전체 너비로, 태블릿에서는 2열 레이아웃으로, 데스크탑 디스플레이에서는 3열 레이아웃으로 이미지를 표시하는 것을 알고 있다면, 다음과 같은 sizes 속성을 포함해야 한다.

import Image from 'next/image';

export default function Page() {
  return (
    <div className="grid-element">
      <Image
        fill
        src="/example.png"
        sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
      />
    </div>
  );
}

이 예제의 sizes는 성능 지표에 큰 영향을 줄 수 있다. 33vw sizes가 없는 경우, 서버에서 선택한 이미지는 실제로 필요한 크기의 3배다. 파일 크기는 너비의 제곱에 비례하므로, sizes가 없으면 사용자는 필요한 크기보다 9배 큰 이미지를 다운로드하게 된다.


priority

값이 true인 경우, 이미지는 우선 순위가 높은 이미지로 간주되어 preload된다. preiority가 있는 이미지를 사용하는 경우, 레이지 로딩은 자동으로 비활성된다.

priority={false} // {false} | {true}

Largest Contentful Paint (LCP) 요소로 감지된 이미지에는 priority 속성을 사용해야 한다. 서로 다른 이미지가 다른 뷰포트 크기에 대한 LCP 요소일 수 있으므로 여러 우선 순위 이미지를 가질 수도 있다.

이 속성은 페이지 로딩 시 화면 상단에 표시되는 이미지에만 사용해야 한다. 기본값은 false다.


placeholder

이미지가 로드되는 동안 사용할 placeholder다. 가능한 값은 blur 또는 empty다. 기본값은 empty다.

placeholder = 'empty'; // {empty} | {blur}

blur로 설정할 경우, plaehodler로 blurDataURL 속성이 사용된다. src가 정적 import에서 가져온 객체이고 가져온 이미지가 .jpg, .png, .webp, .avif인 경우, blurDataURL은 자동으로 채워진다.

동적 이미지의 경우, blurDataURL 속성을 제공해야 한다. Plaiceholder와 같은 솔루션은 base64 생성에 도움이 될 수 있다.

empty로 설정할 경우, 이미지가 로드되는 동안 placeholder가 없으며, 빈 공간만 표시된다.


고급 props


style

기본 이미지 요소에 CSS style을 전달할 수 있다.

const imageStyle = {
  borderRadius: '50%',
  border: '1px solid #fff',
};

export default function ProfileImage() {
  return <Image src="..." style={imageStyle} />;
}

필요한 width와 height 속성은 스타일링과 상호작용할 수 있다는 점을 기억해야 한다. 이미지의 너비를 수정하기 위해 스타일링을 사용하는 경우, 이미지의 가로세로 비율을 유지하기 위해 height를 auto로 스타일링해야 한다. 그렇지 않으면 이미지가 왜곡될 수 있다.


onLoadingComplete

이미지가 완전히 로드되고 placeholder가 제거된 후 호출되는 콜백 함수다.

콜백 함수는 <img> 요소에 대한 참조를 포함한 하나의 인수와 함께 호출된다.

<Image onLoadingComplete={(img) => console.log(img.naturalWidth)} />

onLoad

이미지가 로드될 때 호출되는 콜백 함수다.

<Image onLoad={(e) => console.log(e.target.naturalWidth)} />

참고로, load 이벤트는 플레이스홀더가 제거되고 이미지가 완전히 디코딩되기 전에 발생할 수 있다.

대신에 onLoadingComplete를 사용한다.


onError

이미지 로드 시에 호출되는 콜백 함수다.

<Image onError={(e) => console.error(e.target.id)} />

loading

이미지 로딩 동작이다. 기본값은 lazy다.

lazy로 설정할 경우, 이미지가 뷰포트로부터 계산된 거리에 도달할 때까지 이미지 로딩을 지연시킨다.

eager로 설정할 경우, 이미지를 즉시 로드한다.

loading = 'lazy'; // {lazy} | {eager}

이 속성은 고급 사용 사례에만 적합하다. eager로 이미지를 로드하는 것은 일반적으로 성능에 해를 입힐 수 있다. 대신에 이미지를 즉시 사전로드하는 priority 속성을 사용하는 것을 권장한다.


blurDataURL

성공적으로 로드되기 전에 src 이미지 대신 사용할 플레이스홀더 이미지로 사용될 데이터 URL다. placeholder="blur"와 함께 사용될 때에만 효과가 있다.

반드시 base64로 인코딩된 이미지여야 한다. 이미지는 확대되고 흐려지므로 매우 작은 이미지(10px 이하)를 권장한다. 더 큰 이미지를 플레이스홀더로 사용하면 애플리케이션의 성능에 문제가 발생할 수 있다.

다음을 시도해 보자:

  • 기본 blurDataURL 속성 데모

  • blurDataURL 속성을 사용한 shimmer 효과 데모

  • blurDataURL 속성을 사용한 색상 효과 데모


unoptimized

true로 설정할 경우, 원본 이미지가 품질, 크기 또는 형식을 변경하지 않고 그대로 제공된다. 기본값은 false다.

unoptimized = {false} // {false} | {true}
import Image from 'next/image';

const UnoptimizedImage = (props) => {
  return <Image {...props} unoptimized />;
};

Next.js 12.3.0부터는 다음 구성을 사용하여 next.config.js를 업데이트하여 모든 이미지에이 속성을 할당할 수 있다.

module.exports = {
  images: {
    unoptimized: true,
  },
};

다른 props

<Image /> 컴포넌트의 다른 속성은 다음을 제외하고 기본적으로 내부 img 요소로 전달된다.

  • srcSet. 대신 Device Sizes를 사용한다.

  • decoding은 항상 "async"다.


구성 옵션

props 외에도 next.config.js에서 Image 컴포넌트를 구성할 수 있다.


remotePatterns

악의적인 사용자로부터 애플리케이션을 보호하기 위해 외부 이미지 사용에 대한 구성이 필요하다. 이를 위해 Next.js 이미지 최적화 API에서 계정의 외부 이미지만 제공되도록 보장한다. 다음과 같이 next.config.js 파일의 remotePatterns 속성으로 외부 이미지를 구성할 수 있다.

// next.config.js

module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'example.com',
        port: '',
        pathname: '/account123/**',
      },
    ],
  },
};

위의 예제는 next/image의 src 속성이 https://example.com/account123/로 시작해야 함을 보장한다. 다른 프로토콜, 호스트명, 포트 또는 일치하지 않는 경로는 400 Bad Request로 응답한다.


다음은 next.config.js 파일의 remotePatterns 속성에 대한 또 다른 예제다.

module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: '**.example.com',
      },
    ],
  },
};

위의 예제에서는 https://img1.example.com 또는 https://me.avatar.example.com으로 시작하는 src 속성을 허용한다. 또한 임의의 수의 하위 도메인을 허용한다. 다른 프로토콜이나 일치하지 않는 호스트명은 400 Bad Request로 응답한다.


와일드카드 패턴은 경로명과 호스트명 모두에 사용할 수 있으며 다음 구문을 따른다.

  • *는 단일 경로 세그먼트 또는 서브도메인을 일치시킨다.

  • **는 끝에서 경로 세그먼트의 임의의 수 또는 시작에서 서브도메인의 임의의 수를 일치시킨다.

  • **구문은 패턴의 중간에서 작동하지 않는다.


domains

remotePatterns와 유사하게, domains 구성은 외부 이미지에 대한 허용된 호스트명 목록을 제공하는 데 사용될 수 있다.

하지만 domains 구성은 와일드카드 패턴 일치를 지원하지 않으며 프로토콜, 포트 또는 경로를 제한할 수 없다.

악의적인 사용자로부터 애플리케이션을 보호하기 위해 domains 대신 strict remotePatterns를 구성하는 것을 권장한다. domains는 도메인에서 제공되는 모든 콘텐츠를 소유한 경우에만 사용한다.


다음은 next.config.js 파일의 domains 속성 예제다.

module.exports = {
  images: {
    domains: ['assets.acme.com'],
  },
};

loaderFile

Next.js의 내장된 이미지 최적화 API 대신 클라우드 제공업체를 사용하여 이미지를 최적화하려는 경우, 다음과 같이 next.config.js에서 loaderFile을 구성할 수 있다.

module.exports = {
  images: {
    loader: 'custom',
    loaderFile: './my/image/loader.js',
  },
};

이는 Next.js 애플리케이션의 루트와 상대적인 파일을 가리켜야 한다. 파일은 문자열을 반환하는 기본 함수를 내보내야 한다. 아래 예제를 참고한다.

export default function myImageLoader({ src, width, quality }) {
  return `https://example.com/${src}?w=${width}&q=${quality || 75}`;
}

또는 next/image의 각 인스턴스를 구성하기 위해 loader prop을 사용할 수도 있다.


고급 설정

다음 구성은 고급 사용 사례를 위한 것으로 일반적으로 필요하지 않다. 아래의 속성을 구성하는 경우, 향후 업데이트에서 Next.js의 기본값을 재정의한다.


deviceSizes

사용자의 기대하는 장치 너비를 알고 있다면, next.config.js의 deviceSizes 속성을 사용하여 장치 너비에 대한 목록을 지정할 수 있다. 이러한 너비는 next/image 컴포넌트가 sizes prop을 사용할 때 사용되며, 사용자의 장치에 적합한 이미지가 제공된다.

구성을 제공하지 않으면 아래의 기본값을 사용한다.

module.exports = {
  images: {
    deviceSizes: [640, 750, 828, 1080, 1200, 1920, 2048, 3840],
  },
};

imageSizes

next.config.js 파일에서 images.imageSizes 속성을 사용하여 이미지 너비의 목록을 지정할 수 있다. 이러한 너비는 장치 너비 배열과 연결되어 이미지 srcset을 생성하는 데 사용된다.

두 개의 별도 목록을 사용하는 이유는 imageSizes가 sizes prop을 제공하는 이미지에만 사용되기 때문이다. sizes prop은 이미지가 화면의 전체 너비보다 작음을 나타낸다. 따라서 imageSizes의 크기는 deviceSizes의 가장 작은 크기보다 작아야 한다.

구성을 제공하지 않으면 아래의 기본값을 사용한다.

module.exports = {
  images: {
    imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
  },
};

formats

기본 이미지 최적화 API는 요청의 Accept 헤더를 통해 브라우저에서 지원하는 이미지 형식을 자동으로 감지한다.

Accept 헤더가 구성된 형식과 일치하는 경우, 배열에서 첫 번째 일치 항목이 사용된다. 따라서 배열의 순서가 중요하다. 일치하는 항목이 없는 경우 (또는 소스 이미지가 애니메이션인 경우), 이미지 최적화 API는 원본 이미지 형식으로 대체된다.

구성을 제공하지 않으면 아래의 기본값을 사용한다.

module.exports = {
  images: {
    formats: ['image/webp'],
  },
};

다음 구성으로 AVIF 지원을 활성화할 수 있다.

module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
  },
};

일반적으로 AVIF는 인코딩에 20% 더 오래 걸리지만 WebP에 비해 20% 더 작게 압축된다. 이는 이미지가 처음 요청될 때 일반적으로 느리게 작동하고, 그 후 캐시된 요청은 더 빠르게 작동할 것을 의미한다.

Next.js 앞에 Proxy/CDN을 사용하여 자체 호스팅하는 경우, Proxy가 Accept 헤더를 전달하도록 구성해야 한다.


캐싱 동작

이미지는 요청 시 동적으로 최적화되고 <distDir>/cache/images 디렉터리에 저장된다. 최적화된 이미지 파일은 만료될 때까지 후속 요청에 대해 제공된다. 캐시된 만료된 파일과 일치하는 요청이 들어오면, 만료된 이미지가 즉시 제공된다. 그런 다음 이미지는 다시 최적화되며, 백그라운드에서 캐시에 새로운 만료 날짜로 저장된다.(이를 재유효화라고도 함)


이미지의 캐시 상태는 x-nextjs-cache 응답 헤더의 값으로 확인할 수 있다. 가능한 값은 다음과 같다.

  • MISS : 경로가 캐시에 없음 (첫 번째 방문 시 최대 한 번 발생)

  • STALE : 경로가 캐시에 있지만 재유효화 시간을 초과하여 백그라운드에서 업데이트됨

  • HIT : 경로가 캐시에 있고 재유효화 시간을 초과하지 않음


만료 시간 (혹은 Max Age)은 minimumCacheTTL 구성 또는 상위 이미지의 Cache-Control 헤더 중 더 큰 값에 의해 정의된다. 구체적으로는 Cache-Control 헤더의 max-age 값을 사용한다. s-maxage와 max-age 둘 다 발견되면 s-maxage가 우선한다. max-age는 CDN과 브라우저를 포함한 하위 클라이언트로 전달된다.

  • upstream 이미지에 Cache-Control 헤더가 포함되지 않거나 값이 매우 낮은 경우 캐시 지속 시간을 늘리기 위해 minimumCacheTTL을 구성할 수 있다.

  • deviceSizes와 imageSizes를 구성하여 생성 가능한 이미지 수를 줄일 수 있다.

  • formats를 구성하여 여러 형식을 비활성화하고 단일 이미지 형식을 선호할 수 있다.


minimumCacheTTL

캐시된 최적화된 이미지의 TTL(Time to Live)을 초 단위로 구성할 수 있다. 많은 경우에는 파일 내용을 자동으로 해싱하고 불변의 Cache-Control 헤더로 이미지를 영구적으로 캐시하는 정적 이미지 가져오기를 사용하는 것이 좋다.

module.exports = {
  images: {
    minimumCacheTTL: 60,
  },
};

최적화된 이미지의 만료 시간 (또는 Max Age)은 minimumCacheTTL 또는 상위 이미지의 Cache-Control 헤더 중 더 큰 값에 의해 정의된다.

이미지별로 캐싱 동작을 변경해야 하는 경우, headers를 구성하여 상위 이미지에 Cache-Control 헤더를 설정할 수 있다. (예: /some-asset.jpg, /_next/image 자체가 아닌)

현재 캐시를 무효화하는 메커니즘이 없으므로, minimumCacheTTL을 낮게 유지하는 것이 좋다. 그렇지 않으면 src prop을 수동으로 변경하거나 <distDir>/cache/images를 삭제해야 할 수도 있다.


disableStaticImages

기본 동작은 import icon from './icon.png과 같은 정적 파일을 가져와 src 속성에 전달하는 것을 허용한다.

다른 플러그인과 충돌하는 경우에는 이 기능을 비활성화하고 다른 방식으로 가져오기를 기대하는 경우가 있을 수 있다.

next.config.js에서 정적 이미지 가져오기를 비활성화할 수 있다.

module.exports = {
  images: {
    disableStaticImages: true,
  },
};

dangerouslyAllowSVG

디폴트 loader는 몇 가지 이유로 SVG 이미지를 최적화하지 않는다. 첫째로, SVG는 벡터 형식이므로 손실 없이 크기를 조정할 수 있다. 둘째로, SVG는 HTML/CSS와 많은 기능을 공유하기 때문에 적절한 콘텐츠 보안 정책 (CSP) 헤더가 없으면 취약점이 발생할 수 있다.


기본 이미지 최적화 API를 사용하여 SVG 이미지를 제공해야 하는 경우, next.config.js에서 dangerouslyAllowSVG를 설정할 수 있다.

module.exports = {
  images: {
    dangerouslyAllowSVG: true,
    contentDispositionType: 'attachment',
    contentSecurityPolicy: "default-src 'self'; script-src 'none'; sandbox;",
  },
};

또한, 브라우저가 이미지를 다운로드하도록 contentDispositionType을 설정하는 것과 이미지에 포함된 스크립트가 실행되지 않도록 contentSecurityPolicy를 설정하는 것을 강력히 권장한다.


움직이는 이미지

디폴트 loader는 자동으로 애니메이션 이미지를 이미지 최적화 우회하고 원본 이미지 그대로 제공한다.

애니메이션 파일에 대한 자동 감지는 최선을 다하며 GIF, APNG, WebP를 지원한다. 특정 애니메이션 이미지에 대해 명시적으로 이미지 최적화를 우회하려면 unoptimized prop을 사용한다.


알려진 브라우저 버그

이 next/image 컴포넌트는 브라우저의 네이티브 지연 로딩을 사용하며, 이는 Safari 15.4 이전의 오래된 브라우저에서 즉시 로딩으로 대체될 수 있다. 희미한 placeholder를 사용하는 경우, Safari 12 이전의 오래된 브라우저는 빈 placeholder로 대체될 수 있다. weight/height가 자동(auto)인 스타일을 사용하는 경우, 종횡비를 유지하지 않는 Safari 15 이전의 오래된 브라우저에서 레이아웃 이동(Layout Shift)이 발생할 수 있다.


Safari 15 및 16은 로딩 중에 회색 테두리를 표시한다. Safari 16.4에서 이 문제가 수정되었다. 가능한 해결책은 다음과 같다.

  • CSS @supports (font: -apple-system-body) 및 (-webkit-appearance: none)을 사용하여 img[loading="lazy"] { clip-path: inset(0.6px) }를 지정한다.

  • 이미지가 화면에 표시되는 영역 위에 위치한다면 priority를 사용한다.


Firefox 67 이상에서는 로딩 중에 흰색 배경이 표시된다. 가능한 해결책은 다음과 같다.

  • AVIF format을 활성화한다.

  • placeholder="blur"을 사용한다.


[ 출처 ] https://nextjs.org/docs/app/api-reference/components/image#caching-behavior

]]> <![CDATA[let, const 키워드와 블록 레벨 스코프]]> https://velog.io/@chacha_fe/let-const-%ED%82%A4%EC%9B%8C%EB%93%9C%EC%99%80-%EB%B8%94%EB%A1%9D-%EB%A0%88%EB%B2%A8-%EC%8A%A4%EC%BD%94%ED%94%84 https://velog.io/@chacha_fe/let-const-%ED%82%A4%EC%9B%8C%EB%93%9C%EC%99%80-%EB%B8%94%EB%A1%9D-%EB%A0%88%EB%B2%A8-%EC%8A%A4%EC%BD%94%ED%94%84 Thu, 25 May 2023 13:27:10 GMT var 키워드로 선언한 변수의 문제점

1. 변수 중복 선언 허용

var 키워드로 선언한 변수는 중복 선언이 가능하다.

var x = 1;
var y = 1;

// var 키워드로 선언된 변수는 같은 스코프 내에서 중복 선언을 허용한다.
// 초기화문이 있는 변수 선언문은 자바스크립트 엔진에 의해 var 키워드가 없는 것처럼 동작한다.

var x = 100;

// 초기화 없는 변수 선언문은 무시된다.
var y;

console.log(x); // 100
console.log(y); // 1

var 키워드로 선언한 변수를 중복 선언하면 초기화문(변수 선언과 동시에 초기값을 할당하는 문) 유무에 따라 다르게 동작한다.

  • 초기화문이 있는 변수 선언문은 자바스크립트 엔진에 의해 var 키워드가 없는 것처럼 동작한다.
  • 초기화문이 없는 변수 선언문은 무시된다. 이때 에러는 발생하지 않는다.

2. 함수 레벨 스코프

var 키워드로 선언한 변수는 오로지 함수의 코드 블록만을 지역 스코프로 인정한다.

var x = 1;

if(true){
    // x는 전역 변수다. 이미 선언된 전역 변수 x가 있으므로 x 변수는 중복 선언된다.
    // 이는 의도치 않게 변수값이 변경되는 부작용을 발생시킨다.
    var x = 10;
}

console.log(x); // 10

3. 변수 호이스팅

변수 호이스팅에 의해 var 키워드로 선언한 변수는 변수 선언문 이전에 참조할 수 있다. 단, 할당문 이전에 변수를 참조하면 언제나 undefind를 반환한다.

// 이 시점에는 변수 호이스팅에 의해 이미 foo 변수가 선언되었다. (1. 선언 단계)
// 변수 foo는 undefined로 초기화된다. (2. 초기화 단계)
console.log(foo); // undefined

// 변수에 값을 할당(3. 할당 단계)
foo = 123;

console.log(foo); // 123

// 변수 선언은 런타임 이전에 자바스크립트 엔진에 의해 암묵적으로 실행된다.
var foo;

변수 선언문 이전에 변수를 참조하는 것은 변수 호이스팅에 의해 에러를 발생시키지는 않지만 프로그램의 흐름상 맞지 않을뿐더러 가독성을 떨어뜨리고 오류를 발생시킬 여지를 남긴다.


let 키워드

ES6에서는 새로운 변수 선언 키워드인 let과 const를 도입했다.

1. 변수 중복 선언 금지

var 키워드로 이름이 동일한 변수를 중복 선언하면 아무런 에러가 발생하지 않는다. 하지만 let 키워드로 이름이 같은 변수를 중복 선언하면 문법 에러가 발생한다.

var foo = 123;
// var 키워드로 선언된 변수는 같은 스코프 내에서 중복 선언을 허용한다.
// 아래 변수 선언문은 자바스크립트 엔진에 의해 var 키워드가 없는 것처럼 동작한다.
var foo = 456;

let bar = 123;
// let이나 const 키워드로 선언된 변수는 같은 스코프 내에서 중복 선언을 허용하지 않는다.
let bar = 456; // SyntaxError

2. 블록 레벨 스코프

let 키워드로 선언한 변수는 모든 코드 블록(함수 , if 문, for 문, while 문, try/catch 문 등)을 지역 스코프로 인정하는 블록 레벨 스코프를 따른다.

let foo = 1; // 전역 변수 

{
    let foo = 2; // 지역 변수
    let bar = 3; // 지역 변수
}

console.log(foo); // 1
console.log(bar); // ReferenceError

3. 변수 호이스팅

let 키워드로 선언한 변수는 변수 호이스팅이 발생하지 않는 것처럼 동작한다.

console.log(foo); // ReferenceError
let foo;

var 키워드와 달리 let 키워드로 선언한 변수는 선언 단계와 초기화 단계가 분리되어 진행된다.

즉, 런타임 이전에 자바스크립트 엔진에 의해 암묵적으로 선언 단계가 먼저 실행되지만 초기화 단계는 변수 선언문에 도달했을 때 실행된다.

만약 초기화 단계가 실행되기 전에 변수에 접근하려고 하면 참조 에러가 발생한다. let 키워드로 선언한 변수는 스코프의 시작 지점부터 초기화 단계 시작 지점(변수 선언문)까지 변수를 참조할 수 없다.


스코프의 시작 지점부터 초기화 시작 지점까지 변수를 참조할 수 없는 구간을 일시적 사각지대(TDZ)라고 한다.

let foo = 1; // 전역 변수

4. 전역 객체와 let

var 키워드로 선언한 전역 변수와 전역 함수, 그리고 선언하지 않은 변수에 값을 할당한 암묵적 전역은 전역 객체 window의 프로퍼티가 된다. 전역 객체의 프로퍼티를 참조할 때 window를 생략할 수 있다.

// 전역 변수
var x = 1;

// 암묵적 전역
y = 2;

// 전역 함수
function foo() {}

// var 키워드로 선언한 전역 변수는 전역 객체 window의 프로퍼티다.
console.log(window.x); // 1;

// 전역 객체 window의 프로퍼티는 전역 변수처럼 사용할 수 있다.
console.log(x); // 1

// 암묵적 전역은 전역 객체 window의 프로퍼티다.
console.log(window.y); // 2
console.log(y); // 2

// 함수 선언문으로 정의한 전역 함수는 전역 객체 window의 프로퍼티다.
console.log(window.foo); // f foo() {}

// 전역 객체 window의 프로퍼티는 전역 변수처럼 사용할 수 있다.
console.log(foo); // f foo() {}

let 키워드로 선언한 전역 변수는 전역 객체의 프로퍼티가 아니다. 즉, window.foo와 같이 접근할 수 없다.

let 전역 변수는 보이지 않는 개념적인 블록 내에 존재하게 된다.

let x = 1;

// let, const 키워드로 선언한 전역 변수는 전역 객체 window의 프로퍼티가 아니다.
console.log(window.x); // undefined;
console.log(x); // 1

const 키워드

const 키워드는 상수를 선언하기 위해 사용한다.

1. 선언과 초기화

const 키워드로 선언한 변수는 반드시 선언과 동시에 초기화해야 한다.

const foo = 1;

const bar; // SyntaxError

2. 재할당 금지

const 키워드로 선언한 변수는 재할당이 금지된다.

const foo = 1;
foo = 2; // TypeError: Assignment to constant variable.

3. 상수

const 키워드로 선언한 변수에 원시 값을 할당한 경우 변수 값을 변경할 수 없다. 원시 값은 변경 불가능한 값이므로 재할당 없이 값을 변경할 수 있는 방법이 없기 때문이다.

변수의 상대 개념인 상수는 재할당이 금지된 변수를 말한다.

const 키워드로 선언된 변수에 원시 값을 할당한 경우 원시 값은 변경할 수 없는 값이고 const 키워드에 의해 재할당이 금지되므로 할당된 값을 변경할 수 있는 방법은 없다.


4. const 키워드와 객체

const 키워드로 선언된 변수에 객체를 할당한 경우 값을 변경할 수 있다. 변경 불가능한 값인 원시 값은 재할당 없이 변경할 수 있는 방법이 없지만 변경 가능한 객체는 재할다 없이도 직접 변경이 가능하기 때문이다.

const person = {
    name: 'Lee'
};

// 객체는 변경 가능한 값이다. 따라서 재할당 없이 변경이 가능하다.
person.name = 'Kim';

console.log(person); // { name: 'Kim' }

const 키워드는 재할당을 금지할 뿐 불변을 의미하지는 않는다.

]]> <![CDATA[전역 변수의 문제점]]> https://velog.io/@chacha_fe/%EC%A0%84%EC%97%AD-%EB%B3%80%EC%88%98%EC%9D%98-%EB%AC%B8%EC%A0%9C%EC%A0%90 https://velog.io/@chacha_fe/%EC%A0%84%EC%97%AD-%EB%B3%80%EC%88%98%EC%9D%98-%EB%AC%B8%EC%A0%9C%EC%A0%90 Tue, 23 May 2023 13:38:58 GMT 변수의 생명 주기

1. 지역 변수의 생명 주기

변수는 자신이 선언된 위치에서 생성되고 소멸한다. 전역 변수의 생명 주기는 애플리케이션의 생명 주기와 같다. 하지만 지역변수의 생명주기는 함수의 생명 주기와 일치한다.

function foo(){
    var x = 'local'; // 변수 x 생성 -> 변수 x에 값 할당
    console.log(x); // local
    return x; // 변수 x 소멸 
}

foo();
console.log(x); // ReferenceError

함수 몸체 내부에서 선언된 지역 변수의 생명 주기는 함수의 생명 주기와 대부분 일치하지만 지역 변수가 함수보다 오래 생존하는 경우도 있다. (예: 클로저)


2. 전역 변수의 생명 주기

전역 변수의 생명 주기는 전역 객체의 생명주기와 일치한다.

var x = 'global'; // 전역 변수 x 생성 -> 전역 변수 x에 값 할당

function foo(){
    var x = 'local'; // 지역 변수 x 생성 -> 지역 변수 x에 값 할당
    console.log(x);
    return x;  // 지역변수 x 소멸
} 

foo();
console.log(x);

전역 변수의 문제점


암묵적 결합

전역 변수를 선언한 의도는 전역에서 참조하고 할당할 수 있는 변수를 사용하겠다는 것이다.

이는 모든 코드가 전역 변수를 참조하고 변경할 수 있는 암묵적 결합을 허용하는 것이다. 변수의 유효 범위가 크면 클수록 코드의 가독성은 나빠지고 의도치 않게 상태가 변경될 수 있는 위험성도 높아진다.


긴 생명 주기

전역 변수는 생명 주기가 길다. 따라서 메모리 리소스도 오랜 기간 소비한다.

또한 var 키워드는 변수의 중복 선언을 허용하므로 생명 주기가 긴 전역 변수는 변수 이름이 중복될 가능성이 있다. 변수 이름이 중복되면 재할당이 이뤄진다.


스코프 체인 상에서 종점에 존재

전역 변수는 스코프 체인 상에서 종점에 존재한다. 이는 변수를 검색할 때 전역 변수가 가장 마지막에 검색된 다는 것을 의미한다. 즉, 전역 변수의 검색 속도가 가장 느리다는 단점이 있다.


네임스페이스 오염

자바스크립트의 가장 큰 문제점 중 하나는 파일이 분리되어 있다 해도 하나의 전역 스코프를 공유한다는 것이다. 따라서 다른 파일 내에서 동일한 이름으로 명명된 전역 변수나 전역 함수가 같은 스코프 내에 존재할 경우 예상치 못한 결과를 가져올 수 있다.


전역 변수의 사용을 억제하는 방법

전역 변수는 반드시 사용해야할 이유가 있을 때 사용해야하며 변수의 스코프는 좁을수록 좋다.


즉시 실행 함수

즉시 실행 함수는 함수 정의와 동시에 호출되는 즉시 실행 함수는 단 한 번만 호출된다. 모든 코드를 즉시 실행 함수로 감싸면 모든 변수는 즉시 실행 함수의 지역 변수가 된다. 이러한 특성을 통해 전역 변수의 사용을 제한하는 방법이다.

(function(){
    var foo = 10; // 즉시 실행 함수의 지역 변수
})()

console.log(foo); // ReferenceError

네임스페이스 객체

전역에 네임스페이스 역할을 담당할 객체를 생성하고 전역 변수처럼 사용하고 싶은 변수를 프로퍼티 형태로 추가하는 방법이다.

var MYAPP = {}; // 전역 네임스페이스 객체

MYAPP.name = 'Lee';

console.log(MYAPP.name); // Lee

네임스페이스를 분리해서 식별자 충돌을 방지하는 효과는 있으나 네임스페이스 객체 자체가 전역 변수에 할당되므로 그다지 유용한 방법은 아니다.


모듈 패턴

모듈 패턴은 클래스를 모방해서 관련이 있는 변수와 함수를 모아 즉시 실행 함수로 감싸 하나의 모듈을 만든다. 모듈 패턴은 자바스크립트의 강력한 기능인 클로저를 기반으로 동작한다. 모듈 패턴의 특징은 전역 변수의 억제는 물론 캡슐화까지 구현할 수 있다는 것이다.

var Counter = (function(){
    // private 변수
    var num = 0;

    // 외부로 공개할 데이터나 메서드를 프로퍼티로 추가한 객체를 반환한다.
    return {
        increase(){ return ++num },
        decrease(){ return --num }
    }
}());

// private 변수는 외부로 노출되지 않는다.
console.log(Counter.num); // undefined

console.log(Counter.increase()); // 1
console.log(Counter.increase()); // 2

ES6 모듈

ES6 모듈을 사용하면 더는 전역 변수를 사용할 수 없다. ES6 모듈은 파일 자체의 독자적인 모듈 스코프를 제공한다. 모듈 내에서 var 키워드로 선언한 변수는 더는 전역 변수가 아니며 window 객체의 프로퍼티도 아니다.

script 태그에 type=’module’ 속성을 추가하면 로드된 자바스크립트 파일은 모듈로서 동작한다.

<script type='module' scr='lib.ms'></script>
<script type='module' scr='app.ms'></script>
]]> <![CDATA[[ Optimizing ] Lazy Loading]]> https://velog.io/@chacha_fe/Optimizing-Lazy-Loading https://velog.io/@chacha_fe/Optimizing-Lazy-Loading Tue, 23 May 2023 11:11:11 GMT Next.js의 레이지 로딩은 경로를 렌더링하는 데 필요한 JavaScript 양을 줄여 애플리케이션의 초기 로딩 성능을 향상시키는 데 도움이 된다.

레이지 로딩을 사용하면 클라이언트 컴포넌트와 가져온 라이브러리의 로딩을 지연시킬 수 있으며, 필요할 때만 클라이언트 번들에 포함시킬 수 있다. ( 예: 사용자가 모달을 열 때까지 모달의 로딩을 지연 )


Next.js에서 레이지 로딩을 구현하는 두 가지 방법이 있다.

  • next/dynamic을 사용한 동적 임포트
  • React.lazy()와 Suspense를 사용

기본적으로 서버 컴포넌트는 자동으로 코드를 분할하며, 스트리밍을 사용하여 서버에서 클라이언트로 UI 조각을 점진적으로 전송할 수 있다. 레이지 로딩은 클라이언트 컴포넌트에 적용된다.


next/dynamic

next/dynamic은 React.lazy()와 Suspense의 복합체다. app과 page 디렉토리에서 동일한 방식으로 동작하여 점진적인 마이그레이션을 가능하게 한다.


예시


클라이언트 컴포넌트에서 불러오기

// app/layout.js

'use client';

import { useState } from 'react';
import dynamic from 'next/dynamic';

// Client Components:
const ComponentA = dynamic(() => import('../components/A'));
const ComponentB = dynamic(() => import('../components/B'));
const ComponentC = dynamic(() => import('../components/C'), { ssr: false });

export default function ClientComponentExample() {
  const [showMore, setShowMore] = useState(false);

  return (
    <div>
      {/* Load immediately, but in a separate client bundle */}
      <ComponentA />

      {/* Load on demand, only when/if the condition is met */}
      {showMore && <ComponentB />}
      <button onClick={() => setShowMore(!showMore)}>Toggle</button>

      {/* Load only on the client side */}
      <ComponentC />
    </div>
  );
}

SSR 건너뛰기

React.lazy()와 Suspense를 사용할 때 기본적으로 클라이언트 컴포넌트는 사전 렌더링(SSR)된다.

특정 클라이언트 컴포넌트의 사전 렌더링을 비활성화하려면 ssr 옵션을 false로 설정할 수 있다.

const ComponentC = dynamic(() => import('../components/C'), { ssr: false });

서버 컴포넌트 가져오기

서버 컴포넌트를 동적으로 가져온 경우 서버 컴포넌트 자체가 아닌 서버 컴포넌트의 자식인 클라이언트 컴포넌트만 지연 로딩된다.

// app/page.js

import dynamic from 'next/dynamic';

// Server Component:
const ServerComponent = dynamic(() => import('../components/ServerComponent'));

export default function ServerComponentExample() {
  return (
    <div>
      <ServerComponent />
    </div>
  );
}

외부 라이브러리 로딩

import() 함수를 사용하여 필요한 시점에 외부 라이브러리를 로드할 수 있다. 이 예제에서는 퍼지 검색을 위해 외부 라이브러리인 fuse.js를 사용한다. 사용자가 검색 입력란에 입력을 시작한 후에만 해당 모듈이 클라이언트에서 로드된다.

'use client';

import { useState } from 'react';

const names = ['Tim', 'Joe', 'Bel', 'Lee'];

export default function Page() {
  const [results, setResults] = useState();

  return (
    <div>
      <input
        type="text"
        placeholder="Search"
        onChange={async (e) => {
          const { value } = e.currentTarget;
          // Dynamically load fuse.js
          const Fuse = (await import('fuse.js')).default;
          const fuse = new Fuse(names);

          setResults(fuse.search(value));
        }}
      />
      <pre>Results: {JSON.stringify(results, null, 2)}</pre>
    </div>
  );
}

커스텀 로딩 컴포넌트 추가

import dynamic from 'next/dynamic';

const WithCustomLoading = dynamic(
  () => import('../components/WithCustomLoading'),
  {
    loading: () => <p>Loading...</p>,
  },
);

export default function Page() {
  return (
    <div>
      {/* The loading component will be rendered while  <WithCustomLoading/> is loading */}
      <WithCustomLoading />
    </div>
  );
}

Importing Named Exports

이름 지정된 내보내기를 동적으로 가져오려면 import() 함수에서 반환된 Promise에서 해당 내보내기를 반환할 수 있다.

// components/hello.js

'use client';

export function Hello() {
  return <p>Hello!</p>;
}
// app/page.js

import dynamic from 'next/dynamic';

const ClientComponent = dynamic(() =>
  import('../components/ClientComponent').then((mod) => mod.Hello),
);

[ 출처 ] https://nextjs.org/docs/app/building-your-application/optimizing/lazy-loading

]]> <![CDATA[[ Optimizing ] Static Assets]]> https://velog.io/@chacha_fe/Optimizing-Static-Assets https://velog.io/@chacha_fe/Optimizing-Static-Assets Tue, 23 May 2023 11:09:15 GMT Next.js는 루트 디렉토리에 public이라는 폴더 아래와 같이 이미지와 같은 정적 파일을 제공할 수 있다.

public 내부의 파일은 기본 URL (/)을 기준으로 코드에서 참조할 수 있다.


예를 들어, public 내부에 me.png를 추가하면 다음 코드로 이미지에 액세스할 수 있다.

import Image from 'next/image';

function Avatar() {
  return <Image src="/me.png" alt="me" width="64" height="64" />;
}

export default Avatar;

이 폴더는 robots.txt, favicon.ico, Google Site Verification 및 다른 정적 파일(.html 포함)에도 유용하다.

  • 디렉토리 이름이 public인지 확인해야한다. 이름을 변경할 수 없으며, 정적 에셋을 제공하는 유일한 디렉토리다.

  • pages/ 디렉토리에 있는 파일과 같은 이름의 정적 파일이 있는지 확인하여 오류가 발생하지 않도록 해야 한다.

  • Next.js에서는 빌드 시점에 public 디렉토리에 있는 에셋만 제공된다. 런타임에서 추가된 파일은 사용할 수 없다. 지속적인 파일 저장을 위해 AWS S3와 같은 타사 서비스를 사용하는 것을 권장한다.


[ 출처 ] https://nextjs.org/docs/app/building-your-application/optimizing/static-assets

]]> <![CDATA[[ Optimizing ] Metadata]]> https://velog.io/@chacha_fe/Optimizing-Metadata https://velog.io/@chacha_fe/Optimizing-Metadata Tue, 23 May 2023 11:08:11 GMT Next.js에는 SEO 및 웹 공유성을 향상시키기 위해 애플리케이션의 메타데이터(예: HTML head 요소 내부의 meta 및 link 태그)를 정의할 수 있는 Metadata API가 있다.


애플리케이션에 메타데이터를 추가하는 두 가지 방법이 있다.

  1. 구성 기반 메타데이터 layout.js 또는 page.js 파일에서 정적 메타데이터 객체나 동적 generateMetadata 함수를 내보낸다.

  2. 파일 기반 메타데이터 라우트 세그먼트에 정적 또는 동적으로 생성된 특수 파일을 추가한다.


이러한 두 가지 옵션 모두 Next.js가 페이지에 대한 관련 <head> 요소를 자동으로 생성한다.

또한 ImageResponse 생성자를 사용하여 동적 OG 이미지를 생성할 수도 있다.


정적 메타데이터

정적 메타데이터를 정의하려면 layout.js 또는 정적 page.js 파일에서 Metadata 객체를 내보낸다.

// layout.tsx or page.tsx

import { Metadata } from 'next';

export const metadata: Metadata = {
  title: '...',
  description: '...',
};

export default function Page() {}

동적 메타데이터

동적 값을 필요로하는 메타데이터를 가져오기 위해 generateMetadata 함수를 사용할 수 있다.

// app/products/[id]/page.tsx

import { Metadata, ResolvingMetadata } from 'next';

type Props = {
  params: { id: string };
  searchParams: { [key: string]: string | string[] | undefined };
};

export async function generateMetadata(
  { params, searchParams }: Props,
  parent?: ResolvingMetadata,
): Promise<Metadata> {
  // read route params
  const id = params.id;

  // fetch data
  const product = await fetch(`https://.../${id}`).then((res) => res.json());

  // optionally access and extend (rather than replace) parent metadata
  const previousImages = (await parent).openGraph?.images || [];

  return {
    title: product.title,
    openGraph: {
      images: ['/some-specific-page-image.jpg', ...previousImages],
    },
  };
}

export default function Page({ params, searchParams }: Props) {}

💡 알아두면 좋은 점

  • 정적 및 동적 메타데이터(generateMetadata를 통한)는 Server Components에서만 지원된다.

  • 라우트를 렌더링할 때, Next.js는 generateMetadata, generateStaticParams, layout, page 및 Server Components 전체에서 동일한 데이터에 대한 중복된 fetch 요청을 자동으로 제거한다. fetch를 사용할 수 없는 경우 React 캐시를 사용할 수 있다.

  • Next.js는 generateMetadata 내부에서 데이터를 가져오는 것이 완료될 때까지 UI를 클라이언트로 스트리밍하기 전까지 대기한다. 이는 스트리밍 응답의 첫 부분에 <head> 태그가 포함되도록 보장한다.


파일 기반 메타데이터

이러한 특수 파일들은 메타데이터로 사용할 수 있다.

  • favicon.ico, apple-icon.jpg, 그리고 icon.jpg

  • opengraph-image.jpg와 twitter-image.jpg

  • robots.txt

  • sitemap.xml

이러한 파일들은 정적 메타데이터로 사용하거나 코드로 프로그래밍적으로 생성할 수 있다.


동작

파일 기반 메타데이터는 더 높은 우선순위를 가지며, 구성 기반 메타데이터보다 우선하여 적용된다.


기본 필드 (Default Fields)

경로에서 메타데이터를 정의하지 않더라도 항상 추가되는 두 가지 기본 메타 태그가 있다.

  • meta charset 태그는 웹 사이트의 문자 인코딩을 설정한다.

  • meta viewport 태그는 다른 기기에 맞게 웹 사이트의 뷰포트 너비와 확대/축소를 설정한다.


<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />

디폴트 viewport 메타 태그를 덮어쓸 수 있다.


순서 (Ordering)

메타데이터는 순서대로 평가되며, 최종 페이지.js 세그먼트에 가장 가까운 세그먼트에서부터 시작하여 루트 세그먼트까지 내려간다. 예를 들면 다음과 같다.

  1. app/layout.tsx (루트 레이아웃)

  2. app/blog/layout.tsx (중첩된 블로그 레이아웃)

  3. app/blog/[slug]/page.tsx (블로그 페이지)


병합 (Merging)

평가 순서를 따라 동일한 경로의 여러 세그먼트에서 내보낸 메타데이터 객체는 얕은 병합을 통해 경로의 최종 메타데이터 출력을 형성하기 위해 함께 병합된다. 중복된 키는 순서에 따라 교체된다.

이는 이전 세그먼트에서 정의된 openGraph 및 robots와 같은 중첩 필드를 가진 메타데이터가 마지막 세그먼트에 의해 덮어씌워진다는 것을 의미한다.


1. 필드 덮어쓰기

// app/layout.ts

export const metadata = {
  title: 'Acme',
  openGraph: {
    title: 'Acme',
    description: 'Acme is a...',
  },
};
// app/blog/page.js

export const metadata = {
  title: 'Blog',
  openGraph: {
    title: 'Blog',
  },
};

// Output:
// <title>Blog</title>
// <meta property="og:title" content="Blog" />

  • app/layout.js의 title은 app/blog/page.js의 title에 의해 대체된다.

  • app/blog/page.js에서 openGraph 메타데이터를 설정하기 때문에 app/layout.js의 모든 openGraph 필드가 대체된다. openGraph.description이 없는 것에 주목해야한다.


일부 중첩된 필드를 세그먼트 간에 공유하면서 다른 필드를 덮어쓰고 싶다면 별도의 변수로 분리할 수 있다.

// app/shared-metadata.js

export const openGraphImage = { images: ['http://...'] };
// app/page.js

import { openGraphImage } from './shared-metadata';

export const metadata = {
  openGraph: {
    ...openGraphImage,
    title: 'Home',
  },
};
// app/about/page.js

import { openGraphImage } from '../shared-metadata';

export const metadata = {
  openGraph: {
    ...openGraphImage,
    title: 'About',
  },
};

위의 예시에서는 app/layout.js와 app/about/page.js 간에 OG 이미지가 공유되고 제목은 다르다.


2. 필드 상속

// app/layout.ts

export const metadata = {
  title: 'Acme',
  openGraph: {
    title: 'Acme',
    description: 'Acme is a...',
  },
};
// app/about/page.js

export const metadata = {
  title: 'About',
};

// Output:
// <title>About</title>
// <meta property="og:title" content="Acme" />
// <meta property="og:description" content="Acme is a..." />

  • app/layout.js의 title은 app/about/page.js의 title에 의해 대체된다.

  • app/about/page.js에서 openGraph 메타데이터를 설정하지 않았기 때문에 app/layout.js의 모든 openGraph 필드가 상속된다.


동적 이미지 생성

ImageResponse 생성자를 사용하면 JSX와 CSS를 사용하여 동적 이미지를 생성할 수 있다. 이는 오픈 그래프 이미지, Twitter 카드 등의 소셜 미디어 이미지를 생성하는 데 유용하다.

ImageResponse는 Edge Runtime을 사용하며, Next.js는 자동으로 캐시된 이미지에 올바른 헤더를 추가하여 성능을 향상시키고 다시 계산을 줄이는 데 도움을 준다.


사용하려면 next/server에서 ImageResponse를 가져올 수 있다.

// app/about/route.jsx

import { ImageResponse } from 'next/server';

export const runtime = 'edge';

export async function GET() {
  return new ImageResponse(
    (
      <div
        style={{
          fontSize: 128,
          background: 'white',
          width: '100%',
          height: '100%',
          display: 'flex',
          textAlign: 'center',
          alignItems: 'center',
          justifyContent: 'center',
        }}
      >
        Hello world!
      </div>
    ),
    {
      width: 1200,
      height: 600,
    },
  );
}

ImageResponse는 Route Handlers 및 파일 기반 메타데이터를 포함한 다른 Next.js API와 잘 통합된다. 예를 들어, opengraph-image.tsx 파일에서 ImageResponse를 사용하여 빌드 시간에 또는 요청 시간에 동적으로 오픈 그래프 이미지를 생성할 수 있다.

ImageResponse는 flexbox와 절대 위치 지정을 포함한 일반적인 CSS 속성, 사용자 정의 폰트, 텍스트 줄 바꿈, 가운데 정렬 및 중첩 이미지를 지원한다.


💡  알아두면 좋은 점

  • ImageResponse는 HTML과 CSS를 PNG로 변환하기 위해 @vercel/og, Satori 및 Resvg를 사용한다.

  • Edge Runtime만 지원된다. 기본 Node.js 런타임은 작동하지 않는다.

  • flexbox와 CSS 속성의 일부만 지원된다. 고급 레이아웃(예: display: grid)은 작동하지 않는다.

  • 최대 번들 크기는 500KB다. 번들 크기에는 JSX, CSS, 폰트, 이미지 및 기타 에셋이 포함된다. 제한을 초과하는 경우 에셋의 크기를 줄이거나 런타임에서 가져오는 방식을 고려해야 한다.

  • ttf, otf 및 woff 폰트 형식만 지원된다. 폰트 구문 분석 속도를 극대화하기 위해 woff보다는 ttf 또는 otf가 선호된다.


JSON-LD

JSON-LD는 구조화된 데이터를 검색 엔진이 내용을 이해하는 데 사용할 수 있는 형식이다. 예를 들어, 사람, 이벤트, 조직, 영화, 책, 레시피 및 여러 종류의 개체를 설명하는 데 사용할 수 있다.

JSON-LD에 대한 현재 권장 사항은 구조화된 데이터를 layout.js 또는 page.js 컴포넌트에서 <script> 태그로 렌더링하는 것이다. 예를 들면 다음과 같다.

// app/products/[id]/page.tsx

export default async function Page({ params }) {
  const product = await getProduct(params.id);

  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Product',
    name: product.name,
    image: product.image,
    description: product.description,
  };

  return (
    <section>
      {/* Add JSON-LD to your page */}
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      {/* ... */}
    </section>
  );
}

Google의 Rich Results Test 또는 일반적인 Schema Markup Validator를 사용하여 구조화된 데이터를 유효성 검사하고 테스트할 수 있다.

schema-dts와 같은 커뮤니티 패키지를 사용하여 TypeScript로 JSON-LD를 작성할 수 있다.


[ 출처 ] https://nextjs.org/docs/app/building-your-application/optimizing/metadata

]]> <![CDATA[[ Optimizing ] Scripts]]> https://velog.io/@chacha_fe/Optimizing-Scripts https://velog.io/@chacha_fe/Optimizing-Scripts Tue, 23 May 2023 11:04:01 GMT 레이아웃 스크립트

여러 경로에 대해 타사 스크립트를 로드하려면 next/script를 가져오고 스크립트를 직접 레이아웃 컴포넌트에 포함시킨다.

// app/dashboard/layout.tsx

import Script from 'next/script';

export default function DashboardLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <>
      <section>{children}</section>
      <Script src="https://example.com/script.js" />
    </>
  );
}

사용자가 폴더 경로 (예: dashboard/page.js) 또는 중첩된 경로 (예: dashboard/settings/page.js)에 액세스할 때 타사 스크립트가 가져온다. Next.js는 동일한 레이아웃에서 여러 경로를 탐색하더라도 스크립트가 한 번만 로드되도록 보장한다.


애플리케이션 스크립트

모든 경로에 대해 타사 스크립트를 로드하려면 next/script를 가져오고 스크립트를 직접 루트 레이아웃에 포함시킨다.

// app/layout.tsx

import Script from 'next/script';

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>{children}</body>
      <Script src="https://example.com/script.js" />
    </html>
  );
}

이 스크립트는 애플리케이션의 모든 경로에 액세스할 때 로드되고 실행된다. Next.js는 사용자가 여러 페이지 사이를 이동하더라도 스크립트가 한 번만 로드되도록 보장한다.

성능에 불필요한 영향을 최소화하기 위해 타사 스크립트를 특정 페이지나 레이아웃에만 포함하는 것을 권장한다.


전략 (Strategy)

next/script의 기본 동작은 페이지나 레이아웃에서 타사 스크립트를 로드할 수 있게 해준다. 그러나 strategy 속성을 사용하여 로딩 동작을 세밀하게 조정할 수 있다.

  • beforeInteractive : Next.js 코드 및 페이지 하이드레이션 전에 스크립트를 로드한다.

  • afterInteractive : (기본값) 일부 하이드레이션 이후에 스크립트를 조기에 로드한다.

  • lazyOnload : 브라우저 idle time에 스크립트를 늦게 로드한다.

  • worker : (실험적 기능) 웹 워커에서 스크립트를 로드한다.


스크립트를 웹 워커로 오프로드 (실험적 기능)

워커 전략은 아직 안정적이지 않으며 app 디렉토리와 함께 작동하지 않는다. 주의하여 사용해야한다.

워커 전략을 사용하는 스크립트는 Partytown과 함께 웹 워커에서 오프로드되고 실행된다. 이를 통해 메인 스레드를 애플리케이션 코드의 나머지 부분에 할당하여 사이트의 성능을 향상시킬 수 있다.

이 전략은 여전히 실험적이며 next.config.js에서 nextScriptWorkers 플래그가 활성화된 경우에만 사용할 수 있다.

// next.config.js

module.exports = {
  experimental: {
    nextScriptWorkers: true,
  },
};

그런 다음 next를 실행한다. (보통 npm run dev 또는 yarn dev). 그러면 Next.js가 필요한 패키지를 설치하기 위한 안내를 제공한다.

npm run dev

다음과 같은 지침을 볼 수 있다 : npm install @builder.io/partytown 명령을 실행하여 Partytown을 설치한다.

설정이 완료되면 strategy="worker"를 정의하면 Partytown이 자동으로 애플리케이션에 인스턴스화되고 스크립트가 웹 워커로 오프로드된다.

// pages/home.tsx

import Script from 'next/script';

export default function Home() {
  return (
    <>
      <Script src="https://example.com/script.js" strategy="worker" />
    </>
  );
}

인라인 스크립트

스크립트 구성 요소는 외부 파일에서 로드되지 않는 인라인 스크립트도 지원한다. 중괄호({}) 안에 JavaScript를 작성하여 사용할 수 있다.

<Script id="show-banner">
  {`document.getElementById('banner').classList.remove('hidden')`}
</Script>

또는 dangerouslySetInnerHTML 속성을 사용하여 작성할 수도 있다.

<Script
  id="show-banner"
  dangerouslySetInnerHTML={{
    __html: `document.getElementById('banner').classList.remove('hidden')`,
  }}
/>

Next.js가 스크립트를 추적하고 최적화하기 위해 인라인 스크립트에는 id 속성을 할당해야 한다.


추가 코드 실행 (Executing Additional Code)

이벤트 핸들러를 Script 컴포넌트와 함께 사용하여 특정 이벤트가 발생한 후에 추가 코드를 실행할 수 있다.

  • onLoad : 스크립트가 로드된 후에 코드를 실행한다.

  • onReady : 스크립트가 로드된 후와 컴포넌트가 마운트될 때마다 코드를 실행한다.

  • onError : 스크립트 로드에 실패한 경우에 코드를 실행한다.


이러한 핸들러는 next/script가 가져와지고 "use client"가 코드의 첫 번째 줄로 정의된 클라이언트 컴포넌트 내에서만 작동한다.


추가 속성 (Additional Attributes)

Script 컴포넌트에서 사용되지 않는 nonce나 사용자 정의 데이터 속성과 같은 여러 DOM 속성을 <script> 요소에 할당할 수 있다. 추가 속성을 포함하면 최종으로 최적화된 <script> 요소로 자동으로 전달된다.

// app/page.tsx

import Script from 'next/script';

export default function Page() {
  return (
    <>
      <Script
        src="https://example.com/script.js"
        id="example-script"
        nonce="XUENAJFW"
        data-test="script"
      />
    </>
  );
}

[ 출처 ] https://nextjs.org/docs/app/building-your-application/optimizing/scripts

]]> <![CDATA[[ Optimizing ] Fonts]]> https://velog.io/@chacha_fe/Optimizing-Fonts https://velog.io/@chacha_fe/Optimizing-Fonts Tue, 23 May 2023 11:00:56 GMT next/font는 폰트를 자동으로 최적화하고(사용자 정의 폰트 포함) 개인 정보 보호와 성능 향상을 위해 외부 네트워크 요청을 제거한다. 참고자료

next/font에는 모든 폰트 파일에 대한 내장 자동 셀프 호스팅 기능이 포함되어 있다. 이는 사용되는 기본 CSS size-adjust 속성 덕분에 웹 폰트를 최적으로 로드하여 레이아웃 시프트를 제로로 만들 수 있다.

이 새로운 폰트 시스템을 사용하면 Google Fonts를 효율성과 개인 정보 보호를 고려하여 편리하게 사용할 수도 있다. CSS와 폰트 파일은 빌드 시간에 다운로드되고 정적 에셋의 나머지와 함께 자체 호스팅된다. 브라우저에서 Google로 요청이 전송되지 않는다.


Google Fonts

Google 폰트를 자동으로 셀프 호스팅한다. 폰트는 배포에 포함되어 배포와 동일한 도메인에서 제공된다. 브라우저에서 Google로 요청이 전송되지 않는다.

next/font/google에서 사용하려는 폰트를 함수로 가져와서 시작한다. 최상의 성능과 유연성을 위해 변수 폰트를 사용하는 것을 권장한다.

// app/layout.tsx

import { Inter } from 'next/font/google';

// If loading a variable font, you don't need to specify the font weight
const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
});

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en" className={inter.className}>
      <body>{children}</body>
    </html>
  );
}

변수 폰트를 사용할 수 없는 경우, weight를 지정해야 한다.

import { Roboto } from 'next/font/google';

const roboto = Roboto({
  weight: '400',
  subsets: ['latin'],
  display: 'swap',
});

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en" className={roboto.className}>
      <body>{children}</body>
    </html>
  );
}

배열을 사용하여 여러 weight와/또는 스타일을 지정할 수 있다.

const roboto = Roboto({
  weight: ['400', '700'],
  style: ['normal', 'italic'],
  subsets: ['latin'],
  display: 'swap',
});

여러 단어로 된 폰트 이름에는 밑줄 (_)을 사용한다. 예: Roboto Mono는 Roboto_Mono로 가져와야 한다.


서브셋 지정(Specifying a subset)

Google 폰트는 자동으로 서브셋으로 처리된다. 이렇게 하면 폰트 파일의 크기가 줄어들고 성능이 향상된다. 미리로드할 서브셋을 정의해야 한다. preload가 true인 상태에서 어떤 서브셋도 지정하지 않으면 경고가 발생한다.

이를 함수 호출에 추가하여 수행할 수 있다.

// app/layout.tsx

const inter = Inter({ subsets: ['latin'] });

여러 폰트 사용하기(Using Multiple Fonts)

애플리케이션에서 여러 폰트를 가져와 사용할 수 있다. 두 가지 접근 방식이 있다.

첫 번째 접근 방식은 유틸리티 함수를 생성하여 폰트를 내보내고 가져와 필요한 곳에 className을 적용하는 것이다. 이렇게 하면 폰트가 렌더링될 때만 사전로드된다.

// app/fonts.ts

import { Inter, Roboto_Mono } from 'next/font/google';

export const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
});

export const roboto_mono = Roboto_Mono({
  subsets: ['latin'],
  display: 'swap',
});
// app/layout.tsx

import { inter } from './fonts';

export default function Layout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en" className={inter.className}>
      <body>
        <div>{children}</div>
      </body>
    </html>
  );
}
// app/page.tsx
import { roboto_mono } from './fonts';

export default function Page() {
  return (
    <>
      <h1 className={roboto_mono.className}>My page</h1>
    </>
  );
}

위의 예제에서는 Inter가 전역으로 적용되고, Roboto Mono는 필요할 때 가져와 적용할 수 있다.

또는 CSS 변수를 생성하고 원하는 CSS 솔루션과 함께 사용할 수도 있다.

import { Inter, Roboto_Mono } from 'next/font/google';
import styles from './global.css';

const inter = Inter({
  subsets: ['latin'],
  variable: '--font-inter',
  display: 'swap',
});

const roboto_mono = Roboto_Mono({
  subsets: ['latin'],
  variable: '--font-roboto-mono',
  display: 'swap',
});

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en" className={`${inter.variable} ${roboto_mono.variable}`}>
      <body>
        <h1>My App</h1>
        <div>{children}</div>
      </body>
    </html>
  );
}
// app/global.css

html {
  font-family: var(--font-inter);
}

h1 {
  font-family: var(--font-roboto-mono);
}

위의 예제에서는 Inter가 전역으로 적용되고, <h1> 태그에는 Roboto Mono로 스타일이 지정된다.

클라이언트가 다운로드해야 하는 추가 리소스인 각 새로운 폰트마다 신중하게 여러 폰트를 사용하는 것을 권장한다.


로컬 폰트

next/font/local을 가져와서 로컬 폰트 파일의 src를 지정하라. 최상의 성능과 유연성을 위해 변수 폰트를 사용하는 것을 권장한다.

// app/layout.tsx

import localFont from 'next/font/local';

// Font files can be colocated inside of `app`
const myFont = localFont({
  src: './my-font.woff2',
  display: 'swap',
});

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en" className={myFont.className}>
      <body>{children}</body>
    </html>
  );
}

단일 폰트 패밀리에 여러 파일을 사용하려면 src를 배열로 지정할 수 있다.

const roboto = localFont({
  src: [
    {
      path: './Roboto-Regular.woff2',
      weight: '400',
      style: 'normal',
    },
    {
      path: './Roboto-Italic.woff2',
      weight: '400',
      style: 'italic',
    },
    {
      path: './Roboto-Bold.woff2',
      weight: '700',
      style: 'normal',
    },
    {
      path: './Roboto-BoldItalic.woff2',
      weight: '700',
      style: 'italic',
    },
  ],
});

Tailwind CSS와 사용

next/font는 CSS 변수를 통해 Tailwind CSS와 함께 사용할 수 있다.


아래 예제에서는 next/font/google에서 Inter 폰트를 사용한다. (Google이나 로컬 폰트에서 원하는 폰트를 사용할 수 있다). 변수 옵션을 사용하여 폰트를 로드하고 CSS 변수 이름을 정의하고 inter에 할당한다. 그런 다음, inter.variable을 사용하여 CSS 변수를 HTML 문서에 추가한다.

// app/layout.tsx

import { Inter, Roboto_Mono } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-inter',
});

const roboto_mono = Roboto_Mono({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-roboto-mono',
});

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en" className={`${inter.variable} ${roboto_mono.variable}`}>
      <body>{children}</body>
    </html>
  );
}

마지막으로, Tailwind CSS config에 CSS 변수를 추가한다.

// tailwind.config.js
/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    './pages/**/*.{js,ts,jsx,tsx}',
    './components/**/*.{js,ts,jsx,tsx}',
  ],
  theme: {
    extend: {
      fontFamily: {
        sans: ['var(--font-inter)'],
        mono: ['var(--font-roboto-mono)'],
      },
    },
  },
  plugins: [],
};

이제 font-sans와 font-mono 유틸리티 클래스를 사용하여 폰트를 요소에 적용할 수 있다.


사전 로드(Preloading)

사이트의 페이지에서 폰트 함수를 호출할 때, 해당 폰트는 전역으로 사용 가능하고 모든 경로에 사전로드되는 것은 아니다. 대신, 사용된 파일의 종류에 따라 관련 경로에만 폰트가 사전로드된다.

  • 고유한 페이지인 경우, 해당 페이지의 고유 경로에 사전로드된다.

  • 레이아웃인 경우, 해당 레이아웃으로 래핑된 모든 경로에 사전로드된다.

  • 루트 레이아웃인 경우, 모든 경로에 사전로드된다.


폰트 재사용(Reusing Fonts)

localFont 또는 Google 폰트 함수를 호출할 때마다 해당 폰트는 애플리케이션 내에서 하나의 인스턴스로 호스팅된다. 따라서 동일한 폰트 함수를 여러 파일에서 로드하는 경우, 동일한 폰트의 여러 인스턴스가 호스팅된다.

이 경우 다음을 권장한다.

  • 공유 파일에서 폰트 로더 함수를 호출한다.

  • 상수로 export 한다.

  • 해당 폰트를 사용하려는 각 파일에서 해당 상수를 import 한다.


[ 출처 ] https://nextjs.org/docs/app/building-your-application/optimizing/fonts

]]> <![CDATA[[ Optimizing ] Images]]> https://velog.io/@chacha_fe/Optimizing-Images https://velog.io/@chacha_fe/Optimizing-Images Tue, 23 May 2023 10:58:14 GMT Next.js의 Image 컴포넌트는 HTML <img> 요소를 확장하여 다음과 같은 기능을 제공한다.

  1. 크기 최적화

    WebP 및 AVIF와 같은 현대적인 이미지 형식을 사용하여 각 장치에 맞게 올바르게 크기 조정된 이미지를 자동으로 제공한다.

  2. 시각적 안정성 이미지가 로드될 때 자동으로 레이아웃 이동을 방지한다.

  3. 빠른 페이지 로딩 이미지는 웹 브라우저의 네이티브 지연 로딩을 사용하여 뷰포트에 진입할 때만 로드되며, 선택적으로 흐릿한 플레이스홀더를 사용할 수 있다.

  4. 자산 유연성 원격 서버에 저장된 이미지를 포함하여 필요에 따라 이미지 크기를 실시간으로 조정할 수 있다.


사용법

import Image from 'next/image';

로컬 이미지(Local Images)

로컬 이미지를 사용하려면 .jpg, .png 또는 .webp 이미지 파일을 가져와야 한다.

Next.js는 가져온 파일을 기반으로 이미지의 너비와 높이를 자동으로 결정한다. 이 값은 이미지가 로드되는 동안 누적 레이아웃 변화(Cumulative Layout Shift)를 방지하는 데 사용된다.

// app/page.js

import Image from 'next/image';
import profilePic from './me.png';

export default function Page() {
  return (
    <Image
      src={profilePic}
      alt="Picture of the author"
      // width={500} automatically provided
      // height={500} automatically provided
      // blurDataURL="data:..." automatically provided
      // placeholder="blur" // Optional blur-up while loading
    />
  );
}

동적인 await import() 또는 require()은 지원되지 않는다. import는 정적이어야 하므로 빌드 시간에 분석할 수 있어야 한다.


원격 이미지(Remote Images)

원격 이미지를 사용하려면 src 속성에 URL 문자열을 제공해야 한다.

Next.js는 빌드 과정에서 원격 파일에 액세스할 수 없으므로 width, height 및 선택적인 blurDataURL 속성을 수동으로 제공해야 한다.

너비와 높이 속성은 이미지의 올바른 종횡비를 추론하고 이미지 로딩으로 인한 레이아웃 변화를 방지하는 데 사용된다. 너비와 높이는 이미지 파일의 렌더링 크기를 결정하지는 않는다.

import Image from 'next/image';

export default function Page() {
  return (
    <Image
      src="https://s3.amazonaws.com/my-bucket/profile.png"
      alt="Picture of the author"
      width={500}
      height={500}
    />
  );
}

이미지 최적화를 안전하게 허용하려면 next.config.js에서 지원되는 URL 패턴 목록을 정의한다. 악의적인 사용을 방지하기 위해 가능한 한 구체적으로 지정해야한다.


예를 들어, 다음 구성은 특정 AWS S3 버킷에서만 이미지를 허용한다.

// next.config.js

module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 's3.amazonaws.com',
        port: '',
        pathname: '/my-bucket/**',
      },
    ],
  },
};

이미지 src에 상대적인 URL을 사용하려면 로더(loader)를 사용한다.


도메인(Domains)

원격 이미지를 최적화하면서도 내장된 Next.js 이미지 최적화 API를 사용하고 싶을 수 있다. 이를 위해 로더(loader)를 기본 설정으로 유지하고 Image src 속성에 절대 URL을 입력하면 된다.

악의적인 사용자로부터 애플리케이션을 보호하기 위해 next/image 컴포넌트와 함께 사용할 원격 호스트 이름 목록을 정의해야 한다.


Loaders

앞서 언급한 예제에서 원격 이미지에 대해 부분 URL("/me.png")이 제공되었다. 이는 로더 아키텍처 덕분에 가능한 것이다.

로더는 이미지의 URL을 생성하는 함수다. 이는 제공된 src를 수정하고 다른 크기로 이미지를 요청하기 위해 여러 URL을 생성한다. 이러한 여러 URL은 자동으로 srcset을 생성하는 데 사용되어 방문자가 뷰포트에 적합한 크기의 이미지를 제공받을 수 있다.

Next.js 애플리케이션의 기본 로더는 내장된 이미지 최적화 API를 사용하여 웹의 어느 곳에서나 이미지를 최적화한 다음 Next.js 웹 서버에서 직접 제공한다. CDN이나 이미지 서버에서 이미지를 직접 제공하고 싶다면 몇 줄의 JavaScript로 고유한 로더 함수를 작성할 수 있다.

loader prop으로 이미지당 로더를 정의하거나 loaderFile configuration을 사용하여 애플리케이션 수준에서 로더를 정의할 수 있다.


우선 순위(priority)

각 페이지의 가장 큰 콘텐츠가 되는 이미지에 priority 속성을 추가해야 한다. 이렇게 함으로써 Next.js는 이미지를 로딩하기 위해 특별한 우선순위(예: preload 태그 또는 우선순위 힌트)를 부여할 수 있으며, LCP(Largest Contentful Paint)에 의미 있는 향상을 가져올 수 있다.

LCP 요소는 일반적으로 페이지의 뷰포트 내에서 가장 큰 이미지 또는 텍스트 블록이다. next dev를 실행할 때 LCP 요소가 priority 속성이 없는 <Image>인 경우 콘솔 경고가 표시된다.

LCP 이미지를 식별한 후에는 다음과 같이 속성을 추가할 수 있다.

import Image from 'next/image';
import profilePic from '../public/me.png';

export default function Page() {
  return <Image src={profilePic} alt="Picture of the author" priority />;
}

이미지 사이징(Image Sizing)

이미지가 성능에 가장 많은 영향을 주는 방법 중 하나는 이미지가 로드되는 동안 페이지에서 다른 요소들을 밀어내어 레이아웃이 변경되는 레이아웃 시프트(layout shift)다. 이러한 성능 문제는 사용자에게 귀찮음을 야기하여 Cumulative Layout Shift라는 자체적인 Core Web Vital을 가지게 되었다. 이미지 기반 레이아웃 시프트를 피하기 위해서는 항상 이미지의 크기를 지정해야 한다. 이렇게 함으로써 브라우저는 이미지가 로드되기 전에 정확히 충분한 공간을 예약할 수 있다.


next/image는 좋은 성능 결과를 보장하기 위해 설계되었으므로 레이아웃 시프트에 기여하지 않을 수 있는 방식으로 사용해야 하며, 다음 중 하나의 방식으로 크기를 지정해야 한다.

  1. 정적 임포트를 사용하여 자동으로 크기를 결정한다.

  2. width와 height 속성을 사용하여 명시적으로 크기를 지정한다.

  3. fill을 사용하여 부모 요소에 맞추어 이미지 크기를 암시적으로 지정한다. 이렇게 함으로써 이미지는 부모 요소를 채우도록 확장된다.


💡  이미지 크기를 모르는 경우

이미지의 크기를 알지 못하는 소스에서 이미지에 접근하는 경우 다음과 같은 방법이 있다.

  1. fill 사용 fill 속성을 사용하면 이미지가 부모 요소에 따라 크기가 결정된다. CSS를 사용하여 이미지의 부모 요소에 페이지에서 공간을 제공하고 sizes 속성을 사용하여 미디어 쿼리 브레이크 포인트와 일치하도록 할 수 있다. 또한 fill, contain 또는 cover와 object-position을 함께 사용하여 이미지가 해당 공간을 어떻게 차지할지 정의할 수 있다.

  2. 이미지 정규화 제어 가능한 소스에서 이미지를 제공하는 경우 이미지를 특정 크기로 정규화하기 위해 이미지 파이프라인을 수정하는 것을 고려한다.

  3. API 호출 수정 애플리케이션이 이미지 URL을 API 호출을 통해 가져오는 경우 (예: CMS로부터), API 호출을 수정하여 URL과 함께 이미지의 크기를 반환할 수 있다.


이미지 크기 조정에 대한 제안된 방법이 모두 작동하지 않는 경우 next/image 컴포넌트는 표준 <img> 요소와 함께 페이지에서 잘 작동하도록 설계되었다.


스타일링(Styling)

Image 컴포넌트의 스타일링은 일반 <img> 요소의 스타일링과 유사하지만 몇 가지 지침을 염두에 두어야 한다.

  1. styled-jsx 대신 className 또는 style을 사용한다.
  • 대부분의 경우 className 속성을 사용하는 것을 권장한다. 이는 가져온 CSS 모듈, 글로벌 스타일시트 등이 될 수 있다.
  • 인라인 스타일을 지정하기 위해 style 속성을 사용할 수도 있다.
  • styled-jsx는 현재 컴포넌트에 대해 범위가 지정되므로 사용할 수 없다. (스타일을 전역으로 표시하지 않는 한)
  1. fill을 사용할 때, 부모 요소는 position: relative를 가져야 한다.
  • 이는 해당 레이아웃 모드에서 이미지 요소가 올바르게 렌더링되기 위해 필요하다.
  1. fill을 사용할 때, 부모 요소는 display: block을 가져야 한다.
  • 이것은 <div> 요소의 기본값이지만 그렇지 않은 경우에는 명시해야 한다.

구성(Configuration)

next/image 컴포넌트와 Next.js Image Optimization API는 next.config.js 파일에서 구성할 수 있다. 이러한 구성은 원격 이미지 사용, 사용자 정의 이미지 브레이크포인트 정의, 캐싱 동작 변경 등을 가능하게 한다.


[ 출처 ] https://nextjs.org/docs/app/building-your-application/optimizing/images

]]> <![CDATA[[ Optimizing ] Optimizations]]> https://velog.io/@chacha_fe/Optimizing-Optimizations https://velog.io/@chacha_fe/Optimizing-Optimizations Tue, 23 May 2023 10:54:16 GMT Next.js에는 애플리케이션의 속도와 Core Web Vitals를 개선하기 위해 설계된 다양한 내장 최적화 기능이 제공된다.


내장 컴포넌트

내장 컴포넌트는 일반적인 UI 최적화를 구현하는 복잡성을 추상화한다. 이러한 컴포넌트는 다음과 같다.

Images

네이티브 <img> 요소를 기반으로 구축된다. 이미지 컴포넌트는 이미지의 성능을 최적화하기 위해 지연 로딩 및 기기 크기에 따른 이미지 자동 조정을 수행한다.

네이티브 <a> 태그를 기반으로 구축된다. 링크 컴포넌트는 페이지를 백그라운드에서 미리 가져와서 페이지 전환을 더 빠르고 부드럽게 만든다.

Scripts

네이티브 <script> 태그를 기반으로 구축된다. 스크립트 컴포넌트를 사용하면 타사 스크립트의 로딩과 실행을 제어할 수 있다.


메타데이터

메타데이터는 검색 엔진이 콘텐츠를 더 잘 이해할 수 있도록 도와준다(이는 더 좋은 SEO 결과로 이어질 수 있음). 또한, 소셜 미디어에서 콘텐츠가 어떻게 표시되는지를 사용자 정의할 수 있으며, 이를 통해 다양한 플랫폼에서 보다 매력적이고 일관된 사용자 경험을 만들 수 있다.

Next.js의 메타데이터 API를 사용하면 페이지의 <head> 요소를 수정할 수 있다.

메타데이터는 두 가지 방식으로 구성할 수 있다.

구성 기반 메타데이터(Config-based Metadata)

layout.js 또는 page.js 파일에서 정적 메타데이터 객체 또는 동적 generateMetadata 함수를 내보낸다.

파일 기반 메타데이터

경로 세그먼트에 정적 또는 동적으로 생성된 특수 파일을 추가한다.

또한, imageResponse 생성자를 사용하여 JSX 및 CSS로 동적 Open Graph 이미지를 생성할 수도 있다.


정적 자산(Static Assets)

Next.js의 /public 폴더를 사용하여 이미지, 폰트 및 기타 파일과 같은 정적 자산을 제공할 수 있다.

/public 폴더 내의 파일은 CDN 공급자에 의해 캐시될 수 있으므로 효율적으로 전달된다.


분석 및 모니터링

대규모 애플리케이션의 경우, Next.js는 인기있는 분석 및 모니터링 도구와 통합되어 애플리케이션의 성능을 이해하는 데 도움을 준다. 자세한 정보는 , OpenTelemetry,  Instrumentation 를 통해 확인할 수 있다.


[ 출처 ] https://nextjs.org/docs/app/building-your-application/optimizing

]]> <![CDATA[[ Styling ] Styling]]> https://velog.io/@chacha_fe/Styling-Styling https://velog.io/@chacha_fe/Styling-Styling Tue, 23 May 2023 10:52:17 GMT Next.js는 애플리케이션의 스타일링을 위해 다양한 방법을 지원한다.

  • Global CSS : 전통적인 CSS에 익숙한 사용자에게는 간단하고 익숙한 방법이지만, 애플리케이션이 커짐에 따라 CSS 번들이 커지고 스타일 관리가 어려워질 수 있다.

  • CSS Module : 이름 충돌을 피하고 유지 관리성을 향상시키기 위해 로컬 범위로 제한된 CSS 클래스를 생성한다.

  • Tailwind CSS : 유틸리티 기반의 CSS 프레임워크로, 유틸리티 클래스를 조합하여 빠르게 사용자 정의 디자인을 만들 수 있다.

  • Sass : 변수, 중첩된 규칙, 믹스인과 같은 기능을 추가하여 CSS를 확장하는 인기 있는 CSS 전처리기다.

  • CSS-in-JS : JavaScript 컴포넌트에 CSS를 직접 포함시켜 동적이고 로컬 범위의 스타일링을 가능하게 한다.


CSS Modules

Next.js는 .module.css 확장자를 사용하여 CSS Modules를 내장 지원한다.

CSS Modules는 자동으로 고유한 클래스 이름을 생성하여 CSS를 로컬 범위로 제한한다. 이를 통해 충돌 걱정 없이 다른 파일에서 동일한 클래스 이름을 사용할 수 있다. 이러한 동작으로 CSS Modules는 컴포넌트 수준의 CSS를 포함하기에 이상적인 방법이다.


CSS Modules 예시

// app/dashboard/layout.tsx

import styles from './styles.module.css';

export default function DashboardLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return <section className={styles.dashboard}>{children}</section>;
}
// app/dashboard/styles.module.css

.dashboard {
  padding: 24px;
}

CSS Modules은 선택적인 기능이며, .module.css 확장자를 가진 파일에만 활성화된다. 일반 <link> 스타일시트와 글로벌 CSS 파일은 여전히 지원된다.

프로덕션 환경에서는 모든 CSS Module 파일이 자동으로 많은 축소 및 코드 분할된 .css 파일로 연결된다. 이러한 .css 파일은 애플리케이션에서 핫 실행 경로를 나타내며, 애플리케이션을 그리기(paint) 위해 최소한의 CSS만 로드되도록 보장한다.


전역 스타일

global.css를 통해 전역 스타일을 적용시킬 수 있다.

// app/global.css

body {
  padding: 20px 20px 60px;
  max-width: 680px;
  margin: 0 auto;
}

루트 레이아웃 (app/layout.js) 내에서 global.css 스타일시트를 가져와 애플리케이션의 모든 라우트에 스타일을 적용한다.

// app/layout.tsx

// These styles apply to every route in the application
import './global.css';

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  );
}

외부 스타일 시트

외부 패키지에서 발행한 스타일시트는 app 디렉토리 내의 어디에서든, 컴포넌트와 함께 사용할 수 있다. 외부 스타일시트는 npm 패키지로부터 직접 가져와야 하거나 코드베이스와 함께 다운로드하여 동일한 위치에 놓아야 한다. <link rel="stylesheet" />는 사용할 수 없다.

// app/layout.tsx

import 'bootstrap/dist/css/bootstrap.css';

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body className="container">{children}</body>
    </html>
  );
}

추가 기능

Next.js에서는 스타일 추가 작성 환경을 개선하는 추가 기능이 포함되어 있다.

  • next dev로 로컬에서 실행할 때, 로컬 스타일시트(전역 스타일시트 또는 CSS 모듈)는 편집을 저장하는 동안 변경 사항이 즉시 반영되도록 Fast Refresh를 활용한다.

  • next build로 프로덕션 빌드를 생성할 때, CSS 파일은 더 적은 수의 축소된 .css 파일로 번들링되어 스타일을 검색하는 데 필요한 네트워크 요청 수를 줄인다.

  • JavaScript를 비활성화하면 스타일은 프로덕션 빌드 (next start)에서도 로드된다. 그러나 Fast Refresh를 사용하려면 여전히 next dev에서 JavaScript가 필요하다.


Tailwind CSS

Tailwind CSS는 Next.js와 아주 적합한 유틸리티 우선 CSS 프레임워크이다.


Tailwind CSS 설치

Tailwind CSS 패키지를 설치하고 init 명령을 실행하여 tailwind.config.js 및 postcss.config.js 파일을 생성한다.

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

Tailwind 설정

tailwind.config.js 파일 내에서 Tailwind CSS 클래스 이름을 사용할 파일에 경로를 추가한다.

postcss.config.js를 수정할 필요는 없다.

// tailwind.config.js

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    './app/**/*.{js,ts,jsx,tsx,mdx}', // Note the addition of the `app` directory.
    './pages/**/*.{js,ts,jsx,tsx,mdx}',
    './components/**/*.{js,ts,jsx,tsx,mdx}',

    // Or if using `src` directory:
    './src/**/*.{js,ts,jsx,tsx,mdx}',
  ],
  theme: {
    extend: {},
  },
  plugins: [],
};

Tailwind 스타일 불러오기

Tailwind가 생성한 스타일을 애플리케이션의 전역 스타일시트에 주입하기 위해 Tailwind가 사용할 Tailwind CSS 지시문을 추가한다.

// app/globals.css

@tailwind base;
@tailwind components;
@tailwind utilities;

루트 레이아웃 (app/layout.tsx) 내에서 globals.css 스타일시트를 가져와 애플리케이션의 모든 라우트에 스타일을 적용한다.

// app/layout.tsx

import type { Metadata } from 'next';

// These styles apply to every route in the application
import './globals.css';

export const metadata: Metadata = {
  title: 'Create Next App',
  description: 'Generated by create next app',
};

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  );
}

유틸리티 클래스 사용

export default function Page() {
  return <h1 className="text-3xl font-bold underline">Hello, Next.js!</h1>;
}

Turbopack와 함께 사용

Next.js 13.1부터는 Turbopack을 사용하여 Tailwind CSS와 PostCSS를 지원한다.


CSS-in-JS

런타임 JavaScript가 필요한 CSS-in-JS 라이브러리는 현재 서버 컴포넌트에서 지원되지 않는다. CSS-in-JS를 사용하는 경우, 서버 컴포넌트와 스트리밍과 같은 최신 React 기능을 사용하려면 라이브러리 작성자가 최신 버전의 React를 지원해야 한다.


다음 라이브러리는 앱 디렉토리의 클라이언트 컴포넌트에서 지원된다.

  • styled-jsx
  • styled-components
  • tamagui
  • style9
  • vanilla-extract

다음은 현재 지원 작업이 진행 중인 라이브러리다.

  • emotion
  • Material UI
  • Chakra UI

서버 컴포넌트를 스타일링하려면 CSS Module이나 PostCSS 또는 Tailwind CSS와 같이 CSS 파일을 출력하는 기타 솔루션을 사용하는 것을 권장한다.


App에서 CSS-in-JS 구성

CSS-in-JS를 구성하는 것은 세 단계의 선택적인 프로세스로 진행된다.

  1. 렌더링 중에 모든 CSS 규칙을 수집하는 스타일 레지스트리

  2. 규칙이 사용될 가능성이 있는 콘텐츠 이전에 규칙을 삽입하는 새로운 useServerInsertedHTML 훅

  3. 초기 서버 사이드 렌더링 중에 앱을 스타일 레지스트리로 래핑하는 클라이언트 컴포넌트


styled-jsx

Client Components에서 styled-jsx를 사용하려면 v5.1.0을 사용해야 한다. 먼저 새로운 레지스트리를 만든다.

// app/registry.tsx

'use client';

import React, { useState } from 'react';
import { useServerInsertedHTML } from 'next/navigation';
import { StyleRegistry, createStyleRegistry } from 'styled-jsx';

export default function StyledJsxRegistry({
  children,
}: {
  children: React.ReactNode;
}) {
  // Only create stylesheet once with lazy initial state
  // x-ref: https://reactjs.org/docs/hooks-reference.html#lazy-initial-state
  const [jsxStyleRegistry] = useState(() => createStyleRegistry());

  useServerInsertedHTML(() => {
    const styles = jsxStyleRegistry.styles();
    jsxStyleRegistry.flush();
    return <>{styles}</>;
  });

  return <StyleRegistry registry={jsxStyleRegistry}>{children}</StyleRegistry>;
}

그런 다음 루트 레이아웃을 레지스트리로 래핑한다.

// app/layout.tsx

import StyledJsxRegistry from './registry';

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html>
      <body>
        <StyledJsxRegistry>{children}</StyledJsxRegistry>
      </body>
    </html>
  );
}

Styled-Components

다음은 styled-components@v6.0.0-rc.1 이상을 구성하는 방법의 예시다.


먼저, styled-components API를 사용하여 렌더링 중에 생성된 모든 CSS 스타일 규칙을 수집하는 전역 레지스트리 컴포넌트와 해당 규칙을 반환하는 함수를 만든다. 그런 다음 useServerInsertedHTML 훅을 사용하여 레지스트리에 수집된 스타일을 루트 레이아웃의 <head> HTML 태그에 삽입한다.

// lib/registry.tsx

'use client';

import React, { useState } from 'react';
import { useServerInsertedHTML } from 'next/navigation';
import { ServerStyleSheet, StyleSheetManager } from 'styled-components';

export default function StyledComponentsRegistry({
  children,
}: {
  children: React.ReactNode;
}) {
  // Only create stylesheet once with lazy initial state
  // x-ref: https://reactjs.org/docs/hooks-reference.html#lazy-initial-state
  const [styledComponentsStyleSheet] = useState(() => new ServerStyleSheet());

  useServerInsertedHTML(() => {
    const styles = styledComponentsStyleSheet.getStyleElement();
    styledComponentsStyleSheet.instance.clearTag();
    return <>{styles}</>;
  });

  if (typeof window !== 'undefined') return <>{children}</>;

  return (
    <StyleSheetManager sheet={styledComponentsStyleSheet.instance}>
      {children}
    </StyleSheetManager>
  );
}

루트 레이아웃의 children prop을 스타일 레지스트리 컴포넌트로 래핑한다.

// app/layout.tsx

import StyledComponentsRegistry from './lib/registry';

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html>
      <body>
        <StyledComponentsRegistry>{children}</StyledComponentsRegistry>
      </body>
    </html>
  );
}

💡  알아두면 좋은 점

  • 서버 렌더링 중에 스타일은 전역 레지스트리로 추출되고 HTML의 <head>에 플러시된다. 이를 통해 스타일 규칙이 사용하는 콘텐츠 이전에 배치되도록 보장된다. 앞으로는 스타일을 삽입할 위치를 결정하기 위해 예정된 React 기능을 사용할 수도 있다.

  • 스트리밍 중에는 각 청크의 스타일이 수집되어 기존 스타일에 추가된다. 클라이언트 측 수화(hydration)가 완료된 후, styled-components가 기존대로 작동하고 추가적인 동적 스타일을 삽입한다.

  • 스타일 레지스트리에 대해 트리의 최상위에 클라이언트 컴포넌트를 사용하는 이유는 CSS 규칙을 이렇게 추출하는 것이 더 효율적이기 때문이다. 이렇게 하면 후속 서버 렌더링에서 스타일을 다시 생성하는 것을 피하고, 서버 컴포넌트 페이로드로 전송되는 것을 방지할 수 있다.


[ 출처 ] https://nextjs.org/docs/app/building-your-application/styling

]]> <![CDATA[스코프]]> https://velog.io/@chacha_fe/%EC%8A%A4%EC%BD%94%ED%94%84 https://velog.io/@chacha_fe/%EC%8A%A4%EC%BD%94%ED%94%84 Fri, 19 May 2023 09:54:19 GMT 스코프란?

모든 식별자(변수 이름, 함수 이름, 클래스 이름 등)는 자신이 선언된 위치에 의해 다른 코드가 식별자 자신을 참조할 수 있는 유효 범위가 결정된다. 이를 스코프라 한다. 즉, 스코프는 식별자가 유효한 범위를 말한다.


아래 예제에서 자바스크립트 엔진은 이름이 같은 두 개의 변수 중에서 어떤 변수를 참조해야 할 것인지를 결정해야 한다. 이를 식별자 결정이라 한다. 

var x = 'global';

function foo(){
    var x = 'local';
    console.log(x);
}

foo(); // 'local'

console.log(x); // 'global'

자바스크립트 엔진은 코드를 실행할 때 코드의 문맥을 고려한다.

코드가 어디서 실행되며 주변에 어떤 코드가 있는지를 렉시컬 환경이라 부른다. 즉, 코드의 문맥은 렉시컬 환경으로 이뤄진다. 이를 구현한 것이 실행 컨텍스트이며, 모든 코드는 실행 컨텍스트에서 평가되고 실행된다.


스코프의 종류

스코프는 전역과 지역으로 구분할 수 있다.

변수는 자신이 선언된 위치에 의해 자신이 유효한 범위인 스코프가 결정된다.


전역 스코프

전역이란 코드의 가장 바깥 영역을 말한다. 전역은 전역 스코프를 만든다. 전역에 변수를 선언하면 전역 스코프를 갖는 전역 변수가 된다. 전역 변수는 어디서든지 참조할 수 있다.


지역 스코프

지역이란 함수 몸체 내부를 말한다. 지역은 지역 스코프를 만든다. 지역에 변수를 선언하면 지역 스코프를 갖는 지역 변수가 된다. 지역 변수는 자신의 지역 스코프와 하위 지역 스코프에서 유효하다.


스코프 체인

함수는 중첩될 수 있으므로 함수의 지역 스코프도 중첩될 수 있다. 이는 스코프가 함수의 중첩에 의해 계층적 구조를 갖는다는 것을 의미한다.

모든 스코프는 하나의 계층적 구조로 연결되며, 모든 지역 스코프의 최상위 스코프는 전역 스코프다.

이렇게 스코프가 계층적으로 연결된 것을 스코프 체이닝이라 한다.


자바스크립트 엔진은 코드를 실행하기에 앞서 렉시컬 환경을 생성한다. 변수 선언이 실행되면 변수 식별자가 렉시컬 환경에 키로 등록되고, 변수 할당이 일어나면 렉시컬 환경의 변수 식별자에 해당하는 값을 변경한다.


스코프 체인에 의한 변수 검색

자바스크립트 엔진은 스코프 체인을 따라 변수를 참조하는 코드의 스코프에서 시작해서 상위 스코프 방향으로 이동하며 선언된 변수를 검색한다. 절대 하위 스코프로 내려가면 식별자를 검색하는 일은 없다.

상위 스코프에서 유효한 변수는 하위 스코프에서 자유롭게 참조할 수 있지만 하위 스코프에서 유효한 변수를 상위 스코프에서 참조할 수 없다.


함수 레벨 스코프

함수 레벨 스코프는 코드 블록이 아닌 함수에 의해서만 지역 스코프가 생성된다는 의미이다.


블록 레벨 스코프와의 차이

  • 블록 레벨 스코프는 모든 함수 몸체만이 아닌 모든 코드 블록이 지역 스코프를 생성한다.

  • var 키워드로 선언한 함수는 함수 레벨 스코프를 가지며 let const 키워드로 선언한 함수는 블록 레벨 스코프를 가진다.


렉시컬 스코프

아래 예제의 실행 결과는 bar 함수의 상위 스코프가 무엇인지에 따라 결정된다.

var x = 1;

function foo(){
    var x = 10;
    bar();
}

function bar(){
    console.log(x);
}

foo();
bar();
  1. 함수를 어디서 호출했는지에 따라 함수의 상위 스코프를 결정
  2. 함수를 어디서 정의했는지에 따라 함수의 상위 스코프를 결정

동적 스코프

함수가 호출되는 시점에 동적으로 상위 스코프를 결정


렉시컬 스코프

함수 정의가 평가되는 시점에 상위 스코프가 정적으로 결정


자바스크립트는 렉시컬 스코프를 따르므로 함수를 어디서 호출했는지가 아닌 함수를 어디서 정의했는지에 따라 상위 스코프를 결정한다. 함수가 호출된 위치는 상위 스코프 결정에 어떠한 영향도 주지 않는다.

자바스크립트에서 함수의 상위 스코프는 언제나 자신이 정의된 스코프다.

이처럼 함수의 상위 스코프는 함수 정의가 실행될 때 정적으로 결정된다. 함수 정의가 실행되어 생성된 함수 객체는 이렇게 결정된 상위 스코프를 기억한다. 함수가 호출될 때마다 함수의 상위 스코프를 참조할 필요가 있기 때문이다.

]]> <![CDATA[[ Data Fetching ] Server Actions]]> https://velog.io/@chacha_fe/Data-Fetching-Server-Actions https://velog.io/@chacha_fe/Data-Fetching-Server-Actions Fri, 19 May 2023 08:55:40 GMT Server Actions은 Next.js의 알파 기능으로, React Actions을 기반으로 구축되었다. 이 기능을 사용하면 서버 측 데이터 변경, 클라이언트 측 JavaScript 감소 및 점진적으로 향상된 폼을 구현할 수 있다.

import { cookies } from 'next/headers';

export default function AddToCart({ productId }) {
  async function addItem(data) {
    'use server';

    const cartId = cookies().get('cartId')?.value;
    await saveToDb({ cartId, data });
  }

  return (
    <form action={addItem}>
      <button type="submit">Add to Cart</button>
    </form>
  );
}

Server Action 규칙

Next.js 프로젝트에서 Server Actions을 사용하려면 experimental serverActions 플래그를 활성화해야 한다.

// next.config.js

module.exports = {
  experimental: {
    serverActions: true,
  },
};

생성

"use server" 지시문이 함수 본문의 맨 위에 있는 비동기 함수를 정의함으로써 Server Action을 생성할 수 있다. 이 함수는 직렬화 가능한 인수와 React Server Components 프로토콜을 기반으로 하는 직렬화 가능한 반환 값이 있어야 한다.

// app/components/component.js

async function myAction() {
  'use server';
  // ...
}

또한 파일의 최상위에 "use server" 지시문을 사용할 수도 있다. 이는 여러 개의 Server Action을 내보내는 단일 파일이 있는 경우 유용하며, Client Component에서 Server Action을 가져오는 경우에는 필수적이다.

// app/actions.js

'use server';

export async function myAction() {
  // ...
}

최상위에 "use server" 지시문을 사용할 경우, 모든 내보내기(export)는 Server Action으로 간주된다.


호출

다음 방법을 사용하여 Server Actions를 호출할 수 있다.

  • action 사용 : React의 action 속성을 사용하여 <form> 요소에서 Server Action을 호출할 수 있다.

  • formAction 사용 : React의 formAction 속성을 사용하여 <button>, <input type="submit"> 및 <input type="image"> 요소를 <form>에서 처리할 수 있다.

  • startTransition을 사용한 사용자 정의 호출 : action이나 formAction을 사용하지 않고 startTransition을 사용하여 Server Actions를 호출할 수 있다. 이 방법은 Progressive Enhancement를 비활성화한다.

1. action

React의 action 속성을 사용하여 <form> 요소에서 Server Action을 호출할 수 있다. action 속성으로 전달된 Server Actions는 사용자 상호작용에 대한 비동기적인 부작용(asynchronous side effects)으로 작동한다.


action은 HTML의 기본 action과 유사하다.

export default function AddToCart({ productId }) {
  async function addItem(data) {
    'use server';

    const cartId = cookies().get('cartId')?.value;
    await saveToDb({ cartId, data });
  }

  return (
    <form action={addItem}>
      <button type="submit">Add to Cart</button>
    </form>
  );
}

2. startTransition 을 사용한 사용자 지정 호출

action이나 formAction을 사용하지 않고도 Server Actions를 호출할 수도 있다. 이를 위해 useTransition 훅이 제공하는 startTransition을 사용할 수 있으며, 이는 form, button 또는 input 외부에서 Server Actions를 사용하고자 할 때 유용하다.


startTransition을 사용하면 Progressive Enhancement 기능이 기본적으로 비활성화된다.

// app/components/example-client-component.js

'use client';

import { useTransition } from 'react';
import { addItem } from '../actions';

function ExampleClientComponent({ id }) {
  let [isPending, startTransition] = useTransition();

  return (
    <button onClick={() => startTransition(() => addItem(id))}>
      Add To Cart
    </button>
  );
}
// app/actions.js

'use server';

export async function addItem(id) {
  await addItemToDb(id);
  revalidatePath(`/product/${id}`);
}

3. startTransition 없이 사용자 지정 호출

Server Mutations을 수행하지 않는 경우, 다른 함수와 마찬가지로 함수를 직접 prop으로 전달할 수 있다.

// app/posts/[id]/page.tsx

import kv from '@vercel/kv';
import LikeButton from './like-button';

export default function Page({ params }: { params: { id: string } }) {
  async function increment() {
    'use server';
    await kv.incr(`post:id:${params.id}`);
  }

  return <LikeButton increment={increment} />;
}
// app/post/[id]/like-button.tsx

'use client';

export default function LikeButton({
  increment,
}: {
  increment: () => Promise<void>;
}) {
  return (
    <button
      onClick={async () => {
        await increment();
      }}
    >
      Like
    </button>
  );
}

개선사항

1. 실험적인 useOptimistic

실험적인 useOptimistic 훅은 애플리케이션에서 낙관적 업데이트를 구현하는 방법을 제공한다. 낙관적 업데이트는 앱이 더 반응적으로 보이도록하여 사용자 경험을 향상시키는 기술이다.

Server Action이 호출되면 응답을 기다리지 않고 예상 결과를 반영하여 UI가 즉시 업데이트된다.

'use client';

import { experimental_useOptimistic as useOptimistic } from 'react';
import { send } from './actions.js';

export function Thread({ messages }) {
  const [optimisticMessages, addOptimisticMessage] = useOptimistic(
    messages,
    (state, newMessage) => [...state, { message: newMessage, sending: true }],
  );
  const formRef = useRef();

  return (
    <div>
      {optimisticMessages.map((m) => (
        <div>
          {m.message}
          {m.sending ? 'Sending...' : ''}
        </div>
      ))}
      <form
        action={async (formData) => {
          const message = formData.get('message');
          formRef.current.reset();
          addOptimisticMessage(message);
          await send(message);
        }}
        ref={formRef}
      >
        <input type="text" name="message" />
      </form>
    </div>
  );
}

2. 실험적인 useFormStatus

실험적인 useFormStatus 훅은 Form Action 내에서 사용할 수 있으며, pending 속성을 제공한다.

import { experimental_useFormStatus as useFormStatus } from 'react-dom';

function Submit() {
  const { pending } = useFormStatus();

  return (
    <input
      type="submit"
      className={pending ? 'button-pending' : 'button-normal'}
      disabled={pending}
    >
      Submit
    </input>
  );
}

3. 점진적 향상 ( Progressive Enhancement )

Progressive Enhancement(점진적 향상)은 JavaScript가 비활성화되었거나 JavaScript로드에 실패한 경우에도 <form>이 제대로 작동하도록 하는 기능이다. 이를 통해 JavaScript를 사용하지 않아도 사용자가 양식과 상호작용하고 데이터를 제출할 수 있다.


Server Form Actions 및 Client Form Actions 모두 Progressive Enhancement를 지원하며, 다음 두 가지 전략 중 하나를 사용한다.

  • Server Action을 직접 <form>에 전달하면 JavaScript가 비활성화되어도 양식이 상호작용 가능하다.

  • Client Action을 <form>에 전달하면 양식은 여전히 상호작용 가능하지만, 액션은 양식이 하이드레이션될 때까지 대기열에 추가된다. <form>은 선택적 하이드레이션으로 우선순위가 부여되므로 빠르게 진행된다.


'use client';

import { useState } from 'react';
import { handleSubmit } from './actions.js';

export default function ExampleClientComponent({ myAction }) {
  const [input, setInput] = useState();

  return (
    <form action={handleSubmit} onChange={(e) => setInput(e.target.value)}>
      {/* ... */}
    </form>
  );
}

두 경우 모두 하이드레이션 이전에 양식은 상호작용할 수 있다. Server Action은 클라이언트 JavaScript에 의존하지 않는 추가 이점이 있지만, 상호작용성을 희생하지 않고 필요한 경우에는 여전히 Client Action과 함께 추가 동작을 구성할 수 있다.


예시

클라이언트 컴포넌트와 함께 사용

Import

Server Actions는 Client Components 내에서 정의할 수 없지만, 가져올 수는 있다. Client Components에서 Server Actions를 사용하려면, 최상위에 "use server" 지시문이 포함된 파일에서 액션을 가져와야 한다.

// app/actions.js

'use server';

export async function addItem() {
  // ...
}
// app/components/example-client-component.js

'use client';

import { useTransition } from 'react';
import { addItem } from '../actions';

function ExampleClientComponent({ id }) {
  let [isPending, startTransition] = useTransition();

  return (
    <button onClick={() => startTransition(() => addItem(id))}>
      Add To Cart
    </button>
  );
}

Props

Server Actions을 가져오는 것이 권장되지만, 경우에 따라 Server Action을 프롭(prop)으로 Client Component에 전달하고 싶을 수도 있다.

예를 들어, 액션 내에서 동적으로 생성된 값을 사용하고자 할 때, Server Action을 프롭으로 전달하는 것이 적절한 해결책일 수 있다.

// app/components/example-server-component.js

import { ExampleClientComponent } from './components/example-client-component.js';

function ExampleServerComponent({ id }) {
  async function updateItem(data) {
    'use server';
    modifyItem({ id, data });
  }

  return <ExampleClientComponent updateItem={updateItem} />;
}
// app/components/example-client-component.js

'use client';

function ExampleClientComponent({ updateItem }) {
  async function action(formData: FormData) {
    await updateItem(formData);
  }

  return (
    <form action={action}>
      <input type="text" name="name" />
      <button type="submit">Update Item</button>
    </form>
  );
}

온디맨드 재검증(revalidation)

Server Action에 전달되는 데이터는 액션을 호출하기 전에 유효성 검사 또는 필터링될 수 있다.

예를 들어, 액션을 인자로 받아들이는 래퍼 함수를 생성하고, 유효하다면 해당 액션을 호출하는 함수를 반환하는 방식으로 구현할 수 있다.

// app/actions.js

'use server';

import { withValidate } from 'lib/form-validation';

export const action = withValidate((data) => {
  // ...
});
// lib/form-validation

export function withValidate(action) {
  return (formData: FormData) => {
    'use server';

    const isValidData = verifyData(formData);

    if (!isValidData) {
      throw new Error('Invalid input.');
    }

    const data = process(formData);
    return action(data);
  };
}

헤더 사용

서버 액션 내에서는 쿠키 및 헤더와 같은 수신 요청 헤더를 읽을 수 있다. 이를 통해 서버 액션 로직 내에서 요청 헤더에서 정보를 검색하고 활용할 수 있다.

import { cookies } from 'next/headers';

async function addItem(data) {
  'use server';

  const cartId = cookies().get('cartId')?.value;

  await saveToDb({ cartId, data });
}

또한 서버 액션 내에서 쿠키를 수정할 수 있다.

import { cookies } from 'next/headers';

async function create(data) {
  'use server';

  const cart = await createCart():
  cookies().set('cartId', cart.id)
  // or
  cookies().set({
    name: 'cartId',
    value: cart.id,
    httpOnly: true,
    path: '/'
  })
}

용어 설명

Actions

사용자 상호작용에 대한 비동기적인 부수효과를 수행하며, 오류 처리와 낙관적 업데이트에 대한 내장된 솔루션을 제공한다. HTML 기본 동작과 유사하다.

Form Actions

웹 표준 <form> API에 통합된 액션으로, 기본적인 점진적 향상과 로딩 상태를 지원한다. HTML 기본 formaction과 유사하다.

Server Functions

서버에서 실행되지만 클라이언트에서 호출할 수 있는 함수다.

Server Actions

액션으로 호출되는 서버 함수다.

Server Mutations

데이터를 변경하고 redirect, revalidatePath 또는 revalidateTag를 호출하는 서버 액션이다.


[ 출처 ] https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions

]]> <![CDATA[[ Data Fetching ] Revalidating Data]]> https://velog.io/@chacha_fe/Data-Fetching-Revalidating-Data https://velog.io/@chacha_fe/Data-Fetching-Revalidating-Data Fri, 19 May 2023 08:50:33 GMT Next.js를 사용하면 전체 사이트를 다시 빌드할 필요 없이 특정 정적 경로를 업데이트할 수 있다. 재유효화(증분적 정적 재생성으로도 알려짐)를 사용하면 정적인 이점을 유지하면서 수백만 개의 페이지로 확장할 수 있다.


Next.js에서는 두 가지 유형의 재유효화가 있다.

  • Background : 특정 시간 간격마다 데이터를 재유효화한다.

  • On-Demand : 업데이트와 같은 이벤트에 따라 데이터를 재유효화한다.


Background Revalidation

특정 간격으로 캐시된 데이터를 재유효화하려면 fetch()에서 next.revalidate 옵션을 사용하여 리소스의 캐시 유효기간을 설정할 수 있다. (초 단위)

fetch('https://...', { next: { revalidate: 60 } });

fetch를 사용하지 않고 데이터를 재유효화하려면(fetch가 아닌 외부 패키지나 쿼리 빌더 사용) 경로 세그먼트 구성을 사용할 수 있다.

// app/page.tsx

export const revalidate = 60; // revalidate this page every 60 seconds

fetch 외에도 cache를 사용하여 데이터를 재유효화할 수 있다.


작동 방식

  1. 빌드 시 정적으로 렌더링된 라우트에 대한 요청이 발생하면 초기에는 캐시된 데이터가 표시된다.

  2. 초기 요청 이후 60초 이전에 해당 라우트로의 모든 요청도 캐시되어 즉시 표시된다.

  3. 60초 윈도우 이후, 다음 요청은 여전히 캐시된(구식) 데이터를 표시한다.

  4. Next.js는 백그라운드에서 데이터 재생성을 트리거한다.

  5. 라우트가 성공적으로 생성된 후, Next.js는 캐시를 무효화하고 업데이트된 라우트를 표시한다. 백그라운드 재생성이 실패한 경우, 이전 데이터는 변경되지 않은 상태로 유지된다.


생성되지 않은 라우트 세그먼트에 대한 요청이 발생하면 Next.js는 첫 번째 요청 시 동적으로 라우트를 렌더링한다. 이후 요청은 캐시로부터 정적인 라우트 세그먼트를 제공한다.


💡 참고 사항

상위 데이터 provider에서 캐싱이 기본적으로 활성화되어 있는지 확인하라. 그렇지 않으면 (예: useCdn: false를 사용하여) 재유효화를 통해 ISR 캐시를 업데이트할 신선한 데이터를 가져올 수 없다. 캐싱은 요청되는 엔드포인트에 대해 Cache-Control 헤더를 반환할 때 CDN에서 발생할 수 있다. Vercel의 ISR은 캐시를 전역적으로 유지하고 롤백을 처리한다.


On-demand Revalidation

60으로 재유효화 시간을 설정하면 모든 방문자는 사이트의 동일한 생성된 버전을 1분 동안 볼 수 있다. 캐시를 무효화하는 유일한 방법은 1분이 지난 후에 페이지를 방문하는 경우다.

Next.js 앱 라우터는 라우트나 캐시 태그를 기반으로 컨텐츠를 필요에 따라 재유효화하는 기능을 지원한다. 이를 통해 특정 fetch에 대한 Next.js 캐시를 수동으로 지울 수 있어서 다음과 같은 경우 사이트를 업데이트하기가 더욱 쉬워진다.

  • 헤드리스 CMS에서 컨텐츠가 생성되거나 업데이트되는 경우
  • 전자상거래 메타데이터가 변경되는 경우(가격, 설명, 카테고리, 리뷰 등)

온디맨드 재유효화 사용

데이터는 경로(revalidatePath) 또는 캐시 태그(revalidateTag)별로 온디맨드로 재유효화될 수 있다.

예를 들어, 다음과 같은 fetch에서는 캐시 태그 collection을 추가한다.

// app/page.tsx

export default async function Page() {
  const res = await fetch('https://...', { next: { tags: ['collection'] } });
  const data = await res.json();
  // ...
}

이 캐시된 데이터는 Route Handler에서 revalidateTag를 호출하여 필요에 따라 온디맨드로 재유효화될 수 있다.

// app/api/revalidate/route.ts

import { NextRequest, NextResponse } from 'next/server';
import { revalidateTag } from 'next/cache';

export async function GET(request: NextRequest) {
  const tag = request.nextUrl.searchParams.get('tag');
  revalidateTag(tag);
  return NextResponse.json({ revalidated: true, now: Date.now() });
}

Error Handling and Revalidation

데이터 재유효화 시도 중 오류가 발생하면 마지막으로 성공적으로 생성된 데이터가 캐시로부터 계속 제공된다. 다음 요청에서 Next.js는 데이터를 다시 재유효화하기 위해 재시도한다.


[ 출처 ] https://nextjs.org/docs/app/building-your-application/data-fetching/revalidating

]]>