[⚛️ React Conf 2024] 리액트 19에서 새로워진 것들 (What's new in React 19 | Lydia Hallie)

2024 REACT CONF

What's new in React 19 | Lydia Hallie

약 2 달 전에 REACT CONF 2024가 열렸다.
여러 토크들이 진행되었었는데, 그중 따끈 따근(?)한 React 19의 새 소식들을 살펴보고자 한다.
canary 버전의 리액트를 쓰고 있었다면 소개할 내용들이 이미 익숙한 것들일 수 있지만,
안정화된 버전을 기다린 나와 같은 사람들은 해당 토크에서 반가운 소식들을 전해 들을 수 있을 거 같다.
이번에는 간단하게 어떤 것들이 달라졌나 살펴보고, 실제로 소개된 19 버전의 기능들을 사용해 보고자 한다.
👇 다룬 주제 목차로 살펴보기

1. Asynchoronous transitions: startTransition에 async 함수를 전달하기
2. Actions:  transition을 트리거하는 함수들
3. useActionState:  훅을 통한 action 생성
4. action and formAction props : form, button, input 등과 action 함께 쓰기
5. useFormStatus : 더 쉽게 action의 form status에 접근하기
6. React Server Components : 클라이언트 환경 외에서 리액트 컴포넌트 랜더
7. use:  promise의 resolved 값이나 context의 값 읽기
8. Server Actions:  서버에서 run 하는 함수 클라이언트에서 call 하기
> 리액트 19부터 개선된 사항들
9.  ref as prop:  함수형 컴포넌트에서 prop으로 ref 접근
10.  Document metadata:  컴포넌트 내에서 직접 metadata 사용하기
11.  Stylesheet support:  컴포넌트 내에서 직접 stylesheet 사용하기
12. Preloading API: 컴포넌트 내에서 preload, preconnect, preinit, prefetchDNS 등 사용

한 눈에 보는 react 19에서 새로워진 것들

 

1. Asynchoronous transitions: startTransition에 async 함수를 전달하기

startTransition은 리액트 18에서 소개되었다.

transition을 통해서 상대적으로 urgent 한 state들을 마킹할 수 있게 되었다.

다음과 같이 urgent한 데이터를 setUrgentState으로 감싸주면 된다.

const [isPending, startTransition] = useTransition();

function handleData(){
	setUrgentState(urgentData);
    startTransition(()=>{
    	setNonUrgentState(nonUrgentData);
    })
}

 

리액트는 기본적으로 필요로 하는 모든 컴포넌트들을 하나의 과정으로 랜더 한다.

 

하지만 업데이트의 복잡도에 따라 리액트가 실제로 랜더를 마치고 이 업데이트를 DOM에 커밋하기까지의 시간이 달라질 수 있다.

문제는 이 랜더와 커밋의 과정이 메인 thread에서 진행되기 때문에, 우리의 애플리케이션은 어떠한 다른 태스크들을 처리할 수 없는 상태가 된다. 사용자들은 이때 무반응한 UI를 마주하게 되는 안 좋은 경험을 할 수 있다.

즉, 리액트가 랜더를 하고 DOM에 변화를 커밋하려는 도중에 사용자가 웹사이트에서 어떤 상호작용을 하고자 한다면,

피드백이 지연되는 현상이 발생하게 된다.

 

이 때 transition 훅을 사용하면 용이하다.

transition을 사용하면 하나의 방해받지 않은 업데이트 대신, 

리액트는 매 5ms 마다 메인 thread에게 제어권을 넘겨줘서 처리되어야 하는 태스크들이 있는지 확인한다.

 

예를 들면, 다음과 같이 메인 thread에 태스크들이 있다고 할 때, 
리액트는 현재 렌더를 중지하고, 브라우저가 먼저 태스크를 처리하도록 순서를 양보한 뒤, 처리가 완료되면 렌더 작업을 마저 한다.

커밋 작업은 이후, 가장 효율적일 때 진행한다.

 

아래처럼 input 값을 form에 입력하여 제출하는 경우가 종종 있다.

// ...중략...
const [name, setName] = useState('');
const [data, setData] = useState(null);
const [isPending, setIsPending] = useState(false);

async function handleSubmit(){
	setIsPending(true);	// isPending을 true로 설정 시 리액트가 리랜더를 시킨다
    const data = await updateData(name);
    setIsPending(false);
    setData(data);
}

return (
	<div>
    	<input onChange={e => setName(e.target.value)}/>
        <button onClick={handleSubmit}>
        	{isPending? "Updating..." : "Update"}
        </button>
        <span>{data?.success && "Changes saved!"}</span>
    </div>
)

// ...중략...

 

이 방식이 틀린 건 아니지만, 해당 방식은 다음과 같은 문제가 생길 수 있다. 

 

사용자가 "Lydia"라고 입력하고 updateDate 제출이 발생하고 있는 동안, 다시 사용자가 "Evan"이라고 입력하고 updateDate 제출을 할 수 있다.

 

네트워크 요청이 끝나고 data 가 리턴되었을 때, setData로 UI에 데이터를 보여주게 될 경우, 

사용자 입장에서는 가장 최신에 입력했던 이름이 Evan이었기 때문에 Evan으로 뜰 거라고 기대했을 수도 있다.

하지만 실제로는 Lydia에 대한 데이터 요청이 끝난 뒤, 해당 데이터로 업데이트가 발생하고,

Evan에 대한 요청이 끝나야지만 해당 정보로 UI가 업데이트된다.

 

뿐만 아니라 데이터를 다루기 위한 boilerplate 코드(에러처리 등등까지 포함 등등)가 장황하게 느껴질 수 있다.

transition을 사용해 다음과 같이 수정해 보자.

// ...중략...
const [name, setName] = useState('');
const [data, setData] = useState(null);
// const [isPending, setIsPending] = useState(false);
// 수정
const [isPending, startTransition] = useTransition();

async function handleSubmit(){
	// setIsPending(true);	
    // const data = await updateData(name);
    // setIsPending(false);
    // setData(data);
	startTransition(async () => {
    	const data = await updateData(name);
    	startTransition(async () => {
    		setData(data);
    	})
    })
}

return (
	<div>
    	<input onChange={e => setName(e.target.value)}/>
        <button onClick={handleSubmit}>
        	{isPending? "Updating..." : "Update"}
        </button>
        <span>{data?.success && "Changes saved!"}</span>
    </div>
)

// ...중략...

 

다만 현재의 limitation으로는 startTransition 안의  await 키워드 이후의 state 업데이트는 아직 디폴트로 transition으로 마킹되어 있지 않기 때문에 다시 startTransition를 감싸줘야 한다. (async context가 사용가능해지기 전까지는!)

 

transition으로 코드를 변경 후, 다시 Lydia를 입력하고 제출하고 있는 도중에 Evan을 입력하고 제출하는 상황을 살펴보자.

이번에는 위의 상황과는 달리 Evan에 관한 데이터만 하나만 화면에 렌더 된다.

 

이는 여러 개의 transition이 진행 중이라면, 리액트는 이 transition들을 batch 하고,

모든 transition이 종료된 이후에야만 commit을 하기 때문이다. 따라서 하나의 페인트인 'Evan'만 발생한다.

 

2. Actions:  transition을 트리거하는 함수들

3. useActionState:  훅을 통한 action 생성

 

useActionState은 리액트 19에서 새롭게 등장한 훅이다.

action을 사용하고, transition 중 status 업데이트들에 접근하고, 접근한 state들로 state을 설정하기에 용이한 훅이다.

 

useActionState 훅이 어떻게 구성되어 있는지 살펴보자.

 

• useActionState는 세 개의 값을 배열로 리턴한다. 각각의 값을 살펴보자.
  • state: useActionState의 두 번째 인자로 넘겨준 initialState(위의 경우 null), 또는 action 후 리턴되는 데이터 값
  • action : useActionState의 첫 번째 인자로 넘겨준 action 함수 리턴. transition을 trigger 하도록 값을 사용할 수 있다.
  • isPending: transition이 시작하자마자 true값을 지닌다. transition이 dom에 commit 되면 자동적으로 false값이 된다.

 

이번에는 이전에 useTransition으로 리펙토링 했던 코드를 useActionState을 활용해 리펙토링 해보자.

이전에는 transition state를 직접 업데이트해 줄 필요는 없어졌지만, 여전히 직접 state 업데이트를 해줬어야 했다.

// ...중략...
// const [name, setName] = useState('');
// const [data, setData] = useState(null);
// const [isPending, startTransition] = useTransition();

// 수정
const [isPending, startTransition] = useActionState(
	async(currentState, formData)=>{
    	const name = await formData.get('name');
        const data = await updateDate(name);
        return data;
    },
    null
);

// async function handleSubmit(){
	// setIsPending(true);	
    // const data = await updateData(name);
    // setIsPending(false);
    // setData(data);
	// startTransition(async () => {
    //	const data = await updateData(name);
    //	startTransition(async () => {
    //		setData(data);
    //	})
    // })
// }

return (
	{/**<div>
    	<input onChange={e => setName(e.target.value)}/>
        <button onClick={handleSubmit}>
        	{isPending? "Updating..." : "Update"}
        </button>
        <span>{data?.success && "Changes saved!"}</span>
    </div> */}
    <form action={action}>
    	<input name='name'/>
         <button onClick={handleSubmit}>
        	{isPending? "Updating..." : "Update"}
        </button>
        <span>{data?.success && "Changes saved!"}</span>
    </form>
)

// ...중략...

 

useActionState으로 더 이상 여러 개의 데이터 state가 불필요해졌고,

formData의 name으로 접근할 수 있어져서 코드가 더 깔끔해졌다.

4. action and formAction props : form, button, input 등과 action 함께 쓰기

리액트 dom은 action과 formAction 프롭스로 직접 action을 사용할 수 있도록 한다.

 

action 또는 formAction으로 프롭스로 전달한 함수는 async일 수도 있고 아닐 수도 있다.

다만 전달한 함수는 모두 action이다. (transition을 trigger 한다)

 

5. useFormStatus : 더 쉽게 action의 form status에 접근하기

 

직전에 제출한 form의 status에 더 쉽게 접근할 수 있다.

useFormStatus 훅은 다음과 같은 객체를 리턴한다.

• data: 현재 제출한 form 데이터
• pending: transition의 pending state 

다음의 예시를 살펴보자.

useFormStatus 훅은 useContext처럼 action 데이터를 사용한다. 

즉, useActionState를 사용하고 있는 상위(부모) 컴포넌트로 감싸준 하위의 컴포넌트들은

action 데이터의 콘텍스트를 사용할 수 있게 된다.

function Form(){
	const [data, action] = useActionState();
    return (<form>
    	<input name="name"/>
        <StyledButton/>
        <span>{data.success && "Changes saved!"}</span>
    </form>)
}

function StyledButton(){
	const {pending} = useFormStatus();
    return (<button style={...}>
    	{pending? "Updating...": "Updaate"}
    </button>)
}

 

context와 유사하게, 실제로 form을 랜더 하는 컴포넌트(부모 컴포넌트)가 아닌 자식 컴포넌트에서 호출해야 한다.

6. useOptimistic : action이 완료되기 전에 UI를 optimistic 하게 업데이트하기

 

action 안에 async 태스크가 데이터를 리턴을 하기까지 생각보다 많은 시간이 소요될 수도 있고 유저들이 느린 인터넷 커넥션을 사용 중일 수도 있다. 이럴 경우 isPending의 상태를 보여주기보다는 이미 action이 완료된 것 같은 상태를 보여주고 싶을 수도 있다.

이미 action이 완료된 상태를 보여주려면 어떤 데이터가 리턴될 건지 알아야 하는데 어떻게 하면 될까?

 

이때 useOptimistic 훅으로 리턴된 함수를 통해 transition이 완료되기 전에 UI를 업데이트할 수 있다.

 

 

useOptimistic 훅은 다음의 값들을 배열로 리턴한다.

• allValues:  리턴한 배열의 첫 인덱스에는 현재 state이다. action 이 pending 중이 아니라면 initial state를, pending 중이라면 update 함수로 리턴한 값 ([... currentState, optimisticValue])을 지닌다.
• update 함수: (currentState, optimisticValue) =>{return [...currentState, optimisticValue]} 에 해당하는 실제 업데이트 함수.

동작 예시를 살펴보자.

다음과 같이  messagesFromServer 프롭으로 버로부터 메시지를 받는 경우가 있다고 하자.

 

먼저 useOptimistic 훅에서 첫 번째 인자로 messageFromSever 프롭으로부터 받은 값을 initial state로 지정하고, 서버에서 받은 이 값이 랜더 된다.

만약 다음과 같이 유저가 메시지를 제출하면 addMessage action이 trigger 된다.

addMessage action 안에 우선 방금 입력했던 값으로 addOptimisticMessage 함수가 호출되고, 

useOptimistic 훅의 update 함수가 trigger 된다.

trigger 된 update함수는 서버에서 받은 currentMessages와 새로운 optimisticMessage을 담은 배열을 리턴한다.

이제 pending 중이므로 allMessages는 업데이트된다.

아직 보내지고 있다는 걸 명시하기 위해 'Sending...'등의 문구를 추가해 줄 수 있다.

 

이후에 아래와 같이 실제로 요청을 보내고, 

 

요청이 성공하면 messagesFromServer 프롭이 업데이트되고, 

이 값을 initial state로 썼기 때문에 이제 allMessages는 이 업데이트된 값을 갖게 된다.

따라서 re-render가 발생하고 allMessages값을 보여주게 된다. (리랜더링 전까지는 optimistic 업데이트의 데이터를 본 것)

 

이전까지 디폴트로 async 한 action은  transition을 trigger 한다는 것을 살펴봤었다.

하지만 useOptimistic은 UI에 곧바로 반영이 되도록 한다.

 

 

---

지금까지는 Client API에 대해 살펴봤었다.

이번에는 Server API에 대해 살펴보자.

---

6. React Server Components : 클라이언트 환경 외에서 리액트 컴포넌트 랜더

 

전통적으로 렌더링 방식에는 client-side와 server-side가 있다.

 

1. Client-side Rendering

• 서버 사이드의 리액트 트리가 자바스크립트 번들로 랜더 되고, 
• minimal html이 클라이언트 사이드에 전달
• 클라이언트 사이드의 리액트 트리가 번들된 서버 사이드 리액트 트리로 리액트 트리를 rebuild

2. Server-side Rendering

• 리액트 트리가 html과 자바스크립트 번들로 랜더되고,
• 이 번들이 클라이언트 사이드에 전달
• static html이 번들 안에서 상호작용가능하게끔 rebuild

두 렌더링 방식 모두 리액트 트리를 이미 서버에 갖고 있음에도 리액트 렌더러가 client-side에서 rebuild 해야 한다는 점

 

(react18) Concurrent renderer 등장으로 React Server Component 등장

• RSC는 실제 serialized 컴포넌트 트리를 특수한 json 형식으로 클라이언트에게 전달할 수 있게끔 했다.
• 클라이언트 사이드 랜더러는 이 json 포맷을 읽어서 html이나 js 없이도 리액트 트리를 rebuild 할 수 있게 되었다.

 

RSC는 클라이언트에 직접 전달되지 않고, 다음과 같은 json 형식으로 리턴 값만 전달된다.

 

따라서 다음과 같이 서버 사이드의 기능(DB접근, 파일 시스템 이용 등등)들을 컴포넌트 내부에서 직접 쓸 수 있게 되었다.

 

리액트 19부터는 aysnc/await로 서버 컴포넌트를 랜더 할 수 있게 되어 더욱 쉽게 서버 사이드의 기능들을 사용할 수 있다.

 

생각보다 db에서 데이터를 찾기 위한 시간이 많이 소요되는 상황이 있을 수 있다.

이 경우 리액트 트리 전체가 데이터가 fetch 완료될 때까지, 그리고 클라이언트에게 전달될 때까지 대기해야 한다.

이 문제를 해결하기 위해서 suspense boundary로 감싸줘서 상대적으로 빠른 부븐들은 클라이언트한테 stream 해서 랜더 하고,

기다려하는 부분들은 suspense fallback을 렌더 할 수 있다. 

 

데이터 fetch가 완료되고 rc payload가 생성완료된 시점에 해당 컴포넌트가 클라이언트에게 전달되고 렌더 된다.

 

리액트 컴포넌트가 아무런 js 코드 없이 서버에서만 렌더 된 후 json으로 렌더 되기 때문에 디폴트로 클라이언트 사이드 기능들을 사용할 수 없다. 즉, hook이나 이벤트 핸들러 등을 사용하거나 window객체에 접근할 수 없다.

 

클라이언트 사이드로 컴포넌트를 렌더 하기 위해서는 명시적으로 자바스크립트 번들에 추가해야 한다.

번들러에게 명시하기 위해서 "use client" 번들러 명령어를 사용하면 된다.

 

"use client" 명령어를 추가 시, 리액트는 서버에서 이 컴포넌트를 렌더 하지 않고 CSR로 렌더 하는 방식을 택한다.

 

리턴 값뿐만 아니라 컴포넌트 자체를 클라이언트에게 보내기 때문에 서버 컴포넌트에서 그랬듯이 데이터를 fetch 해올 수 없게 되었다.

대신 다음과 같이 서버 컴포넌트에서 데이터를 fetch 해오고 props로 클라이언트 컴포넌트에 전달하는 방식을 택하거나

 

다음에 설명한 클라이언트 API인 use를 사용할 수 있다.

use API를 클라이언트 컴포넌트 내부에서 사용하여 실제 데이터 대신 promise를 props로 전달하는 방식을 택할 수 있다.

7. use :  promise의 resolved 값이나 context의 값 읽기

⚠️ 주의! use는 훅이 아닌 api다.

 

직전에 살펴봤던 예시에서 reactionsPromise는 서버 컴포넌트에서 생성되었다.

값을 await 하는 대신 이 promise를 클라이언트에게 전달하고, 클라이언트에서 use API로 전달하게 된다.

 

use API는 자동적으로 Suspense와 ErrorBoundary와 통합되는데,

다음과 같이 클라이언트에서 promise가 resolve 되기 전까지는 suspense fallback을 보여주고,

 

promise가 resolve 된 이후 다음과 같이 해당 컴포넌트의 데이터를 보여주거나 promise가 rejected 되면 errorBoundary를 보여준다.

use API를 클라이언트에 직접 사용하는 것의 장점은 나머지 서버 컴포넌트들은 데이터를 await 할 필요 없이 클라이언트에 미리 stream 된다는 점이다.

use API를 통해 async 데이터를 클라이언트 사이드에서 수월하게 다룰 수 있게 된다.

이전에는 아래의 코드(왼쪽)처럼 api endpoint를 설정하고, 로딩/에러 state 설정을 해야 했지만,

useAPI를 통해 (오른쪽) 리액트 내부적으로 이 부분을 처리하기 때문에 코드를 단순화할 수 있게 되었다.

 

use API는 async 함수뿐만 아니라 context와 쓰일 수 있다.

useContext 훅과 동일하지만 조건부적으로 호출할 수 있다는 점에서 차이가 있다. 

즉, early return이나 조건문 내에서 호출 가능하다는 점에서 useContext보다 더 유연하게 사용할 수 있다.

8. Server Actions :  서버에서 run 하는 함수 클라이언트에서 call 하기

서버 환경에서 server action을 생성할 수 있게 되었다.

server action이란 서버 사이드에서 실행(run)하지만 클라이언트 사이드에서 호출(call)될 수 있는 함수다.

server action은 리액트 내부적인 특성이라기보다는 framework와 함께 쓰이기 위한 특성이라고 한다.

 

"use server" 명령어를 사용하여 서버 컴포넌트를 생성할 수 있다.

함수의 body 위에 명시하고 클라이언트 컴포넌트에 props로 전달하거나

 

파일의 최상단에 명시하여 serverAction를 클라이언트 컴포넌트에 import 하는 방식을 취할 수 있다.

 

endpoint 구현은 사용하는 framework에 따라 달라지겠지만, 

server action이 trigger 되면 이 함수를 실행하기 위해 리액트는 이 요청을 서버에게 전달하게 된다.

 

그리고 이 요청의 state를 useActionState, useTransition, useFormStatus 등의 훅으로 추적할 수 있다.

---

지금까지는 리액트 19에서 새로 소개된 기능들에 대해 살펴봤었다.

다음은 개선된 사항들에 대해 살펴보고 마무리할 예정이다.

---

9.  ref as prop :  함수형 컴포넌트에서 prop으로 ref 접근

 

리액트 19부터는 서버 컴포넌트에서 ref를 prop으로 접근할 수 있게 되었다.

이전에는 ref를 서버 컴포넌트에 직접 전달하기 위해서는 forwardRef를 사용해야 했었다 (왼쪽 사진).

하지만 리액트 19부터는 forwardRef 없이 일반 prop처럼 접근 가능해졌다 (오른쪽 사진).

 

또한 ref 콜백함수 내에 cleanup 함수가 제공되는데, 다음과 같이 이벤트 리스너를 제거하여 메모리 누수를 예방할 수 있다.

10.  Document metadata :  컴포넌트 내에서 직접 metadata 사용하기

 

이전에 컴포넌트 내에서 직접 metatag를 사용하기 위해서는 react helmet를 사용해야 했다.

리액트 19부터는 리액트 자체적으로 컴포넌트 내부에서 metatag를 사용하면 head로 hoisting을 해준다.

하지만 아직 커스텀 metatag를 사용하고자 한다면 react helmet 툴을 사용해야 한다.

11.  Stylesheet support :  컴포넌트 내에서 직접 stylesheet 사용하기

 

리액트 19부터는 스타일시트를 사용하고 있는 컴포넌트 내에서 직접 사용할 수 있게 되었다.

metatag과 마찬가지로 리액트는 이 태그들을 head로 hoist 하여 css가 로드되기 전까지 브라우저가 컴포넌트를 렌더 하지 않도록 한다.

뿐만 아니라 suspense 안에서도 사용가능한데,

리액트는 다음과 같이 중요도(precedence)에 따라 스타일시트가 먼저 로드되도록 보장한다.

 

suspense boundary 안의 스타일시트가 로드(스타일시트가 head에 추가되고 로드를 완료될 때까지)되는 동안 리액트는 suspense fallback을 보여준다. css가 완전히 로드될 때까지 이 suspense fallback을 보여주기 때문에 스타일이 입혀지지 않은 flash가 발생하는 것을 방지한다.

12.  Preloading API: 컴포넌트 내에서 preload, preconnect, preinit, prefetchDNS 등 사용

 

browser hint에 해당하는 preload, preconnect, preinit, prefetchDNS 등을 컴포넌트 내부에서 사용하여 로딩 속도를 향상할 수 있게 되었다.

리액트는 자동적으로 중요도에 따라 이 링크들의 순서를 정렬하기 때문에 개발자가 로딩 순서로 인한 성능저하를 걱정할 필요가 없어진다. 

---

🍀 마치면서

오늘은 What's new in React 19에 소개된 리액트 19의 새롭거나 개선된 기능들에 대해 살펴봤다.

1. Asynchoronous transitions: startTransition에 async 함수를 전달하기
2. Actions:  transition을 트리거하는 함수들
3. useActionState:  훅을 통한 action 생성
4. action and formAction props : form, button, input 등과 action 함께 쓰기
5. useFormStatus : 더 쉽게 action의 form status에 접근하기
6. React Server Components : 클라이언트 환경 외에서 리액트 컴포넌트 랜더
7. use:  promise의 resolved 값이나 context의 값 읽기
8. Server Actions:  서버에서 run 하는 함수 클라이언트에서 call 하기
> 리액트 19부터 개선된 사항들
9.  ref as prop:  함수형 컴포넌트에서 prop으로 ref 접근
10.  Document metadata:  컴포넌트 내에서 직접 metadata 사용하기
11.  Stylesheet support:  컴포넌트 내에서 직접 stylesheet 사용하기
12. Preloading API: 컴포넌트 내에서 preload, preconnect, preinit, prefetchDNS 등 사용

 

전반적으로 '리액트 서버 컴포넌트'가 불러온 변화들로 인해 state들을 어떻게 접근/관리하고, 컴포넌트를 언제 어떻게 랜더링 할 지에 관한 기능들에 대해 다룬 것 같다. 아직 소개한 기능들을 사용을 해보지는 못했지만, transition관련 훅들이 transition 상태를 나타내는데 할애해야 하는 코드들을 대폭 줄일 수 있을 거 같아서 흥미롭게 느껴졌다.

다음에는 리액트 19 버전에서 새로 소개된 기능들을 한번 써보고 개선된 개발 경험을 체험해보고 싶다.