A-4: React 컴포넌트 타이핑 — props·이벤트·children·ref

안녕하세요, 홍순구입니다. 지난 시간에 좋아요가 눌리고 댓글이 달리는 피드를 만들었죠. 그러면서 제가 마지막에 이런 말을 남겼습니다. 오늘 이벤트 객체의 타입을 한 번도 안 적었다고요.

정말 그랬는지 지난 시간 코드를 다시 봅시다.

// apps/web-spa/src/components/CommentForm.tsx — 지난 시간에 만든 입력창
<input
  className="comment-input"
  value={content}
  onChange={(event) => setContent(event.target.value)}
  placeholder="댓글 달기..."
  aria-label="댓글 입력"
/>

event에 타입이 없습니다. 그런데도 event.target.value를 칠 때 에디터가 자동완성을 띄워줬어요. TypeScript가 이미 알고 있었다는 뜻입니다.

함수 안이 길어지면 누구나 하는 일이니까, 이 핸들러를 밖으로 한번 빼 봅시다.

function handleChange(event) {
  setContent(event.target.value);
}

빨간 줄이 그어집니다. 방금까지 알아서 잘 되던 게 안 돼요.

오늘은 이 빨간 줄에서 출발합니다. 컴포넌트에는 값이 드나드는 입구가 여럿 있어요. props로 값이 들어오고, 이벤트로 사용자의 동작이 들어오고, children으로 다른 화면 조각이 들어오고, ref로는 실제 DOM 요소가 나갑니다. 오늘 이 네 입구에 전부 타입을 답니다.

 오늘의 여정

 Step 1~3   이벤트 객체에 타입 달기 · 함수를 props 로 받을 때의 타입
    │
 Step 4~5   props 타입을 짓는 세 가지 길 · 컴포넌트를 함수로 선언하는 이유
    │
 Step 6~7   children 을 명시로 받기 · ref 를 props 로 받기
    ▼
 네 입구가 모두 타입으로 지켜지는 인스타 컴포넌트

💡 오늘 수업의 핵심 — "컴포넌트의 입구를 타입으로 적는다"

지난 세 번의 TypeScript 시간에 데이터의 모양을 타입으로 적었습니다. 오늘은 그 타입을 컴포넌트에 연결해요. 무엇이 들어오고 무엇이 나가는지를 함수 시그니처 하나만 봐도 알 수 있게 만드는 것이 오늘의 전부입니다.

🎯 학습 목표

• 이벤트 핸들러를 밖으로 뺐을 때 필요한 이벤트 타입을 스스로 찾아 적을 수 있다
• props 타입을 새로 선언할지, 파생시킬지, 확장할지 판단할 수 있다
• children과 ref를 props로 명시해서 받을 수 있다

Step 1: "핸들러를 밖으로 빼는 순간"

오프닝에서 본 빨간 줄부터 확인하고 갑시다. 에디터에 마우스를 올리면 이렇게 나옵니다.

error TS7006: Parameter 'event' implicitly has an 'any' type.

매개변수 event가 슬그머니 any가 됐다는 뜻입니다. 지난 A-1 시간에 strict를 켜 두었죠. any를 조용히 넘어가지 않고 잡아주는 것이 그 설정의 일입니다.

인라인일 때는 왜 됐을까

같은 코드인데 JSX 안에 있을 때는 아무 말이 없었습니다. 그 이유는 화살표 함수가 놓인 위치에 있어요.

onChange={(event) => setContent(event.target.value)}

<input>의 onChange는 아무 함수나 받는 게 아닙니다. React 타입 정의에 "이 속성에는 이런 모양의 함수가 온다" 고 이미 적혀 있어서, 그 속성에 직접 써 넣은 화살표 함수는 자기 매개변수의 타입을 그 정보에서 물려받습니다. 주변 문맥을 보고 타입을 채워주는 것이라 문맥 기반 타이핑이라고 불러요.

밖으로 빼는 순간 이 연결이 끊어집니다. 함수 혼자 떨어져 있으면 자기가 나중에 어디에 쓰일지 알 방법이 없거든요.

 인라인으로 쓸 때                       밖으로 뺐을 때

 <input onChange={(e) => ...} />        function handleChange(e) { ... }
           ↑                                              ↑
   onChange 가 원하는 함수 모양을            물려받을 문맥이 없다
   그 자리에서 물려받는다                     → 직접 적어야 한다

그래서 직접 적는다

// apps/web-spa/src/components/CommentForm.tsx
function handleChange(event: React.ChangeEvent<HTMLInputElement>) {
  setContent(event.target.value);
}

