상태 관리를 통해 React Hook Form과 유사한 인터페이스의 훅 만들기 🚀

React Hook Form과 유사한 인터페이스 만들기


드롭다운 메뉴는 웹 애플리케이션에서 흔히 볼 수 있는 UI다. 누구나 한 번쯤 만들어 본 경험이 있을 것이다. 만드는 것도 크게 어렵지 않다. 내가 부트캠프를 하면서 사용했던 드롭다운 메뉴는 재사용성과 확장성이 떨어져, 남의 코드에 if문이 덕지덕지 붙거나 다시 만든 경험이 있었다. 프론트엔드를 배운 대부분의 사람은 이를 구현할 수 있다. 하지만 구현에만 초점을 둔 것과 확장성과 유연성을 고려한 것과는 시간이 지남에 따라 큰 차이가 나타난다. 왜냐하면 처음부터 완벽한게 만들 수 없기 때문에 기능을 수정하거나 추가할 때 구조가 제 역할을 하지 못할 가능성이 커진다. 결국 복잡성이 증가하면서 코드를 이해하고 해석하는 데 더 많은 시간이 소요되게 된다. 따라서, 구현에만 초점을 둔 초안을 바탕으로 점진적으로 어떻게 개선하는지에 대한 나의 방법을 공유하겠다.

## 알아두면 좋은 것.

우선, 만들기 전에 용어 정리를 할 필요가 있다. 바로 Dropdown Menu와 Select의 차이다. 둘 다 비슷한 UI지만 서로 다른 성격을 띤다. 우리는 디자이너와 소통도 해야 하고, 명칭을 제대로 알아야 올바른 요구사항을 만들 수 있다.

- **Dropdown Menu**: 메뉴의 항목을 클릭했을 때 특정 동작(페이지 이동, 특정 기능)을 수행하거나 중첩된 하위 메뉴들을 보여주는 특징이 있다.
- **Select**: HTML의 select 태그를 생각하면 된다. 즉, Form에서 사용자에게 입력 받기 위해 여러 옵션을 제공하여 선택하게 하는 하나의 입력 요소를 말한다.

즉, 서로 비슷한 UI이지만, 달성하려는 목적이 다르기 때문에 요구사항 또한 다르다. 실제로 나도 드롭다운 메뉴와 셀렉트를 동시에 사용하려다 보니 코드가 많이 지저분해졌던 경험이 있었다.

## 드롭다운 만들기

### 요구사항 정의하기

드롭다운 메뉴를 닫힌 상태와 열린 상태로 정의해 보았다.

#### 메뉴가 닫혀있는 상태

- Dropdown 버튼을 클릭하면 메뉴가 나타난다.

#### 메뉴가 열려있는 상태

- Dropdown 버튼을 클릭하면 메뉴를 닫을 수 있다.
- 하위 메뉴를 클릭하면 특정 동작이 수행되고, 메뉴는 닫혀야 한다.
- Dropdown 바깥을 클릭했을 때 메뉴는 닫혀야 한다.
- 중첩된 메뉴를 가진 하위 메뉴에 마우스를 올리면 중첩된 메뉴가 보여야 한다.

### 일반적으로 구현하는 드롭다운의 형태

구현에 집중하다 보면 다음과 같은 형태로 만들곤 한다. 구글에 검색해보면 비슷한 방식으로 만든 포스트들이 있다.

```tsx
import { FaAngleDown } from "react-icons/fa6"
import useToggle from "../hooks/useToggle"
import useOutSideClick from "../hooks/useOutSideClick"

export default function Dropdown() {
  const { handleToggle, handleCloseToggle, isToggle } = useToggle()
  const dropdownRef = useOutSideClick<HTMLDivElement>({ onCloseToggle: handleCloseToggle })

  return (
    <div className="relative text-white" ref={dropdownRef}>
      <button
        className="px-3 py-3 bg-gray-800 rounded-lg flex justify-between items-center gap-6"
        onClick={handleToggle}
      >
        드롭다운
        <div>
          <FaAngleDown className={isToggle ? `rotate-180` : `rotate-0`} />
        </div>
      </button>
      {isToggle && (
        <ul className="absolute top-full translate-y-1 bg-gray-800 rounded-lg text-sm w-full p-1 gap-1.5">
          <li className="dropdown-menu-item">
            <button className="w-full p-2">특정 기능</button>
          </li>
          <li className="hover:bg-gray-700 rounded-md relative group">
            <div className="w-full p-2">중첩 메뉴 기능</div>
            <ul className="hidden absolute w-[150px] group-hover:block bg-gray-800 rounded-lg translate-x-full top-0 right-4 p-1 gap-1.5">
              <li className="dropdown-menu-item">
                <button className="w-full p-2">중첩 메뉴 1</button>
              </li>
              <li className="dropdown-menu-item">
                <button className="w-full p-2">중첩 메뉴 2</button>
              </li>
              <li className="dropdown-menu-item">
                <button className="w-full p-2">중첩 메뉴 3</button>
              </li>
            </ul>
          </li>
          <li className="dropdown-menu-item">
            <button className="w-full p-2">페이지 이동 기능</button>
          </li>
        </ul>
      )}
    </div>
  )
}
```

### 문제점

위 코드는 다음과 같은 문제가 있다.

- 재사용이 불가능하고, 유지보수 측면에서 UI가 변경될 때마다 모든 파일을 수정해야 한다.
- 기존 코드에서 수정을 해야 하므로 확장성이 떨어진다. OCP(개방 폐쇄 원칙) 위반
- 일관성이 깨지고, 코드를 해석하는 데 시간이 많이 소요된다.
- 사용할 때마다 필요한 훅을 매번 불러와야 한다.

구현에만 집중할 경우 위와 같이 만드는 경우가 생각보다 흔하며, 훅으로 로직을 분리하지 않는 경우도 많다. 재사용성이 떨어지면 중복된 코드가 많아질 확률이 높아진다. 즉 클라이언트 리소스가 그만큼 소모된다는 말이다. 또한, 확장에 열려있어야하고 수정에 대해서는 폐쇄적이여야 한다는 OCP 원칙에 위반되기도 한다.

