[공식문서 번역] Composition Pattern

컴포지트 패턴?

---

컴포지트 패턴은 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴으로, 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 한다

• 원래는 객체지향에서 사용되던 패턴인듯하다
• 이걸 어떻게 NextJS에서 사용하게 될지, 공식문서를 정리해보았다

 

Server and Client Composition Patterns

---

서버와 클라이언트의 컴포지트 패턴

리액트 애플리케이션을 만들 때, 애플리케이션에서 어떤 부분이 서버에서 렌더되어야 하는지 또는 클라이언트에서 렌더되어야 하는지를 고려할 필요가 있다.
이 페이지는 서버 컴포넌트와 클라이언트 컴포넌트를 사용할 때 추천되는 컴포지션 패턴을 다룬다.

 

When to use Server and Client Components?

---

언제 서버 컴포넌트를 사용하고 클라이언트 컴포넌트를 사용하는지?

다음은 서버 컴포넌트와 클라이언트 컴포넌트를 사용해야 하는 경우에 대한 간단한 정리이다.

 

Server Component Patterns

---

서버 컴포넌트 패턴

클라이언트 사이드 렌더링을 취하기 전에, 데이터를 불러오거나, 데이터베이스 또는 백엔드 서비스에 접근하는 것과 같은 작업들을 서버에서 하기를 원할지도 모른다.

아래는 서버 컴포넌트와 함께 사용될 수 있는 일반적인 패턴들이다.

 

Sharing data between components

---

컴포넌트간에 데이터 공유하기

서버에서 데이터를 불러올 때, 다른 컴포넌트들과 데이터를 공유해야 하는 상황이 있을 수 있다.
예를 들어, 같은 데이터에 의존하는 레이아웃과 페이지가 있을 수 있다.

React Context(이것은 서버에서 사용이 불가능하다)를 사용하거나, 데이터를 Props로 넘겨주는 것 대신에 fetch 또는 리액트의 cache 함수를 사용해서 동일한 데이터를 필요로 하는 컴포넌트에서 데이터를 요청할 수 있다.

이때, 동일한 데이터에 대한 반복되는 요청이 발생하는 것을 걱정할 필요가 없다.
이것은 리액트가 fetch가 자동으로 데이터 요청을 저장하도록 했기 때문이다.
그리고 cache함수는 fetch를 사용할 수 없을 때 사용하면 된다.

더 많은 정보를 위해서는 리액트의 memoization 부분을 참고해라.

 

Keeping Server-only Code out of the Client Environment

---

클라이언트 환경에서도 서버에서만 사용되는 코드를 유지하기

JavaScript 모듈은 서버 컴포넌트와 클라이언트 컴포넌트 모두에서 공유되기 때문에, 서버에서만 동작하기를 바랬던 코드가 클라이언트로 넘어가버릴 수 있다.

예를 들어, 다음의 data-fetching 함수를 보자:

export async function getData() {
  const res = await fetch('https://external-service.com/data', {
    headers: {
      authorization: process.env.API_KEY,
    },
  })

  return res.json()
}

처음 봤을 때는 getData가 서버와 클라이언트 모두에서 동작할 것처럼 보인다.
그러나 이 함수는 API_KEY를 사용한다. 그리고 이것은 서버에서만 작동하도록 의도했다는 것을 의미한다.

환경 변수 API_KEY앞에 NEXT_PUBLIC이라는 접두사가 없기 때문에, 그것은 서버에서만 접근이 가능하다.
당신의 환경 변수가 클라이언트로 새어나가는 것을 방지하기 위해, NextJS는 환경 변수를 빈 문자열로 변환한다.

그 결과, getData()가 클라이언트측에서 import되고 실행될 수는 있지만, 원하는대로 동작하지 않을 것이다.
변수를 public으로 바꾸는 것은 함수가 클라언트에서 동작하도록 할 수 있겠지만, 민감한 정보를 클라이언트측에 노출되는 것을 원하지는 않을 것이다.

이렇게 의도치않게 클라이언트에서 서버 코드를 사용하는 것을 막기 위해 우리는 server-only 패키지를 사용할 수 있다.
이 패키지는 다른 개발자들이 우연히 이러한 모듈을 클라이언트 컴포넌트에서 import할 경우에 빌드 타임에 에러를 발생시킬 것이다.

server-only패키지를 사용하기 위해서 먼저 패키지를 설치해야 한다

npm install server-only

 