이름을 두 조각으로 나눠 읽으면 외울 게 없습니다. ChangeEvent는 어떤 종류의 이벤트인지를 말하고, 꺾쇠 안의 HTMLInputElement는 그 이벤트가 어느 요소에서 났는지를 말해요. 값이 바뀌는 사건이 입력창에서 일어났다, 이렇게 읽으면 됩니다.

이걸 적어주면 event.target.value가 다시 string으로 잡힙니다. 자동완성도 돌아와요.

지금까지의 CommentForm은 이렇게 생겼습니다.

// apps/web-spa/src/components/CommentForm.tsx
import { useState } from 'react';

interface CommentFormProps {
  onSubmit: (content: string) => void;
}

export function CommentForm({ onSubmit }: CommentFormProps) {
  const [content, setContent] = useState('');
  const isEmpty = content.trim() === '';

  function handleChange(event: React.ChangeEvent<HTMLInputElement>) {
    setContent(event.target.value);
  }

  return (
    <form
      className="comment-form"
      onSubmit={(event) => {
        event.preventDefault();
        onSubmit(content.trim());
        setContent('');
      }}
    >
      <input
        className="comment-input"
        value={content}
        onChange={handleChange}
        placeholder="댓글 달기..."
        aria-label="댓글 입력"
      />
      <button className="comment-submit" type="submit" disabled={isEmpty}>
        게시
      </button>
    </form>
  );
}

제출 핸들러는 아직 JSX 안에 남아 있습니다. 다음 Step에서 저것도 꺼냅니다.

💡 한 줄 정리

JSX 속성에 직접 쓴 화살표 함수는 이벤트 타입을 문맥에서 물려받지만, 이름 붙여 밖으로 뺀 함수는 물려받을 문맥이 없어 직접 적어야 합니다.

import type { ChangeEvent } from 'react';

function handleChange(event: ChangeEvent<HTMLInputElement>) {
  setContent(event.target.value);
}

Step 2: "클릭과 제출 — MouseEvent와 FormEvent"

이번엔 제출 핸들러도 밖으로 꺼내 보는데, 방식은 똑같아요. 어떤 이벤트가 어느 요소에서 나는지만 적으면 됩니다.

// apps/web-spa/src/components/CommentForm.tsx
function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
  event.preventDefault();
  if (isEmpty) {
    return;
  }
  onSubmit(content.trim());
  setContent('');
}

제출 사건이 폼에서 일어났으니 FormEvent와 HTMLFormElement입니다.

event.preventDefault()는 지난 시간에도 있었던 줄이에요. 브라우저는 폼이 제출되면 페이지를 통째로 새로 불러오려고 합니다. 그 기본 동작을 막는 것이고, 이걸 빼먹으면 댓글을 달 때마다 화면이 깜빡이며 처음으로 돌아갑니다.

if (isEmpty) return도 새로 넣었습니다. 버튼은 비활성이라 못 누르지만, 입력창에서 엔터를 치면 제출은 그대로 일어나거든요. 빈 댓글이 달리는 걸 막아줍니다.

// apps/web-spa/src/components/CommentForm.tsx
import { useState } from 'react';

interface CommentFormProps {
  onSubmit: (content: string) => void;
}

export function CommentForm({ onSubmit }: CommentFormProps) {
  const [content, setContent] = useState('');
  const isEmpty = content.trim() === '';

  function handleChange(event: React.ChangeEvent<HTMLInputElement>) {
    setContent(event.target.value);
  }

  function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
    event.preventDefault();
    if (isEmpty) {
      return;
    }
    onSubmit(content.trim());
    setContent('');
  }

  return (
    <form className="comment-form" onSubmit={handleSubmit}>
      <input
        className="comment-input"
        value={content}
        onChange={handleChange}
        placeholder="댓글 달기..."
        aria-label="댓글 입력"
      />
      <button className="comment-submit" type="submit" disabled={isEmpty}>
        게시
      </button>
    </form>
  );
}

JSX가 훨씬 읽기 좋아졌습니다. 폼이 무엇을 그리는지와 제출될 때 무슨 일이 일어나는지가 나뉘었어요.

마우스 이벤트로 더블클릭 좋아요 만들기

인스타그램에는 사진을 두 번 두드리면 좋아요가 눌리는 동작이 있는데, 이제 우리도 만들 수 있습니다.

