useId란

서버와 클라이언트에서 동일한 ID를 생성하도록 보장하는 Hook이다.

중요한 건

랜덤 ID 생성 자체가 목적이 아니라,
SSR hydration consistency를 보장하는 게 핵심이라는 점이다.

왜 문제가 생길까

SSR 환경에서는

서버가 먼저 HTML 생성
이후 클라이언트가 hydration

을 수행한다.

즉

서버 렌더링
클라이언트 렌더링

이 두 번 발생한다.

문제는 랜덤 ID다.

랜덤 ID 문제

예를 들어:

const id = Math.random();

서버:

0.12345

클라이언트:

0.98765

당연히 다르다.

즉:

서버 HTML
≠
클라이언트 hydration 결과

상태가 된다.

결과:

hydration warning
attribute mismatch
UI 불일치

문제가 발생할 수 있다.

useId 사용

import { useId } from 'react';

function Input() {
  const id = useId();

  return (
    <>
      <label htmlFor={id}>이름</label>
      <input id={id} />
    </>
  );
}

이제:

서버
클라이언트

모두 동일한 ID를 사용한다.

즉 hydration mismatch를 줄일 수 있다.

Form Field

function TextField({
  label,
}: {
  label: string;
}) {
  const id = useId();

  return (
    <div>
      <label htmlFor={id}>
        {label}
      </label>

      <input id={id} />
    </div>
  );
}

이제:

컴포넌트 여러 개 렌더링 가능
ID 충돌 없음
label/input 연결 유지

된다.

aria-describedby

예를 들어 validation message.

function EmailField() {
  const id = useId();

  return (
    <>
      <input aria-describedby={id} />

      <p id={id}>
        이메일 형식을 입력해주세요.
      </p>
    </>
  );
}

이런 구조에서 useId를 많이 사용했다.

특히:

form library
design system component

만들 때 중요했다.

렌더링 순서 기반

이 부분이 가장 중요하다.

useId는 내부적으로 렌더링 순서를 기반으로 ID를 생성한다.

첫 번째 useId
→ r0

두 번째 useId
→ r1

느낌이다.

그래서

서버
클라이언트

가 같은 렌더링 순서를 가져야 한다.

key로 쓰면 안 되는 이유

이것도 많이 실수한다.

{
  list.map((item) => (
    <div key={useId()} />
  ));
}

이건 잘못된 사용이다.

왜냐하면 React의 key는 “데이터 identity” 를 나타내야 하기 때문이다.

즉

같은 데이터
→ 같은 key 유지

가 중요하다.

근데 useId는

렌더링 기반
hook 순서 기반

이다.

즉 데이터 identity용이 아니다.

useId는 전역 UUID가 아니다

이것도 중요하다.

예를 들어

const id = useId();

이걸

DB PK
API identifier
global UUID

처럼 쓰면 안 된다.

useId는

React tree 내부
렌더링 컨텍스트

안에서만 의미 있다.

즉

React accessibility ID
에 더 가깝다.

UseId