그런 다음 server-only 코드로 지정하고 싶은 곳에 패키지를 import하면 된다:

import 'server-only'

export async function getData() {
  const res = await fetch('https://external-service.com/data', {
    headers: {
      authorization: process.env.API_KEY,
    },
  })

  return res.json()
}

이제 getData()를 import하는 클라이언트 컴포넌트는 "이 모듈은 서버에서만 사용될 수 있습니다"라는 내용의 빌드 타임 에러를 받을 것이다.

유사한 패키지인 client-only는 클라이언트에서만 사용되어야 하는 코드를 포함한 모듈에 사용할 수 있다.
예를 들어, window객체에 접근하는 코드를 포함하는 모듈이 있다. (window객체는 브라우저에서 제공하는 정보로 클라이언트측 객체이다)

 

Using Third-party Packages and Providers

---

서드 파티 패키지와 프로바이더 사용하기

서버 컴포넌트는 리액트의 새로운 기술이기 때문에, 기존 생태계의 서드 파티 패키지들과 프로바이더들은 useState, useEffect, createContext와 같은 클라이언트측에서만 사용되는 기술들을 사용하는 컴포넌트에 이제 막 "use client"를 붙이기 시작했다.

오늘날, client-only를 사용하는 npm패키지의 많은 컴포넌트들은 "use client"를 아직 붙이지 않았다.
그러한 서드 파티 컴포넌트들은 "use client"가 선언된 클라이언트 컴포넌트에서는 잘 동작할 것이다. 그러나 서버 컴포넌트에서는 잘 동작하지 않을 것이다.

예를 들어, <Carousel /> 컴포넌트가 포함된 가상의 acme-carousel패키지를 설치했다고 해보자.
이 컴포넌트는 useState를 사용하지만 아직 "use client"는 선언하지 않았다.

만약 클라이언트 컴포넌트에서 <Carousel />를 사용하면, 원하는대로 동작할 것이다:

'use client'

import { useState } from 'react'
import { Carousel } from 'acme-carousel'

export default function Gallery() {
  let [isOpen, setIsOpen] = useState(false)

  return (
    <div>
      <button onClick={() => setIsOpen(true)}>View pictures</button>

      {/* Works, since Carousel is used within a Client Component */}
      {isOpen && <Carousel />}
    </div>
  )
}

그러나 서버 컴포넌트에서 곧바로 사용하고자 한다면 에러가 발생할 것이다:

import { Carousel } from 'acme-carousel'

export default function Page() {
  return (
    <div>
      <p>View pictures</p>

      {/* Error: `useState` can not be used within Server Components */}
      <Carousel />
    </div>
  )
}

이것은 Next가 <Carousel />이 클라이언트에서만 사용할 수 있는 기술들을 사용하는지 모르기 때문이다.

이것을 해결하기 위해서, 본인만의 클라이언트 컴포넌트를 만들어서 서드 파티 컴포넌트를 감쌀 수 있다:

'use client'

import { Carousel } from 'acme-carousel'

export default Carousel

이제, 서버 컴포넌트에서 <Carousel />을 바로 사용할 수 있다:

import Carousel from './carousel'

export default function Page() {
  return (
    <div>
      <p>View pictures</p>

      {/*  Works, since Carousel is a Client Component */}
      <Carousel />
    </div>
  )
}

대부분의 경우에는 서드 파티 컴포넌트를 클라이언트 컴포넌트 안에서 사용할 것이기 때문에 그렇게 감싸지 않아도 될 것이다.
그러나 문제는 프로바이더이다. 그들은 React 상태와 컨텍스트에 의존하고, 일반적으로 애플리케이션의 Root에서 사용되기 때문이다.

 

Using Context Providers

---

Context Providers 사용하기

컨텍스트 프로바이더들은 현재 테마와 같은 전역적인 관심사를 공유하기 위해서 일반적으로 애플리케이션의 Root 근처에서 렌더된다.
React Context는 서버 컴포넌트에서 지원되지 않기 때문에, 애플리케이션의 Root에서 컨텍스트를 생성하려고 하면 에러가 발생할 것이다:

import { createContext } from 'react'

//  createContext is not supported in Server Components
export const ThemeContext = createContext({})

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        <ThemeContext.Provider value="dark">{children}</ThemeContext.Provider>
      </body>
    </html>
  )
}

이것을 해결하기 위해서 클라이언트 컴포넌트 안에서 컨텍스트를 생성하고 프로바이더를 렌더할 수 있다:

'use client'

import { createContext } from 'react'

export const ThemeContext = createContext({})

export default function ThemeProvider({
  children,
}: {
  children: React.ReactNode
}) {
  return <ThemeContext.Provider value="dark">{children}</ThemeContext.Provider>
}

그것은 클라이언트 컴포넌트로 마크가 되었기 때문에 서버 컴포넌트는 이제 프로바이더를 렌더할 수 있다:

import ThemeProvider from './theme-provider'

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

Root에서 렌더된 프로바이더 덕분에, 앱 내의 모든 클라이언트 컴포넌트들은 이 Context를 사용할 수 있게 되었다.

알면 좋은 것

프로바이더는 트리에서 최대한 깊은 곳에서 렌더를 해야 한다.
왜 ThemeProvider가 전체 <html>을 감싸는 것이 아니라 {children}만 감쌌을까.
이것은 Next가 서버 커모넌트의 정적인 부분을 최적화하는 것을 쉽게 해준다.

 

Advice for Library Authors

---

라이브러리 제작자에게 전하는 조언

유사하게, 다른 개발자들이 사용할 패키지를 만드는 라이브러리 제작자들은 "use client"를 클라이언트 진입점에 표시할 수 있다.
이것은 패키지 사용자들이 패키지 컴포넌트를 감싸지 않고도 바로 서버 컴포넌트에서 사용할 수 있도록 해준다.

"use cleint"를 트리의 더 깊은 곳에서 사용함으로써 패키지를 최적화할 수 있다.
이렇게 함으로써 가져온 모듈들이 서버 컴포넌트 모듈 그래프의 일부가 되도록 할 수 있다.

 

Client Components

---

클라이언트 컴포넌트

 

Moving Client Components Down the Tree

---

클라이언트 컴포넌트를 트리 아래쪽으로 보내기

클라이언트측의 JavaScript 번들의 크기를 줄이기 위해서, 클라이언트 컴포넌트를 컴포넌트 트리의 하단으로 이동시키는 것을 추천한다.

예를 들어, 정적인 요소들(로고, 링크 등)을 포함하는 레이아웃과 state를 사용하는 상호작용하는 검색바가 있다고 해보자.

전체 레이아웃을 클라이언트 컴포넌트로 만들기보다는, 상호작용을 하는 로직을 클라이언트 컴포넌트(예: <SearchBar />)에 넣어서 레이아웃을 서버 컴포넌트로 유지할 수 있다.
이것은 레이아웃에서 사용되는 JavaScript를 클라이언트로 보낼 필요가 없다는 것을 의미한다.
(레이아웃은 서버에서 렌더될 것이기 때문에)

// SearchBar is a Client Component
import SearchBar from './searchbar'
// Logo is a Server Component
import Logo from './logo'

// Layout is a Server Component by default
export default function Layout({ children }: { children: React.ReactNode }) {
  return (
    <>
      <nav>
        <Logo />
        <SearchBar />
      </nav>
      <main>{children}</main>
    </>
  )
}

 

Passing props from Server to Client Components (Serialization)

---

서버 컴포넌트에서 클라이언트 컴포넌트로 Props 전달하기 (Serialization)

서버 컴포넌트에서 데이터를 요청한 다음에 데이터를 클라이언트 컴포넌트에 Props로 넘겨주고 싶을 수도 있다.
서버 컴포넌트에서 클라이언트 컴포넌트로 전달되는 Props들은 리액트에 의해 serializable 해야 한다.

만약 클라이언트 컴포넌트가 의존하는 데이터가 serializable하지 않다면, 서드 파티 라이브러리를 사용해서 데이터를 클라이언트측에서 불러오거나 또는 Route Handler를 통해서 서버에서 요청할 수 있다.

 

Interleaving Server and Client Components

---

서버 컴포넌트와 클라이언트 컴포넌트 번갈아 사용하기

클라이언트 컴포넌트와 서버 컴포넌트를 번갈아 사용할 때, UI를 컴포넌트 트리로 시각화하는 것이 도움이 될 것이다.
서버 컴포넌트인 Root 레이아웃부터 시작해서 컴포넌트 트리의 특정 서브트리는 "use client"를 추가함으로써 클라이언트에서 렌더할 수 있다.

그러한 클라이언트 서브트리 안에서도 여전히 서버 컴포넌트를 중첩하거나 서버 액션들을 호출할 수 있다.
그러나 몇가지 명심해야 할 것들이 있다.