// apps/web-spa/src/components/PostCard.tsx
function handleImageDoubleClick(event: React.MouseEvent<HTMLImageElement>) {
  // 더블클릭이 이미지를 선택 상태로 만드는 브라우저 기본 동작을 막는다
  event.preventDefault();
  onToggleLike(id);
}

<img
  className="post-image"
  src={imageUrl}
  alt={`${username} 의 게시물`}
  onDoubleClick={handleImageDoubleClick}
/>

클릭 계열 사건이 이미지에서 났으니 MouseEvent와 HTMLImageElement입니다. 지난 시간에 만들어 둔 onToggleLike를 그대로 부르기 때문에, 버튼으로 누르든 사진을 두드리든 같은 상태를 건드립니다.

이름 짓는 규칙은 하나뿐

이벤트 타입은 종류가 많지만 형태는 전부 같습니다.

외울 필요는 없습니다. 요소 이름을 모르겠으면 JSX 안에 인라인으로 한 번 써 보세요. 에디터가 추론해서 보여주는 타입을 그대로 복사해 밖으로 옮기면 됩니다.

요소를 틀리게 적으면 어디서 걸릴까

HTMLInputElement 자리에 엉뚱한 요소를 적었다고 해봅시다. 재미있는 것은 에러가 뜨는 위치예요.

error TS2322: Type '(event: ChangeEvent<HTMLFormElement, Element>) => void' is not
assignable to type 'ChangeEventHandler<HTMLInputElement, HTMLInputElement>'.

핸들러를 정의한 곳이 아니라 그 핸들러를 onChange에 붙이는 곳에서 걸립니다. 함수 자체는 그것대로 말이 되는 함수니까요. 문제는 그 함수를 입력창에 붙일 수 없다는 것이고, TypeScript는 붙이려는 순간에 그 사실을 말해줍니다.

💡 한 줄 정리

이벤트 타입은 React.{무슨 사건}Event<{어느 요소}> 한 가지 형태입니다. 요소를 잘못 적으면 핸들러를 정의한 곳이 아니라 JSX에 붙이는 곳에서 걸립니다.

error TS2339: Property 'value' does not exist on type 'EventTarget'.

Step 3: "함수를 props로 받을 때"

지금까지는 컴포넌트가 자기 안에서 쓰는 핸들러에 타입을 달았는데, 함수는 props를 타고 컴포넌트 사이를 오가기도 하죠. 지난 시간에 이미 그렇게 썼어요.

// apps/web-spa/src/components/CommentForm.tsx
interface CommentFormProps {
  onSubmit: (content: string) => void;
}

(content: string) => void는 함수의 모양을 적은 타입입니다. 문자열 하나를 받고 아무것도 안 돌려준다는 뜻이에요. 화살표 왼쪽이 받는 것, 오른쪽이 돌려주는 것입니다.

돌려줄 게 없을 때 쓰는 void가 눈에 띌 겁니다. 부모가 이 함수로 무엇을 하든 자식은 관심이 없다는 선언이에요. 자식은 그저 "댓글이 달렸다" 고 알리기만 하고, 그 뒤에 무슨 일이 일어날지는 부모가 정합니다.

지난 시간의 의문 하나

LikeButton을 다시 봅시다.

// apps/web-spa/src/components/LikeButton.tsx
interface LikeButtonProps {
  liked: boolean;
  likeCount: number;
  onToggle: () => void;
}

onToggle은 아무것도 안 받는 함수지만, 이걸 버튼에 그대로 넘겼어요.

<button onClick={onToggle}>

onClick은 함수를 부를 때 이벤트 객체를 하나 넘겨줍니다. 그런데 아무것도 안 받는 함수를 넣었는데도 통과했어요. 왜일까요.

넘겨주는 쪽이 인자를 하나 준다고 해서 받는 쪽이 반드시 받아야 하는 건 아니기 때문입니다. 안 쓸 거면 안 받아도 돼요. 반대로 받는 쪽이 요구하는 것보다 적게 주는 것은 안 됩니다.

 onClick 이 부를 때:  handler(event)

 () => void          받기로 한 게 없다 → event 를 그냥 흘려보낸다 → 통과
 (e: MouseEvent) => void   받기로 한 걸 받는다 → 통과
 (a, b) => void      두 번째 인자를 아무도 안 준다 → 거절

JavaScript에서 인자를 덜 받는 함수를 부르는 건 원래 자연스러운 일이고, 타입도 그 사실을 그대로 따릅니다. 덕분에 이벤트 객체가 필요 없는 핸들러는 매개변수를 아예 안 적어도 됩니다. 실제로 클릭 핸들러 대부분이 이벤트 객체를 안 씁니다.