이 문제를 해결하기 위해 드롭다운 메뉴를 컴포넌트로 분리하고, 리스트를 props로 전달받는 경우도 있다.(추상화가 어떻게 되냐에 따라 좋은 접근이 될 수 있다) 하지만 드롭다운 메뉴는 버튼만으로 동작하는 것이 아니다. `<Link />` 컴포넌트로도 동작할 수 있다. 물론 Router 메서드를 사용할 수 있지만, map을 사용해 렌더링할 때 분기 처리가 필요하기 때문에 가독성 면에서 좋지 않다고 느낀다.

### 어떻게 개선할 수 있을까 ?

개선을 하기 전에 컴포넌트 설계를 다시 해봐야 한다. 경험이 부족하다면 코드를 개선하는 것이 쉽지 않기 때문에, 구현에 앞서 충분한 구상과 다양한 방법을 시도하는 것이 중요하다. 이 문제는 다음과 같은 방식으로 해결할 수 있다.

- 재사용성을 높이기 위해 단일 책임 원칙을 지키고, 컴포넌트를 세부적으로 쪼갠다.
- 세부적으로 쪼갠 컴포넌트를 합성해서 사용하면 재사용성, 확장성, 그리고 유연성을 향상시킬 수 있다.
- 반복해서 호출해야 하는 훅들은 Context API를 사용해 지역적으로 관리할 수 있다.

드롭다운 메뉴, 드롭다운 메뉴 버튼, 드롭다운 메뉴 리스트, 드롭다운 메뉴 리스트 아이템 등으로 컴포넌트를 분리하면 각 컴포넌트가 단일 책임 원칙을 따르며 하나의 역할만 수행하게 되어, 재사용성이 크게 향상된다. 반복적으로 호출되는 훅을 Context API 대신 React.cloneElement를 사용해 children props를 병합할 수 있다. 그러나 드롭다운 메뉴의 개수가 고정되지 않고, 특정 기능이 props로 전달되어 사용될 수 있기 때문에 복잡성이 증가할 수 있다.

### 라이브러리 분석을 해야하는 이유

스스로 문제를 해결하는 것도 중요하지만, 이미 이러한 문제를 경험한 개발자들이 많다는 점을 기억해야 한다. 바로 라이브러리를 만든 사람들이다. 라이브러리를 만든 사람들은 다양한 요구사항에 대응하며 작업한다. 유명한 라이브러리는 사용하기 쉽고 유연하며 확장성이 뛰어나다. 즉, 우리는 라이브러리의 소스 코드를 분석함으로써 많은 통찰을 얻을 수 있다. Radix UI의 DropdownMenu 소스 코드를 살펴보자.

```tsx
<DropdownMenu.Root>
  <DropdownMenu.Trigger>
    <Button variant="soft">
      Options
      <DropdownMenu.TriggerIcon />
    </Button>
  </DropdownMenu.Trigger>
  <DropdownMenu.Content>
    <DropdownMenu.Item shortcut="⌘ E">Edit</DropdownMenu.Item>
    <DropdownMenu.Item shortcut="⌘ D">Duplicate</DropdownMenu.Item>
    <DropdownMenu.Separator />
    <DropdownMenu.Item shortcut="⌘ N">Archive</DropdownMenu.Item>

    <DropdownMenu.Sub>
      <DropdownMenu.SubTrigger>More</DropdownMenu.SubTrigger>
      <DropdownMenu.SubContent>
        <DropdownMenu.Item>Move to project…</DropdownMenu.Item>
        <DropdownMenu.Item>Move to folder…</DropdownMenu.Item>
        <DropdownMenu.Separator />
        <DropdownMenu.Item>Advanced options…</DropdownMenu.Item>
      </DropdownMenu.SubContent>
    </DropdownMenu.Sub>

    <DropdownMenu.Separator />
    <DropdownMenu.Item>Share</DropdownMenu.Item>
    <DropdownMenu.Item>Add to favorites</DropdownMenu.Item>
    <DropdownMenu.Separator />
    <DropdownMenu.Item shortcut="⌘ ⌫" color="red">
      Delete
    </DropdownMenu.Item>
  </DropdownMenu.Content>
</DropdownMenu.Root>
```

코드를 보면 합성 컴포넌트(Compound Pattern)을 사용한 것을 확인할 수 있다. 합성 컴포넌트를 사용하면 다음과 같은 이점이 있다.

- 유연한 UI 구조
- 재사용성
- 관심사 분리(상태와 UI 분리)

위 코드는 훅을 별도로 호출하지 않는다. 내부적으로 상태를 공유하고 있어, 드롭다운 기능이 하나의 일관된 단위처럼 느껴진다. 합성 컴포넌트를 사용하면 props를 효율적으로 분산시킬 수 있으며, 각 컴포넌트가 본연의 역할만 수행하게 되어 재사용성과 유연성이 높아지고, 확장성 또한 향상된다.

현재 우리가 만든 코드를 합성 컴포넌트를 사용해 만든다면, 재사용 가능하고 유연한 컴포넌트를 구현할 수 있게 된다. 똑같진 않지만 유사한 방식으로 만들어보자.

### 초안을 Compound Pattern으로 바꿔보자.

기존에 만들었던 초안을 바탕으로 Compound Pattern을 적용하면 Radix UI처럼 유사하게 만들 수 있다. 네이밍은 Radix UI를 그대로 따랐으며, 내부 상태 관리는 Context API를 사용했다.