• 요청-응답 생명주기 동안에, 코드는 서버와 클라이언트를 오갈 수 있다. 만약 클라이언트에서 서버에 있는 데이터와 자원에 접근해야 한다면 서버에 새로운 요청을 보내게 된다 - 서버와 클라이언트간에 왔다갔다 하는 것이 아니다.
• 서버에 새로운 요청을 보내게 되면, 내부에 중첩된 클라이언트 컴포넌트를 포함해서 모든 서버 컴포넌트가 먼저 렌더된다. 렌더된 결과(RSC Payload)는 클라이언트 컴포넌트들의 위치에 대한 참조도 포함한다. 그런 다음 클라리언트 측에서 리액트는 RSC Payload를 사용해서 서버 컴포넌트와 클라이언트 컴포넌트를 하나의 트리로 합친다.
• 클라이언트 컴포넌트는 서버 컴포넌트 다음으로 렌더되기 때문에, 클라이언트 컴포넌트 모듈 내에서 서버 컴포넌트를 불러올 수 없다 (새로운 요청을 또 다시 서버로 보내게 될 것이기 때문에). 대신 서버 컴포넌트를 클라이언트 컴포넌트에 Props로 전달할 수 있다. 아래의 지원하지 않는 패턴과 지원하는 패턴 부분을 보면 된다.

 

Unsupported Pattern: Importing Server Components into Client Components

---

지원하지 않는 패턴: 서버 컴포넌트를 클라이언트 컴포넌트에서 불러오기

다음의 패턴은 지원하지 않는 패턴이다. 서버 컴포넌트를 클라이언트 컴포넌트 안에서 불러올 수 없다:

'use client'

// You cannot import a Server Component into a Client Component.
import ServerComponent from './Server-Component'

export default function ClientComponent({
  children,
}: {
  children: React.ReactNode
}) {
  const [count, setCount] = useState(0)

  return (
    <>
      <button onClick={() => setCount(count + 1)}>{count}</button>

      <ServerComponent />
    </>
  )
}

 

Supported Pattern: Passing Server Components to Client Components as Props

---

지원하는 패턴: 서버 컴포넌트를 클라이언트 컴포넌트에 Props로 전달하기

다음의 패턴은 지원한다. 서버 컴포넌트를 클라이언트 컴포넌트에 Props로 전달할 수 있다.

일반적으로 사용되는 패턴은 리액트의 children prop을 사용해서 클라이언트 컴포넌트에 "슬롯"을 만드는 것이다.

아래의 예시에서, <ClientComponent />는 children prop을 허용한다:

'use client'

import { useState } from 'react'

export default function ClientComponent({
  children,
}: {
  children: React.ReactNode
}) {
  const [count, setCount] = useState(0)

  return (
    <>
      <button onClick={() => setCount(count + 1)}>{count}</button>
      {children}
    </>
  )
}

<ClientComponent />는 children이 결과적으로 서버 컴포넌트로 채워질 것이란 걸 모른다.
그렇기 때문에 <ClientComponent />는 어디에 children을 렌더할 것인지 결정하는 것에 대한 책임만을 갖는다.

상위 서버 컴포넌트에서 <ClientComponent />와 <ServerComponent /> 모두를 불러와서, <ServerComponent />를 <ClientComponent />의 자식으로 전달할 수 있다:

// This pattern works:
// You can pass a Server Component as a child or prop of a
// Client Component.
import ClientComponent from './client-component'
import ServerComponent from './server-component'

// Pages in Next.js are Server Components by default
export default function Page() {
  return (
    <ClientComponent>
      <ServerComponent />
    </ClientComponent>
  )
}

이러한 접근으로, <ClientComponent />와 <ServerCompmonent />는 분리되어 독립적으로 렌더될 수 있다.
이 경우에서 <ServerCompmonent />는 <ClientComponent />가 클라이언트측에서 렌더되기 전에 서버에서 미리 렌더될 수 있다.

알면 좋은 것
- "lifting content up" 패턴은 부모 컴포넌트가 리렌더될 때 자식 컴포넌트도 리렌더되는 것을 방지하기 위해서 사용된다.
- children prop만 사용해야 하는 것은 아니다. JSX를 전달하기 위해 어떤 prop을 사용하든 무관하다.

 

Reference

---

컴포지트 패턴 - 위키백과, 우리 모두의 백과사전

Rendering: Composition Patterns | Next.js

'use server' directive – React