준비된 이름을 쓰는 방법

이벤트 핸들러의 모양은 워낙 자주 쓰여서 React가 이름을 미리 만들어 뒀습니다.

// apps/web-spa/src/components/CommentInput.tsx — Step 7 에서 만들 입력창 컴포넌트
interface CommentInputProps {
  value: string;
  onChange: React.ChangeEventHandler<HTMLInputElement>;
}

React.ChangeEventHandler<HTMLInputElement>는 (event: React.ChangeEvent<HTMLInputElement>) => void와 똑같은 뜻입니다. 짧아지죠. 이 컴포넌트는 Step 7에서 실제로 만듭니다.

소괄호 하나가 만드는 사고

지난 시간에 함수를 넘기는 것과 부르는 것을 구분했습니다. props로 넘길 때도 똑같은 실수가 나옵니다.

<LikeButton onToggle={handleToggle()} />

error TS2322: Type 'void' is not assignable to type '() => void'.

handleToggle()은 함수를 실행한 결과이고 그 결과는 void입니다. props는 나중에 부를 함수를 원했는데 이미 실행해 버린 뒤의 빈손을 받은 거예요. 함수 타입을 적어두면 이런 실수가 화면을 열어보기 전에 잡힙니다.

💡 한 줄 정리

props로 받는 함수는 (받는 것) => 돌려주는 것으로 적습니다. 받기로 한 것보다 적게 받는 함수는 그 자리에 들어갈 수 있어서, 이벤트가 필요 없는 핸들러는 매개변수를 안 적어도 됩니다.

Step 4: "props 타입을 짓는 세 가지 길"

지금 우리 코드베이스에는 props 타입이 세 가지 방식으로 만들어져 있습니다. 지금까지 그때그때 편한 대로 썼는데, 오늘 기준을 세우고 갑시다.

첫째, 새로 선언한다

// apps/web-spa/src/components/Avatar.tsx
interface AvatarProps {
  username: string;
  profileImageUrl: string;
}

Avatar가 필요한 것만 손으로 적었습니다. 짧고, 이 컴포넌트가 무엇을 요구하는지 한눈에 보여요.

둘째, 원본에서 파생시킨다

// apps/web-spa/src/types/derived.ts
export type PostCardProps = Omit<Post, 'hashtagNames' | 'createdAt'>;

A-3에서 만든 타입입니다. Post에서 카드가 안 쓰는 두 개를 빼고 나머지를 그대로 씁니다. 백엔드가 Post에 필드를 하나 추가하면 이쪽도 자동으로 따라와요.

셋째, 있는 것을 확장한다

// apps/web-spa/src/components/PostCard.tsx
interface PostCardViewProps extends PostCardProps {
  onToggleLike: (id: number) => void;
}

지난 시간에 만든 것입니다. 서버가 준 데이터는 PostCardProps 그대로 두고, 화면에서만 필요한 콜백을 얹었어요.

무엇을 언제 쓰나

기준을 한 문장으로 줄이면 이렇습니다. 그 props가 서버 데이터의 일부인가, 화면이 만들어낸 값인가. 서버에서 온 것은 원본에서 파생시키고, 화면이 만들어낸 것은 손으로 적습니다. PostCardViewProps가 정확히 이 둘을 나눠 담고 있어요.

interface와 type 중 무엇을 쓸지도 같은 결론입니다. A-1에서 정한 대로 공개되는 객체 모양은 interface, 유틸리티 타입으로 만든 것은 type입니다. extends로 얹을 일이 있으면 interface가 편해요.

💡 한 줄 정리

서버 데이터에서 온 props는 원본 타입에서 파생시키고, 화면이 만들어낸 props는 새로 적습니다. 둘이 섞이면 extends로 나눠 담습니다.

Step 5: "컴포넌트를 함수로 선언하는 이유"

여기까지 우리가 만든 컴포넌트는 전부 같은 모양이었습니다.

function 이름({ 구조분해 }: Props) {
  return (JSX);
}

너무 당연해 보이지만, 사실 이건 선택의 결과입니다. 예전에는 다른 방식이 표준에 가까웠고, 지금도 오래된 코드나 조금 지난 블로그 글에서는 그쪽을 자주 만나게 될 거예요.

예전 방식

React.FC라는 타입이 있습니다. Function Component의 줄임말이고, 컴포넌트를 변수에 담으면서 그 변수에 이 타입을 붙이는 방식이었어요. 이름을 알아둬야 하는 이유는 하나입니다. 남의 코드에서 봤을 때 "아, 옛날 방식이구나" 하고 알아보기 위해서요. 새로 쓸 일은 없습니다.