> [Compound Pattern에 대해 알고싶다면 여기를 클릭하세요!](https://d5ng-blog.vercel.app/React/compound-pattern)

```tsx
// ui/DropdownMenu.tsx
import { createContext, ReactNode, useContext } from "react"
import { FaAngleDown } from "react-icons/fa6"
import useToggle from "../hooks/useToggle"
import useOutSideClick from "../hooks/useOutSideClick"

export interface ChildrenProps {
  children: ReactNode
}

export type DropdownMenuContextType = {
  isOpen: boolean
  toggle: () => void
  close: () => void
}

export const DropdownMenuContext = createContext<DropdownMenuContextType>({
  isOpen: false,
  toggle: () => {},
  close: () => {},
})

function useDropdownMenu() {
  const ctx = useContext(DropdownMenuContext)
  if (!ctx) throw new Error("Dropdown Menu에서 사용해주세요.")
  return ctx
}

export default function DropdownMenu({ children }: ChildrenProps) {
  const toggleState = useToggle()
  const dropdownRef = useOutSideClick<HTMLDivElement>({ callback: toggleState.close })

  return (
    <DropdownMenuContext.Provider value={toggleState}>
      <div className="relative text-white" ref={dropdownRef}>
        {children}
      </div>
    </DropdownMenuContext.Provider>
  )
}

function DropdownMenuTrigger({ children }: ChildrenProps) {
  const { toggle } = useDropdownMenu()
  return (
    <button className="px-3 py-3 bg-gray-800 rounded-lg flex justify-between items-center gap-6" onClick={toggle}>
      {children}
    </button>
  )
}

function DropdownMenuTriggerIcon() {
  const { isOpen } = useDropdownMenu()
  return (
    <div>
      <FaAngleDown className={isOpen ? `rotate-180` : `rotate-0`} />
    </div>
  )
}

function DropdownMenuContent({ children }: ChildrenProps) {
  const { isOpen } = useDropdownMenu()
  if (!isOpen) return null
  return (
    <ul className="absolute top-full translate-y-1 bg-gray-800 rounded-lg text-sm w-full p-1 gap-1.5">{children}</ul>
  )
}

function DropdownMenuItem({ children }: ChildrenProps) {
  return <li className="dropdown-menu-item w-full p-2">{children}</li>
}

function DropdownMenuSub({ children }: ChildrenProps) {
  return <li className="hover:bg-gray-700 rounded-md relative group">{children}</li>
}

function DropdownMenuSubTrigger({ children }: ChildrenProps) {
  return <div className="w-full p-2">{children}</div>
}

function DropdownMenuSubContent({ children }: ChildrenProps) {
  return (
    <ul className="hidden absolute w-[150px] group-hover:block bg-gray-800 rounded-lg translate-x-full top-0 right-4 p-1 gap-1.5">
      {children}
    </ul>
  )
}

DropdownMenu.Root = DropdownMenu
DropdownMenu.Trigger = DropdownMenuTrigger
DropdownMenu.Content = DropdownMenuContent
DropdownMenu.Item = DropdownMenuItem
DropdownMenu.TriggerIcon = DropdownMenuTriggerIcon
// Sub
DropdownMenu.Sub = DropdownMenuSub
DropdownMenu.SubTrigger = DropdownMenuSubTrigger
DropdownMenu.SubContent = DropdownMenuSubContent
```

```tsx
// components/Dropdown.tsx
import DropdownMenu from "@/ui/DropdownMenu.tsx"
export default function Dropdown() {
  return (
    <DropdownMenu.Root>
      <DropdownMenu.Trigger>
        드롭다운
        <DropdownMenu.TriggerIcon />
      </DropdownMenu.Trigger>
      <DropdownMenu.Content>
        <DropdownMenu.Item>특정 기능</DropdownMenu.Item>
        <DropdownMenu.Sub>
          <DropdownMenu.SubTrigger>중첩 메뉴 기능</DropdownMenu.SubTrigger>
          <DropdownMenu.SubContent>
            <DropdownMenu.Item>중첩 메뉴 기능1</DropdownMenu.Item>
            <DropdownMenu.Item>중첩 메뉴 기능2</DropdownMenu.Item>
            <DropdownMenu.Item>중첩 메뉴 기능3</DropdownMenu.Item>
          </DropdownMenu.SubContent>
        </DropdownMenu.Sub>
        <DropdownMenu.Item>페이지 이동 기능</DropdownMenu.Item>
      </DropdownMenu.Content>
    </DropdownMenu.Root>
  )
}
```

각 컴포넌트를 세분화하여 단일 책임 원칙을 적용한 덕분에 재사용성이 크게 향상되었고, 중복을 줄여 DRY 원칙을 지키게 되었다. 또한, 새로운 요구사항이 들어와도 기존 컴포넌트를 수정하지 않고 추가할 수 있어 확장성이 보장되며, 요구사항이 변화할 때도 쉽게 수정할 수 있어 유연성도 확보되었다. 초안에 비해 훨씬 안정적인 컴포넌트로 개선되었다.

### Compound Pattern을 사용할 때 주의할 점

현재 코드에서는 모든 컴포넌트를 한 번에 import하는 방식으로, 사용하지 않는 드롭다운 컴포넌트들도 함께 불러오는 문제가 있다. Radix UI를 기반으로 한 Shadcn UI는 필요한 컴포넌트만 개별적으로 import하여 불필요한 코드가 포함되지 않으며, 이로 인해 성능이 더욱 유리하게 최적화되어 있다. 따라서 현재 코드를 각 컴포넌트별로 import할 수 있도록 수정하면, 필요한 컴포넌트만 불러와 파일 크기를 줄이고 성능을 개선할 수 있다.

### 오해하면 안되는 부분

여기서 오해하지 말아야 할 점이 있다. 위 코드는 컴포넌트의 형태를 UI 라이브러리와 비슷하게 구현한 것이지, Radix UI처럼 완전히 구현한 것은 아니다. 개선된 코드를 살펴보면, `<DropdownMenuTrigger />` 컴포넌트 내부에 버튼이 포함되어 있다. 하지만 버튼은 중첩될 수 없기 때문에, 버튼 태그를 포함한 컴포넌트를 사용할 수 없는 문제가 발생한다. Radix UI는 **Render Delegation** 기법을 사용해 이 문제를 해결하고 있다.

```tsx
// Radix UI의 특징
// Trigger에는 button이 내장되어 있지만 asChild를 사용하여 아래 버튼과 병합하고. Trigger에 기본 상태인 드롭다운의 메뉴를 열고, 닫는 상태들을 포함하고 있다.
<DropdownMenuTrigger asChild>
  <Button variant="outline">Open</Button>
</DropdownMenuTrigger>
```

> Render Delegation은 컴포넌트가 자신이 직접 UI를 렌더링하는 대신, 렌더링을 다른 컴포넌트나 함수로 위임하는 패턴입니다. 이 패턴은 코드의 재사용성을 높이고, 컴포넌트의 책임을 분리함으로써 유지보수성을 향상시키는 데 도움을 줍니다.

## 마치며

일반적인 방식으로 만든 드롭다운의 문제점을 파악하고, 합성 컴포넌트를 사용해 단일 책임 원칙을 지키며 중복 코드를 방지해 DRY 원칙을 준수함으로써 개선 과정을 보여주었다. 그러나 합성 컴포넌트가 항상 최선의 선택은 아닐 수 있으므로, 상황에 따라 더 적합한 방법이 있을 수 있음을 염두에 두자.

또한, UI 컴포넌트를 만들 때 무의식적으로 간단하게 구현하려는 경향이 있다. 하지만 자신이 만든 컴포넌트가 진정으로 좋은지 한 번 더 고민해볼 필요가 있다. 다양한 라이브러리에서 컴포넌트의 네이밍과 구현 방식을 살펴보며 분석하는 과정은 더 나은 컴포넌트를 설계하는 데 큰 도움이 된다.

이 글에서는 Radix UI의 특징인 `Render Delegation`까지 적용해 보여 드리고 싶었지만, 라이브러리의 소스 코드를 그대로 사용하면 되기에 생략하겠다. 관심 있는 분들은 아래의 링크를 참고하면 좋을 것이다.

## 레퍼런스

- [Radix UI Dropdown](https://github.com/radix-ui/primitives/blob/main/packages/react/dropdown-menu/src/DropdownMenu.tsx)
- [Render Delegation](https://www.radix-ui.com/primitives/docs/utilities/slot)


당신의 드롭다운 메뉴는 재사용성과 확장성을 고려하고 있나요?

점진적으로 드롭다운 메뉴 개선하기


## Compound Pattern이란

Compound Pattern은 여러개의 작은 컴포넌트들을 합성해 만든 디자인 패턴입니다. 여러 개의 작은 컴포넌트란 어떤 말일까요? HTML의 `select` 태그를 봐봅시다.

```html
<select>
  <option value="js">JavaScript</option>
  <option value="ts">TypeScript</option>
</select>
```

select 태그와 option 태그를 사용해 하나의 기능이 완성되는 것 처럼 요소들을 세분화하고 합성해서 사용하는 것을 말합니다. Compound Pattern은 UI 라이브러리(Radix UI, MUI)에서 많이 볼 수 있습니다. UI 라이브러리에서 이 패턴을 사용한다는 건 많은 이점이 있기 때문에 사용한다고 볼 수 있습니다.
Compound Pattern을 사용하면 어떤 이점이 있는지 알아보겠습니다

## Compound Pattern의 장점

- 유연한 UI 구조
- 가독성 및 일관성 있는 코드
- props 관리
- prop drilling
- 관심사 분리

Compound Pattern을 사용하면 장점은 크게 4가지로 구분됩니다. 우선 코드 예시를 봐보겠습니다. 다음은 제가 실제로 작업하면서 만들었던 코드입니다.

```tsx
<FormControl type="form" id="email" hasError={hasError}>
  <FormControl.Label>이메일</FormControl.Label>
  <FormControl.Input type="text" placeholder="이메일을 입력해주세요" {...register("email")} {...props} />
  <FormControl.ErrorMessage />
</FormControl>
```

저는 각 Form에 해당하는 Field들을 Compound Pattern을 적용 했습니다. 먼저 왜 유연한 UI 구조인지에 대해 알아볼게요.

### 왜 유연한 UI 구조인가?

위 코드를 보시면 Atomic Pattern처럼 여러 개의 작은 컴포넌트들을 조합해 사용하고 있습니다. 즉 아래와 같이 하나의 컴포넌트가 여러 가지의 일들을 내장하고 있는 게 아니라 조합해서 사용하기 때문에 유연하다는 특징이 있습니다.

조금 더 설명하자면 아래 예시는 컴포넌트 이름이 잘못되었을 수 있지만, **어떠한 이름을 지어도 저 컴포넌트 안에 어떠한 요소들이 있는지 파악**하기 힘들거나 **이름부터 하는일이 많아진다고 느껴 거부감**이 들게됩니다. 만약 새로운 요구사항이 들어와 `Label`이 없는 FormField를 만든다면 어떻게 해야할까요 ??? 아마 Compound Pattern을 사용하지 않는다면 새로운 컴포넌트를 만들거나 또는 props로 전달해 내부 로직에 추가가 될거에요.

```tsx
<FormControl /> // 안에 구성요소를 보기위해 팀원들은 무조건 내부로직을 봐야합니다.
<FormFieldWithLabel /> // 괜찮지만 이게 정말 명확한 이름일까요 ? 에러메세지가 없다면요 !?
<FormFieldWithLabelWithMessage /> // 음.. 해석하기 싫어지는 이름입니다...
```

### props 관리

요구사항에 맞춰 작업하기 위해 props를 추가적으로 전달하게 된다면 props는 끝날 줄 모르게 늘어나게 됩니다. 즉 컴포넌트의 props가 3개를 초과하게 됩니다. 다음은 제가 협업하면서 팀원이 작성했던 코드를 가져와 볼게요.

```tsx
<InputField
  label="이메일"
  id="email"
  type="email"
  value={email.value}
  autoComplete="email"
  onChange={(e) => setEmail(e.target.value)}
  onBlur={validateEmail}
  placeholder="이메일을 입력해 주세요"
  error={email.error}
  ref={focusRef}
/>
```

위에 Compound Pattern을 사용할 때를 비교해보시면 어떤 느낌이 드시나요? ＂이건 좀 아니지 않나＂ 또는 ＂나쁘지 않은데?＂ 라는 생각이 들 수 있지만, 이 컴포넌트를 사용하는 팀원 입장에서도 생각해보면 좋을 것 같습니다. 본인이 혼자 만들고 사용하는 건 전혀 문제가 되지 않습니다. 처음부터 만들었으니까요. 하지만 사용하는 팀원들은 이해하는데 시간을 꽤 투자할 거에요.

실제로 협업할 때 저희 팀원은 Label이 없는 상황일 때 새로운 컴포넌트를 만들었습니다. 결국 재사용성 부분도 문제가 있습니다. 컴포넌트도 마찬가지로 전달해야하는 **props를 웬만하면 3개를 초과**하지 않는게 사용하는 개발자 입장에서 더 좋을 것 같습니다. 사소하지만 이러한 DX들이 중요하다는 생각이 듭니다.

### prop drilling

Compound Pattern은 Context API를 사용하기 때문에 부모 컴포넌트에서 자식 컴포넌트로 전달할 때 직접 전달할 수 있다는 장점이 있습니다. 따라서 Props Drilling에 대한 걱정이 없고 작은 단위로 Context API를 사용하기 때문에 리 렌더링 문제도 크게 걱정하지 않아도 됩니다.

### 가독성 및 일관성 있는 코드

가독성이 높을 수밖에 없는 이유는 여러 가지의 요소들로 구성되어있기 때문입니다. 추가적으로 이름의 통일성이 있어 가독성이 높아진 것도 한몫합니다. 추가 요구사항에도 대응할 수 있기 때문에 재사용성도 높아지니 일관성 있는 코드라고도 부를 수 있을 것 같네요.

### 관심사 분리

핵심적인 로직은 부모 컴포넌트가 담당하고 있습니다. 따라서 자식 컴포넌트들은 본연의 역할만 수행하게 됩니다. Atomic Pattern처럼 컴포넌트들을 세분화했기 때문에 수정해야 할 요소를 쉽게 파악할 수 있고 컴포넌트 내부만 보아도 간단하여서 파악하거나 수정할 때 유리합니다. 즉 **재사용성을 높이는 방법**이라고 볼 수 있습니다.

## Compound Pattern의 단점

단점으로는 JSX 코드가 많이 길어지는 부분과 레이아웃 순서대로 배치되기 때문에 간혹 이상하게 나오는 경우도 있습니다. 너무 좋은 장점 때문에 일어난 단점이기에 팀원들과 상의하면 충분히 해결할 수 있는 문제라고 봅니다.

## Compound Pattern 구현해보기

정말 간단한 형태인 카운트를 예제로 Context API를 사용해 만들어보겠습니다. 항상 무엇인가를 만들 때 필요한 요소가 무엇인지를 알아야 하고, 상태를 어떻게 관리할 건지에 대해서도 고민해보면 좋을 것 같습니다.

- 카운트된 숫자를 보여줄 컴포넌트
- +1 증가하는 버튼 컴포넌트
- -1 감소하는 버튼 컴포넌트

### 구현부

```tsx
import { createContext, ButtonHTMLAttributes, ReactNode, useContext } from "react"

interface ButtonProps extends ButtonHTMLAttributes<HTMLButtonElement> {
  children: ReactNode
}

type CountContextType = {
  count: number
  onIncrease: () => void
  onDecrease: () => void
}

interface CountProps extends CountContextType {
  children: ReactNode
}

const CountContext = createContext<CountContextType>({
  count: 0,
  onIncrease: () => {},
  onDecrease: () => {},
})

// CountProvider에서 사용안하는 경우를 대비한 코드입니다.
function useCountContext() {
  const context = useContext(CountContext)
  if (!context) throw new Error("CountContext에서 사용해주세요.")
  return context
}

export default function Count({ children, ...countStates }: CountProps) {
  return <CountContext.Provider value={{ ...countStates }}>{children}</CountContext.Provider>
}

function Score() {
  const { count } = useCountContext()
  return <span>{count}</span>
}

function IncreaseButton(props: ButtonProps) {
  const { onIncrease } = useCountContext()
  return <button onClick={onIncrease}>{props.children}</button>
}

function DescreaseButton(props: ButtonProps) {
  const { onDecrease } = useCountContext()
  return <button onClick={onDecrease}>{props.children}</button>
}

Count.Score = Score
Count.IncreaseButton = IncreaseButton
Count.DescreaseButton = DescreaseButton
```

### 사용부

```tsx
// 사용부
export default function Usage() {
  const [count, setCount] = useState(0)
  const onIncrease = () => setCount((count) => count + 1)
  const onDecrease = () => setCount((count) => count - 1)

  return (
    {/* customHook을 사용하면 {...countState}로 더 깔끔하게도 가능합니다! */}
    <Count count={count} onIncrease={onIncrease} onDecrease={onDecrease}>
      <Count.Score />
      <Count.IncreaseButton>+1</Count.IncreaseButton>
      <Count.DescreaseButton>-1</Count.DescreaseButton>
    </Count>
  )
}
```

## 마치며

상태가 부모 컴포넌트에서만 관리된다면 로직을 부모 컴포넌트(Count)에서 관리해도 상관없습니다. 만약 부모 컴포넌트에서 로직을 관리한다면 props 전달은 필요 없겠네요. 이러한 부분에서 `Popover`와 같은 컴포넌트에서 매우 유용할 것 같습니다.

저는 부모 컴포넌트에서 로직을 지정하지 않고 사용하는 측 컴포넌트에서 작성해 전달해주도록 했습니다. 컴포넌트 만들 때 재사용성을 고려한다면 이처럼 Compound Pattern을 적극 사용해보는 걸 추천합니다.


합성 컴포넌트를 사용해 유연한 UI, 재사용성 향상, 가독성 높은 코드를 만들어보자. 👀

Compound Pattern을 사용해 재사용 극대화하기


`props.children`을 사용하면 의도치 않은 동작으로 렌더링이 트리거되거나, 안되는 문제가 발생한다. 또한, 렌더링이 트리거되면 useMemo를 사용해 렌더링을 방지하려고 했지만 이 역시 제대로 동작하지 않는다. 이러한 문제가 왜 발생하는지 알아보자.

1. props.children이란 ?
2. JSX와 React Element
3. 부모 컴포넌트 렌더링시 자식 컴포넌트가 렌더링 안되는 이유.
4. 부모 컴포넌트 렌더링시 자식 컴포넌트가 렌더링 되는 이유.
5. render function으로 전달했을 때 렌더링 되는 이유.
6. 부모 컴포넌트 렌더링시 자식 컴포넌트도 렌더링되어 useMemo로 최적화 했지만 그럼에도 렌더링 되는 이유.

## props.children이란

`props.children`이라는 특수한 prop을 사용해 자식 컴포넌트나 요소들을 부모 컴포넌트에 전달할 수 있다. 즉 부모 컴포넌트와 자식 컴포넌트(요소) 사이에 포함관계를 설정할 수 있다. 부모 - 자식 관계가 설정되면 부모 컴포넌트에서 `props.children`으로 자식 컴포넌트에 대한 정보에 접근할 수 있다.

즉 `props.children`을 통해 요소 또는 컴포넌트를 합성해서 사용할 수 있고, 어떠한 요소나, 복잡한 컴포넌트가 와도 상관이 없어서 매우 유연하다는 특징이 있다. 따라서 애플리케이션의 여러 부분에서 코드의 재사용성을 향상할 수 있고 모듈화된 코드를 작성할 수 있다.

> props가 동일하다면 리 렌더링이 일어나지 않는다.

```tsx
    <Parent>
        <Child>
    </Parent>
```

## JSX와 React Element

JSX란 JavaScript에 XML을 추가하여 확장한 문법이다. HTML에 태그를 작성하듯 사용할 수 있도록 도와준다. Babel은 JSX를 `React.Element(type, props, children)` 메서드로 호출해 컴파일하고 `React Element`를 생성한다.

`React Element`는 일반 객체면서도 불변성을 가진다. React Element를 생성한 이후에는 해당 element의 자식이나 속성을 변경할 수 없다. 즉 Re-rendering이 된다는 건 `React Element`를 새롭게 만든다고 할 수 있다.

## 근본적인 문제 찾기.

사전지식을 습득했으니 이제 위에 설명했던 렌더링 문제를 설명할 수 있다. 부모 컴포넌트 렌더링 시 자식 컴포넌트가 렌더링 안되는 이유를 찾아보자. 다음은 버튼을 누르면 상태가 변경되어 렌더링을 일으킨 코드다.

```tsx
export default function App() {
  return (
    <Parent>
      <Child />
    </Parent>
  )
}

function Parent(props: PropsWithChildren) {
  const [isToggle, setIsToggle] = useState(false)
  const handleToggle = () => setIsToggle((prevState) => !prevState)
  console.log("Parent Rendering")
  return (
    <>
      {props.children}
      <button onClick={handleToggle}>Click Me</button>
    </>
  )
}

function Child() {
  console.log("Child Rendering")
  return <div>Child</div>
}
```

실행결과
![실행결과](/posts/react/children/result.png)

위에 예제는 Child 컴포넌트가 렌더링 트리거되지 않는 문제다. 실행 결과를 보면 `Parent Rendering`이 콘솔에 여러 번 찍히는 것을 볼 수 있다. 흔히들 상태 변경이 되면 상태가 일어난 컴포넌트부터 하위 컴포넌트까지 렌더링이 트리거 된다고 알고 있지만, 이 예제에서는 그렇지 않다.

`props.children`은 `React Element`를 생성하고 불변성 객체라고 말했다. App 컴포넌트가 렌더링 될 때 Child 객체가 만들어진다. 객체의 생성 시점은 App 컴포넌트라는 것이다. 객체를 만든 시점은 App이지만 렌더링은 Parent에서 트리거된다는 것이다. 따라서 Parent 컴포넌트가 트리거 되어도 Child 컴포넌트는 동일한 props이기 때문에 리 렌더링이 트리거 되지 않는다. 즉 Child 컴포넌트가 렌더링이 되려면 Child의 생성 시점인 App에서 렌더링이 트리거 돼야 한다는 것이다.

이것을 실행 컨텍스트 관점으로 생각해보자. 여기에서는 전역 실행 컨텍스트와 App 컴포넌트는 제외하겠다.

1. [ Parent 컴포넌트 ] 함수 호출
2. [ Parent 컴포넌트 ] [ Child 컴포넌트 ] 함수 호출
3. [ Parent 컴포넌트 ] [ Child 컴포넌트 ] 함수 반환
4. [ Parent 컴포넌트 ]
5. [ ]

실행 컨텍스트로 보면 위와 같다. 먼저 호출 단계를 봐보자. Parent 컴포넌트가 호출하고 스택에 쌓인다. 그런 다음 Child 컴포넌트를 호출하면서 스택에 쌓인다. Child 컴포넌트를 호출한다는건 아직 값을 반환하기 전이다. 즉 렌더링 전 단계이다. 이제 렌더링 완료 단계를 봐보자. Child 컴포넌트가 반환되어 스택에서 제거되고, Parent 컴포넌트가 반환되어 스택에서 제거된다. 여기서 중요한건 Child 컴포넌트가 반환된 값은 props가 동일한 객체라서 리 렌더링이 트리거 되진 않는다. 렌더링 자체는 Parent에서 할 뿐이다.

이제 render function을 사용했을 때 리 렌더링이 되는 경우를 봐보자. 코드는 다음과 같다.

```tsx
export default function App() {
  return <Parent>{() => <Child text="hello" />}</Parent>
}

function Parent(props: { children: () => React.ReactNode }) {
  const [isToggle, setIsToggle] = useState(false)
  const handleToggle = () => setIsToggle((prevState) => !prevState)
  console.log("Parent Rendering")

  return (
    <>
      {props.children()}
      <button onClick={handleToggle}>Click Me</button>
    </>
  )
}

function Child({ text }: { text: string }) {
  console.log("Child Rendering")
  return <div>{text}</div>
}
```

객체가 생성되는 시점은 App 컴포넌트이고 props.children을 함수로 전달한 케이스다. 이 예제에서는 Parent에 상태가 변경되었을 때 Child 컴포넌트가 리 렌더링이 트리거 된다. 리 렌더링이 트리거 되는 이유는 props.children에서 함수로 호출하기 때문에 그렇다. 즉 함수는 객체타입이다. 함수를 호출할 때마다 다른 참조 값이기에 props가 다르다고 인식해 리 렌더링이 트리거 되는 것이다. 이건 리액트가 아니라 자바스크립트의 개념이다. 따라서 원시타입과 객체타입에 대해 알아야 할 필요가 있다.

마지막으로 React.memo를 사용해 최적화했을 때 적용 안 되는 이유에 대해서 알아보자. 이러한 경우는 다음 코드와 같다.

```tsx
export default function App() {
  const [isToggle, setIsToggle] = useState(false)
  const handleToggle = () => setIsToggle((prevState) => !prevState)
  console.log("App")
  return (
    <>
      <ParentMemo>
        <Child />
      </ParentMemo>
      <button onClick={handleToggle}>Click Me</button>
    </>
  )
}

const ParentMemo = React.memo(Parent)

function Parent(props: PropsWithChildren) {
  console.log("Parent Rendering")
  return <div>{props.children}</div>
}

function Child() {
  console.log("Child Rendering")
  return <div>Child</div>
}
```

실행결과
![실행결과](/posts/react/children/result2.png)

위 코드는 App에서 버튼을 클릭하면 상태가 변화하기 때문에 리 렌더링이 발생한다. 하지만 `React.memo`를 사용했음에도 여전히 하위 컴포넌트에서는 리 렌더링이 발생한다. 이것도 쉽게 답을 찾을 수 있다. 우리는 JSX를 통해 새로운 `React Element`를 만든다는 것을 알고 있다. 즉 App 컴포넌트가 리 렌더링 되면서 `props.children`을 새로운 객체로 만든다. 따라서 `React.memo`는 새로운 props라고 인식하기 때문에 리 렌더링이 일어나는 것이다.

> 여기서 `React.memo`란 컴포넌트를 Memoization 해서 props가 변경되지 않았다면 리 렌더링 방지하는 것을 말한다.

여기서 한 가지 중요한 건 `props.children`은 컴포넌트 props의 children이라는 속성으로 전달해도 똑같이 동작한다. 즉 다음과 같다는 말이다.

```tsx
<Parent children={<Child />} />
```

```tsx
<Parent>
    <Child>
</Parent>
```

## 결론

props.children에 렌더링은 부모 컴포넌트에서 한다. 하지만 props.children 자체는 부모 컴포넌트를 호출한 컴포넌트에서 객체를 생성하기 때문에 이러한 문제가 발생했다. 또한 render function같은 경우엔 함수를 사용했기 때문에 반환된 값은 같은 객체여도 함수로 인해 참조값이 달라져 리 렌더링이 트리거 되는 이유다. 이제 어느 정도 이해를 했다면 props.children을 통해 렌더링 최적화도 해보면 좋을 것 같고 추가로 react-router-dom에서 사용하는 패턴인 `Render Props Pattern`도 알아보면 좋을 것 같다.

마지막으로 이러한 의도치않은 렌더링 문제로 인해 useCallback이나 useMemo를 사용하는 경우가 있는데 렌더링이 된다고 무작정 Memoization 사용하는 것보단 최소한 "왜 렌더링이 되는가"에 대해서 생각해보면 좋을 것 같다.

## Reference

- [children props에 대한 고찰](https://velog.io/@2ast/React-children-prop%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B3%A0%EC%B0%B0feat.-%EB%A0%8C%EB%8D%94%EB%A7%81-%EC%B5%9C%EC%A0%81%ED%99%94#reactmemo%EB%A5%BC-%EB%AC%B4%ED%9A%A8%ED%99%94%ED%95%98%EB%8A%94-children-prop)
- [The mystery of React Element, children, parents and re-renders](https://www.developerway.com/posts/react-elements-children-parents)


props.children을 사용할 때 렌더링 문제를 겪었던 적이 있나요?

props.children 깊게 공부하기


<a href="https://kr.freepik.com/free-vector/3d-hyogwawa-junglyeog-gihahagjeog-dohyeong_5229952.htm#fromView=search&page=1&position=47&uuid=5ac311bc-708e-41ec-88bf-fc5f67745a0e">
  작가 pikisuperstar 출처 Freepik
</a>

**이 글을 읽으면 배울 수 있는 것**

- React에서 렌더링의 의미
- React가 컴포넌트를 언제, 왜 렌더링 하는지
- 화면에 컴포넌트를 표시하는 단계
- 렌더링이 항상 DOM 업데이트를 하지 않는 이유

---

## 렌더링 프로세스

React에서 렌더링이란 컴포넌트가 props와 state를 통해 UI를 어떻게 구성할지 컴포넌트에게 요청하는 작업을 말한다. 일반적으로 말하는 렌더링은, 화면에 바로 나타나는 것처럼 표현되고, React에서는 화면에 나타내기전 어떤 과정을 시작하는 듯한 어조이다. 따라서, 주의해야 할 점은 React에서 렌더링은 DOM 업데이트가 아니다. 즉, **렌더링은 실질적 화면 업데이트가 아니라는 점**이다.

[React가 컴포넌트를 화면에 표시하는 과정](https://ko.react.dev/learn/render-and-commit)은 총 3단계가 있다.

1. Rendering Trigger
2. Component Rendering
3. 리액트가 DOM에 Commit

### Rendering Trigger

Trigger가 되는 조건은 컴포넌트의 state가 `Object.is()` 메서드를 사용해 state 값이 불변을 지켜 변경되었을 때다. state가 변경이되면 리 렌더링이 일어나는데, 리 렌더링은 상태 값에 의존해 새로운 데이터로 새로운 화면을 그린다. 따라서 React가 데이터가 변경되었다는 것을 알아야 하며 그 과정이 Trigger 과정이다. 반드시 상태 값을 Set 함수로 업데이트해야 하는 이유다. React가 렌더링 될 것인지 되지 않을 것인지 판단하기 위해서다.

다음은 컴포넌트가 리렌더링 되는 조건이다.

- 부모 컴포넌트가 리렌더링 되었을 때
- state 값이 변경되었을 때
- context API의 state 변경되었을 때

set State의 함수는 Queue에 순차적으로 등록된다. 이 과정은 Rendering 과정에서 다시 활용된다.

### Component Rendering

렌더링을 Trigger 한 후 React는 컴포넌트를 호출하여 화면에 표시할 내용을 파악한다. 이 단계에서 Reconciliation(재조정)이 일어난다.

- 초기 렌더링에서 React는 루트 컴포넌트를 호출한다.
- 이후 렌더링에서 React는 state 업데이트가 일어나 렌더링을 Trigger 한 컴포넌트를 호출한다.

#### Reconciliation

Reconciliation(재조정)이란 렌더링 프로세스에서 컴포넌트를 실행해 앞으로 그려질 DOM과 그려지기 전 DOM을 비교해 달라진 부분을 찾아 변경이 필요한 컴포넌트를 체크하는 단계다. 여기서 사용하는 알고리즘이 diffing 알고리즘이다.
다음과 같이 세 가지 중 하나라도 변경된 것이 있으면 변경이 필요한 컴포넌트로 체크해둔다.

- type
- props
- key

처음 렌더링할 경우 React는 가상 DOM을 그려놓는다. 그리고 Trigger가 발생하면, 새롭게 가상 DOM을 그린다. 그리고 Diffing 알고리즘을 통해 위 과정을 거쳐 어떤 부분을 업데이트할지 결정하는 것이다. 왜 이런 과정을 거칠까? 굳이 리 렌더링 되지 않아도 되는 부분은 제외하고 변경되어야 하는 부분만 변경하기 위해서이다. 즉, 효율성을 위함이다.

web 혹은 native 환경에서의 DOM 조작은 비용이 비싸다. 하지만, 가상 DOM을 비교하거나 조작하는 일은 실제 DOM을 조작하는 것에 비해 가격이 저렴하다. 가상 DOM은 JavaScript로 조작할 수 있는 가벼운 메모리이기 때문이다. 또한, 모든 DOM을 새로 그리게 될 경우 focus가 없어질 수 있고, select 요소에서 선택했던 option 값이 사라졌을 수도 있으며 스크롤 정보도 없어질 수 있다.

#### Batching

Batching(일괄 처리)은 리액트가 더 나은 성능울 위해 여러 상태 업데이트를 단일 리 렌더링으로 그룹화하는 것을 말한다. Trigger 단계에서 set State의 함수는 Queue에 순차적으로 들어간다고 했다. 이제 Diffing 알고리즘으로 어떤 DOM이 변경되어야 하는지 알았기 때문에, 변경되어야 할 DOM의 state 값을 Queue에 들어갔던 함수를 실행하면서 계산한다.

브라우저의 렌더링은 reflow와 repaint 과정의 비용이 비싸다. 하지만 리액트는 Batching을 통해서 단일 리랜더링으로 그룹화했기 때문에 state가 업데이트될 때마다 리랜더링이 되지 않는다는 성능적 이점이 있다. 즉 단일 리 렌더링으로 그룹화했기 때문에 reflow, repaint를 한 번만 일어나도록 했다.

React 18 버전부터는 Promise, setTimeout, EventHandler 등도 함께 일괄 처리된다. [Automatic batching for fewer renders in React 18](https://github.com/reactwg/react-18/discussions/21)에서 확인할 수 있다. 이 과정을 통해 리렌더링은 setState가 호출될 때마다 실행되는 것이 아니라, 마지막에 한번만 실행 되도록 했다.

### Commit

커밋 단계를 거쳐서 DOM을 업데이트하고 나면, React는 요청된 DOM 노드와 컴포넌트 인스턴스를 가리키도록 모든 변경사항들을 업데이트한다. 그리고나서 componentDidMount 와 componentDidUpdate 클래스 생명주기 메소드 또는 useLayoutEffect 훅을 동기적으로 실행한다. 여기서도 DOM에 마운트 된다는 뜻이지 paint 된다는 뜻이 아니다. 이 단계는 항상 일관적 화면 업데이트를 위해 동기적으로 실행된다. 동기적으로 실행된다는 것은 콜 스택을 비우지 않고, DOM 조작을 Batching 처리 한다는 뜻이다. Commit 단계가 끝나면 브라우저의 렌더링이 발생한다.

여기서 알 수 있는 중요한 사실은 리액트의 렌더링이 일어난다고 해서 무조건 DOM 업데이트가 일어나는 것은 아니라는 것이다. 렌더링을 수행했으나 커밋 단계까지 갈 필요가 없다면, 즉 변경 사항을 계산했는데 아무런 변경 사항이 감지되지 않는다면 이 커밋 단계는 생략될 수 있다. 리액트의 렌더링은 꼭 가시적인 변경이 일어나지 않아도 발생할 수 있다.

React가 상태를 기반으로 효율적으로 화면을 그려내기 위한 동작은 아래와 같다.

- setState의 Object.is() 메서드로 상태 값 비교
- Reconciliation의 가상 DOM으로 부분 리렌더링
- Batching(일괄 처리)를 통해 여러 번이 아닌 한 번만 리렌더링

## Reference

- [React 렌더링과정으로 알아보는 선언적이라는 의미](https://pozafly.github.io/react/declarative-meaning-of-react-rendering-process/)
- [리액트 렌더링 동작의 (거의) 완벽한 가이드](https://velog.io/@arthur/%EB%B2%88%EC%97%AD-%EB%A6%AC%EC%95%A1%ED%8A%B8-%EB%A0%8C%EB%8D%94%EB%A7%81-%EB%8F%99%EC%9E%91%EC%9D%98-%EA%B1%B0%EC%9D%98-%EC%99%84%EB%B2%BD%ED%95%9C-%EA%B0%80%EC%9D%B4%EB%93%9C-A-Mostly-Complete-Guide-to-React-Rendering-Behavior#%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8-%ED%83%80%EC%9E%85%EA%B3%BC-%EC%9E%AC%EC%A1%B0%EC%A0%95-reconciliation)
- [React Deep Dive 도서]


당신이 알고 있는 렌더링은 무엇인가요? 이번에 제대로 공부하는 시간을 가져봅시다.

D5ng

React Hook Form과 유사한 인터페이스 만들기

점진적으로 드롭다운 메뉴 개선하기

Compound Pattern을 사용해 재사용 극대화하기

props.children 깊게 공부하기

리액트 렌더링 과정에 대해 어디까지 알고 있나요?