밀려난 이유는 세 가지입니다.

첫째, children이 자동으로 딸려왔습니다. 자식을 받을 생각이 없는 컴포넌트에도 자식을 넘길 수 있었어요. props에 안 적은 것이 들어온다는 뜻이라 타입이 거짓말을 하는 셈이었습니다. 이 문제는 지금은 고쳐졌지만, 고치는 과정에서 버전마다 동작이 달라져 혼란이 컸습니다.

둘째, 제네릭 컴포넌트를 만들기가 까다로웠습니다. 어떤 타입의 목록이든 받아 그리는 컴포넌트 같은 것을 말해요. 변수에 타입을 붙이는 형태라 타입 매개변수를 얹을 자리가 마땅치 않았습니다. 이건 다음 시간에 직접 만들어 봅니다.

셋째, 함수 선언의 장점을 버려야 했습니다. function으로 선언하면 파일 안 어디에 두든 위에서 쓸 수 있고, 스택 트레이스에 이름이 제대로 찍히고, 에러 메시지도 짧습니다.

지금은 함수로 선언하고 매개변수에 타입을 붙이는 방식이 표준인데, 우리가 처음부터 써온 그대로예요.

반환 타입은 적지 않습니다

함수를 배울 때 반환 타입을 적으라고 배웠으니 이렇게 쓰고 싶어질 수 있습니다.

export function Avatar({ username }: AvatarProps): JSX.Element {

그런데 이건 아예 컴파일이 안 됩니다.

error TS2503: Cannot find namespace 'JSX'.

예전에는 JSX라는 이름이 전역에 열려 있었지만 React 19의 타입 정의에서는 React 안쪽으로 들어갔습니다. 그래서 굳이 적으려면 React.JSX.Element라고 써야 해요.

하지만 적지 않는 쪽을 권합니다. 컴포넌트가 무엇을 돌려주는지는 return 문만 봐도 뻔하고, TypeScript가 알아서 정확하게 추론합니다. A-3에서 이야기했듯 애너테이션은 추론이 못 하거나 틀리게 하는 곳에만 붙이는 것이 좋아요. 여기는 둘 다 아닙니다.

💡 한 줄 정리

컴포넌트는 function으로 선언하고 매개변수에 props 타입을 붙입니다. 반환 타입은 추론에 맡깁니다.

function Avatar({ username }: AvatarProps) {
  return <span>{username}</span>;
}

const Avatar = ({ username }: AvatarProps) => {
  return <span>{username}</span>;
};

Step 6: "children을 명시로 받기"

지금까지 컴포넌트에 값을 넘길 때는 항상 속성을 썼는데, HTML을 떠올려 보면 태그 사이에 내용을 넣는 방식도 있죠.

<section>
  <p>여기가 내용입니다</p>
</section>

React 컴포넌트도 똑같이 쓸 수 있습니다. 피드 위에 제목을 붙이는 껍데기를 하나 만들어 봅시다.

// apps/web-spa/src/components/Section.tsx

interface SectionProps {
  title: string;
  children: React.ReactNode;
}

export function Section({ title, children }: SectionProps) {
  return (
    <section className="section" aria-label={title}>
      <h2 className="section-title">{title}</h2>
      {children}
    </section>
  );
}

children은 React가 정해둔 특별한 이름입니다. 태그 사이에 넣은 것이 이 이름으로 들어와요. 나머지는 우리가 아는 props와 똑같습니다. props 목록에 적고, 구조분해로 꺼내고, JSX 안에서 중괄호로 그립니다.

App에서 이렇게 씁니다.

// apps/web-spa/src/App.tsx
<Section title="피드">
  <Feed posts={posts} onToggleLike={handleToggleLike} />
</Section>

<Section>과 </Section> 사이에 넣은 <Feed />가 children으로 넘어가서 제목 아래에 그려집니다.

ReactNode는 넓은 타입입니다

React.ReactNode는 화면에 그릴 수 있는 거의 모든 것을 받습니다.

 React.ReactNode 가 받는 것

 <Feed />              컴포넌트
 <p>글자</p>            HTML 요소
 "그냥 문자열"          문자열
 42                    숫자
 [<A />, <B />]        위 것들의 배열
 null · undefined      아무것도 안 그린다

 못 받는 것: { username: 'jaehoon' } 같은 순수 객체

넓은 이유는 분명합니다. 태그 사이에 뭐가 올지는 쓰는 사람 마음이니까요. 숫자나 문자열을 그대로 넣어도 되고, 조건에 따라 null을 넣어 아무것도 안 그릴 수도 있습니다.

순수 객체만 막혀 있는데, 이건 React가 화면에 어떻게 그려야 할지 모르기 때문입니다. 실수로 객체를 넣으면 이렇게 알려줘요.

error TS2353: Object literal may only specify known properties, and 'username'
does not exist in type 'ReactElement<...> | Iterable<ReactNode> | ReactPortal | ...'

안 적으면 못 받습니다

여기가 중요합니다. props에 children을 안 적어두면 자식을 넘길 수 없어요.

interface BadgeProps {
  label: string;
}

export function Badge({ label }: BadgeProps) {
  return <span className="badge">{label}</span>;
}

이 컴포넌트에 자식을 넣으면 이렇게 막힙니다.

error TS2322: Type '{ children: string; label: string; }' is not assignable to type
'IntrinsicAttributes & BadgeProps'.
  Property 'children' does not exist on type 'IntrinsicAttributes & BadgeProps'.

불편해 보이지만 이게 맞습니다. Badge는 자식을 그릴 방법이 없거든요. 넘겨봐야 화면에 안 나옵니다. 조용히 사라지는 대신 미리 막아주는 편이 훨씬 낫죠. 앞 Step에서 이야기한 예전 방식의 문제가 정확히 이것이었습니다.

자식을 받고 싶으면 받겠다고 적으면 됩니다. 그것뿐이에요.

💡 한 줄 정리

태그 사이의 내용은 children이라는 이름으로 들어옵니다. children: React.ReactNode를 props에 적어둔 컴포넌트만 자식을 받을 수 있습니다.

Step 7: "ref를 props로 받기"

마지막 입구입니다. 지금까지는 값이 들어오기만 했는데, 이번에는 컴포넌트 안의 실제 DOM 요소를 밖으로 꺼내 봅니다.

이유가 있어요. 지금 댓글을 달고 나면 입력창에서 커서가 사라집니다. 연달아 댓글을 쓰려면 매번 입력창을 다시 눌러야 해요. 인스타그램은 안 그렇죠.

커서를 옮기는 일은 값을 바꿔서 할 수 없습니다. 실제 <input> 요소를 붙잡고 focus()를 불러야 해요. 그 붙잡는 손잡이가 ref입니다.

입력창을 별도 컴포넌트로 떼어냅니다

// apps/web-spa/src/components/CommentInput.tsx

interface CommentInputProps {
  value: string;
  onChange: React.ChangeEventHandler<HTMLInputElement>;
  ref: React.Ref<HTMLInputElement>;
}

export function CommentInput({ value, onChange, ref }: CommentInputProps) {
  return (
    <input
      className="comment-input"
      ref={ref}
      value={value}
      onChange={onChange}
      placeholder="댓글 달기..."
      aria-label="댓글 입력"
    />
  );
}

ref를 다른 props와 똑같이 받아서 <input>에 그대로 넘겼습니다. 특별할 게 없어 보이죠. 이게 React 19의 변화입니다.

타입은 React.Ref<HTMLInputElement>예요. 앞에서 배운 규칙이 그대로 통합니다. 무엇을 가리키는 손잡이인지를 꺾쇠 안에 적습니다.

예전에는 특별 취급이었습니다

ref는 오랫동안 일반 props가 아니었습니다. 컴포넌트에 ref를 넘기면 React가 중간에서 가로챘고, 자식에게 전달하려면 forwardRef라는 함수로 컴포넌트를 한 겹 감싸야 했는데, 그 바람에 컴포넌트 모양이 달라지고 타입도 복잡해졌습니다.

React 19부터는 감쌀 필요가 없습니다. ref가 그냥 props가 됐어요. forwardRef는 아직 동작하지만 쓸 이유가 없고, React 팀도 앞으로 걷어낼 예정이라고 밝혔습니다. 오래된 코드에서 만나면 "이건 옛날에 필요했던 껍데기구나" 하고 알아보면 됩니다.

부모가 손잡이를 만들어 넘깁니다

// apps/web-spa/src/components/CommentForm.tsx
import { useRef, useState } from 'react';
import { CommentInput } from './CommentInput';

interface CommentFormProps {
  onSubmit: (content: string) => void;
}

export function CommentForm({ onSubmit }: CommentFormProps) {
  const [content, setContent] = useState('');
  const inputRef = useRef<HTMLInputElement>(null);
  const isEmpty = content.trim() === '';

  function handleChange(event: React.ChangeEvent<HTMLInputElement>) {
    setContent(event.target.value);
  }

  function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
    event.preventDefault();
    if (isEmpty) {
      return;
    }
    onSubmit(content.trim());
    setContent('');
    inputRef.current?.focus();
  }

  return (
    <form className="comment-form" onSubmit={handleSubmit}>
      <CommentInput ref={inputRef} value={content} onChange={handleChange} />
      <button className="comment-submit" type="submit" disabled={isEmpty}>
        게시
      </button>
    </form>
  );
}

useRef로 빈 손잡이를 만들어 CommentInput에 넘깁니다. React가 실제 <input>을 그리고 나면 그 요소를 inputRef.current에 넣어줘요.

inputRef.current?.focus()의 물음표를 보세요. 아직 화면에 안 그려졌을 수도 있어서 current는 비어 있을 수 있습니다. A-2에서 배운 좁히기가 여기서 쓰입니다. 있을 때만 focus()를 부르는 거예요.

댓글을 달면 이제 커서가 입력창에 남아서 연달아 쓸 수 있어요.

 상태로 하는 일                    ref 로 하는 일

 값이 바뀌면 화면을 다시 그린다      화면을 다시 그리지 않는다
 무엇을 보여줄지 정한다             이미 그려진 요소를 직접 만진다

 예) 입력값·좋아요·댓글 목록        예) 커서 옮기기·스크롤 위치·재생 정지

경계는 이렇게 잡으면 됩니다. 화면에 보이는 내용이 달라지면 상태, 화면은 그대로인데 브라우저에 뭔가 시켜야 하면 ref입니다. ref를 상태 대신 쓰면 값이 바뀌어도 화면이 안 따라오니 조심하세요.

💡 한 줄 정리

React 19에서 ref는 일반 props입니다. ref: React.Ref<HTMLInputElement>로 받아 안쪽 요소에 넘기면, 부모가 그 요소를 직접 만질 수 있습니다.

error TS2322: Type 'Ref<HTMLInputElement>' is not assignable to type
'Ref<HTMLTextAreaElement> | undefined'.

마무리

오늘 컴포넌트의 입구를 하나씩 열어봤습니다. props로 값이 들어오고, 이벤트로 사용자의 동작이 들어오고, children으로 다른 화면 조각이 들어오고, ref로 요소가 나갑니다. 네 개 다 타입으로 적었어요.

지난 세 번의 TypeScript 시간이 데이터의 모양을 그리는 일이었다면 오늘은 그 타입이 화면과 만나는 지점을 다뤘습니다. Post라는 타입 하나가 PostCardProps로 파생되고, 그게 다시 컴포넌트의 입구가 되어 화면까지 이어졌어요.

오늘 배운 핵심 세 가지

💡 하나 — 문맥이 없으면 타입을 직접 적습니다. JSX 속성에 바로 쓴 화살표 함수는 이벤트 타입을 물려받지만, 이름 붙여 밖으로 뺀 함수는 그 연결이 끊깁니다. 그래서 React.{무슨 사건}Event<{어느 요소}>를 적어줍니다.

💡 둘 — props 타입은 출처를 따라 짓습니다. 서버 데이터에서 온 것은 원본에서 파생시키고, 화면이 만들어낸 것은 새로 적습니다. 둘이 섞이면 extends로 나눠 담아요. 기준은 이름이 같은지가 아니라 함께 바뀔 운명인지입니다.

💡 셋 — 안 적은 것은 못 받습니다. children도 ref도 props에 적어둔 컴포넌트만 받을 수 있습니다. 불편해 보여도 이게 맞아요. 받을 방법이 없는 것이 조용히 넘어와 사라지는 것보다 낫습니다.

다음 시간 예고

오늘 Section을 만들면서 자식을 받는 껍데기를 처음 써봤는데, 자식을 받을 곳이 하나뿐이라 제목과 본문 정도만 나눌 수 있었어요. 실제 화면에는 머리말과 꼬리말이 따로 있는 카드, 눌러야 열리는 패널처럼 자식을 여러 갈래로 받아야 하는 껍데기가 많습니다.

다음 시간에는 컴포넌트를 조립해서 화면을 만드는 방법을 배웁니다. 큰 컴포넌트를 언제 쪼개야 하는지, 쪼갠 것들을 어떻게 다시 합칠지가 주제예요.

그리고 오늘 CommentForm 안에 useState와 useRef와 핸들러 두 개가 함께 들어갔습니다. 지난 시간 LikeButton에서도 비슷한 묶음을 봤죠. 이렇게 반복되는 묶음을 통째로 뽑아 이름을 붙이는 방법도 함께 다룹니다.

과제

[구현] 댓글 입력창에 글자 수 세기

CommentInput 아래에 지금 몇 글자를 썼는지 보여주고, 너무 길면 못 쓰게 막아 주세요.

요구사항은 다음과 같습니다.

• apps/web-spa/src/components/CommentCounter.tsx에 CommentCounter 컴포넌트를 만들어 주세요. 지금 글자 수와 최대 글자 수를 props로 받습니다.
• 최대 글자 수는 100 자로 하고, CommentForm이 넘겨줍니다. CommentCounter 안에 숫자를 적어두지 마세요.
• 남은 글자가 10 자 이하로 떨어지면 눈에 띄게 보여 주세요.
• 100 자를 넘기면 게시 버튼이 안 눌리게 해주세요. 지금 빈 값을 막는 것과 같은 방식으로 하면 됩니다.
• CommentForm의 핸들러는 전부 이름 붙인 함수로 두고, 이벤트 타입을 명시해 주세요.
• Section을 써서 피드 제목 아래에 카드가 들어가는 구조는 그대로 유지해 주세요.

다 만들고 나면 npm run typecheck -w web-spa와 npm run lint -w web-spa를 돌려 둘 다 통과하는지 확인해 주세요.

useMemo 나 useCallback은 쓰지 마세요. 아직 안 배웠고, 오늘 배운 것만으로 충분히 됩니다.

[탐구] 타입을 일부러 어겨보기

아래 여섯 가지를 하나씩 시도해 보고, 에디터가 뭐라고 하는지와 그게 무슨 뜻인지 한 줄씩 적어 주세요.

• handleChange의 React.ChangeEvent<HTMLInputElement>에서 꺾쇠 안을 HTMLFormElement로 바꿔보기
• 더블클릭 핸들러 안에 console.log(event.currentTarget.src)를 넣어보고, 그 다음 event.target.src로 바꿔보기
• Avatar의 반환 타입에 : JSX.Element를 적어보기
• Badge처럼 children을 안 받는 컴포넌트에 자식 넘겨보기
• CommentInput에 넘기는 inputRef를 <textarea>에 달아보기
• <LikeButton onToggle={handleToggle} />을 onToggle={handleToggle()}로 바꿔보기

특히 첫 번째와 두 번째를 비교해 보세요. 하나는 핸들러를 붙이는 곳에서 걸리고 다른 하나는 핸들러 안에서 걸립니다. 왜 걸리는 위치가 다른지 생각해 보세요.

생각해볼 주제

1. 타입을 파생시킬 것인가 새로 적을 것인가

오늘 PostCardProps는 Post에서 파생시켰고 AvatarProps는 새로 적었습니다. 기준으로 "함께 바뀔 운명인가"를 제시했죠.

그런데 실무에서는 이 판단이 처음부터 명확한 경우가 드뭅니다. 지금은 게시물에만 쓰이지만 나중에 다른 화면에도 쓰일지 모르는 컴포넌트라면 어느 쪽으로 시작하시겠어요. 나중에 방향을 바꿔야 할 때 어느 쪽에서 어느 쪽으로 옮기는 게 더 쉬울지도 함께 생각해 보세요.

2. 이벤트 타입을 매번 적는 비용

오늘 핸들러를 밖으로 뺄 때마다 타입을 적었습니다. 인라인으로 두면 안 적어도 되는데 말이죠.

그렇다면 짧은 핸들러는 계속 인라인으로 두는 게 나을까요. 아니면 길이와 상관없이 밖으로 빼는 규칙을 정하는 게 나을까요. 타입을 적는 수고 말고도 두 방식은 읽기 쉬움이나 컴포넌트가 다시 그려질 때의 동작에서 차이가 납니다. 어떤 기준으로 정하시겠어요.

3. ref가 일반 props가 된 것

React 19는 ref를 특별 취급하던 규칙을 없애고 보통의 props로 만들었습니다. 감싸는 껍데기가 사라져서 코드는 확실히 짧아졌어요.

특별 취급에는 특별 취급 나름의 쓸모가 있었을 수도 있는데, 문법적으로 눈에 띄면 "여기서 DOM을 직접 만지는구나" 하고 알아채기 쉬웠을 테니까요. 쉬워진 것과 눈에 덜 띄게 된 것 사이에서 무엇을 얻고 무엇을 잃었을까요.