번역) React Labs: What We've Been Working On – February 2024

본문: https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024

React Compiler

React Compiler 는 더 이상 실험적 프로젝트가 아닙니다. 이미 인스타그램에서 실제로 사용 중에 있습니다. 또한 Meta의 additional surface(추가적인 다른 프로젝트..?)에 걸쳐 컴파일러를 적용하고 오픈 소스로 릴리즈하기 위해 준비하고 있습니다.

React는 때때로 상태 변경이 일어날 때마다 너무 많은 리렌더링이 발생하곤 했습니다. 과거부터 React는 그러한 경우에 대한 해결책으로 수동 메모이제이션을 사용해왔습니다. 현재 React의 API 중에서는 useMemo , useCallback , memo API들을 사용하는 것을 뜻하며 이들을 통해 상태 변경에 따른 리렌더링을 조정했습니다.

그러나 이렇게 개발자가 수동으로 메모이제이션을 하는 것은 타협안일 뿐입니다. 이렇게 하면 코드가 엉망이 되고, 틀리기 쉬우며, 최신 정보를 유지하기 위해 추가적인 작업이 필요합니다.

수동 메모이제이션은 꽤 합리적인 타협안이었음에도 우리는 만족스럽지 않았습니다. 우리의 목표는 React가 자동으로 상태 변경에 따라 꼭 업데이트가 필요한 UI만을 찾아 리렌더링을 하게 만드는 것입니다. React의 core mental model과 타협하지 않고서요. 우리는 표준 JavaScript 값과 idiom들로 이루어진 단순한 상태 함수로서의 UI라는 React의 접근 방식이 지금까지 많은 개발자들에게 React가 접근할 수 있었던 핵심적인 부분이라고 생각합니다.

JavaScript는 느슨한 규칙과 동적인 특성 때문에 최적화하기가 어렵기로 악명 높은 언어입니다. React Compiler 는 JavaScript의 규칙과 React의 규칙을 모두 모델링하여 안전하게 코드를 컴파일할 수 있습니다. 예를 들어, React 컴포넌트는 동일한 입력이 주어지면 동일한 값을 반환하는 멱함수여야 하며 props나 상태 값을 변경할 수 없습니다. 이러한 규칙은 개발자가 할 수 있는 일을 제한하고 컴파일러가 최적화할 수 있는 안전한 공간을 개척하는 데 도움을 줍니다.

물론 개발자들이 규칙을 약간 구부리는(bend) 경우도 있다는 것을 알고 있으며, 우리의 목표는 React Compiler 가 가능한 한 많은 코드에서 동작할 수 있도록 하는 것입니다. 컴파일러는 코드가 React의 규칙을 엄격하게 따르지 않을 때를 탐지하려고 시도하며, 안전하지 않으면 코드를 안전한 곳에 컴파일하거나(compile the code where safe) 컴파일을 생략합니다. 우리는 이 접근 방식을 검증하기 위해 Meta의 크고 다양한 코드베이스에 대해 테스트하고 있습니다.

코드가 React의 규칙을 따르는지 확인하고 싶은 개발자에게는 Strict Mode를 사용하도록 설정하고 React의 ESLint 플러그인을 구성하는 것을 권장합니다. 이러한 도구는 React 코드의 미묘한 버그를 탐지하여 현재 응용 프로그램의 품질을 향상시키고 React Compiler 와 같은 향후 기능을 위한 응용 프로그램을 미래 지향적(future-proofs)으로 작성하는데 도움이 될 수 있습니다. 또한 팀이 이러한 규칙을 이해하고 적용하여 보다 강력한 앱을 만들 수 있도록 React 규칙 및 ESLint 플러그인 업데이트에 대한 통합 문서화 작업을 진행하고 있습니다.

컴파일러가 작동하는 것을 보려면 작년 가을에 있었던 우리의 강연을 확인하세요. 강연 당시, 우리는 인스타그램의 한 페이지에서 React Compiler 를 시도한 초기 실험 데이터를 가지고 있었습니다. 그 이후로, 우리는 상용 인스타그램 전역에 컴파일러를 적용하였습니다. 또한 우리는 Meta의 additional surfaces와 컴파일러의 오픈 소스 출시를 가속화하기 위해 팀을 확장했습니다. 우리는 앞으로 나아갈 길에 대해 기대하고 있으며 앞으로 몇 달 동안 더 많은 것을 공유해야 할 것입니다.

Actions

우리는 이전에 Server Actions를 통해 클라이언트에서 서버로 데이터를 전달하는 해결책에 대해 공유한 적이 있습니다. Server Actions를 통해 데이터베이스의 mutation을 실행할 수도 있으면 폼을 구현할 수도 있습니다. Server Actions를 개발하는 동안, 우리는 아래 API들을 확장하여 client-only 애플리케이션에서 데이터를 잘 핸들링할 수 있도록 하였습니다.

우리는 이렇게 확장된 기능들을 “Actions”라고 칭합니다. Actions는 <form /> 과 같은 DOM 엘리먼트 요소에 함수를 전달할 수 있도록 합니다.

<form action={search}>
  <input name="query" />
  <button type="submit">Search</button>
</form>

action 함수는 동기적으로 동작할 수 도 있고 비동기적으로 동작할 수도 있습니다. 클라이언트 사이드에서 표준 JavaScript를 작성하여 action 을 정의할 수도 있고, use server 표시와 함께 서버 사이드에서 작성할 수도 있습니다. action 을 사용할 때, React는 useFormStatus, useFormState 등을 제공하여 현재 상태와 form action 으로부터의 응답값에 접근할 수 있도록 도와주며 데이터 제출(data submission)의 생명 주기를 관리합니다.

기본적으로 Actions은 transition 내에 제출되어 액션이 처리되는 동안 현재 페이지가 인터랙티브하게 유지됩니다. Actions은 비동기 기능을 지원하기 때문에 transition 에서 async/await 를 사용할 수 있는 기능도 추가되었습니다. 이를 통해 fetch 와 같은 비동기 요청이 시작될 때 transition 의 isPending 상태로 보류 중인 UI를 표시하고 적용 중인 업데이트를 통해 보류 중인 UI를 표시할 수 있습니다.

Actions와 함께 useOptimistic 이라는 기능을 도입하여 낙관적인 상태의 업데이트를 관리하고 있습니다. 이 훅을 사용하면 최종 상태가 커밋되면 자동으로 되돌리는 임시 업데이트를 적용할 수 있습니다. Actions의 경우 제출이 성공적이라고 가정할 때 클라이언트에서 데이터의 최종 상태를 최적으로 설정하고 서버에서 받은 데이터의 값으로 되돌릴 수 있습니다. 일반 async/await 를 사용하여 작동하므로 클라이언트에서 fetch 를 사용하든 서버에서 Server Action을 사용하든 동일하게 작동합니다.

라이브러리 작성자는 useTransition 을 사용하여 사용자 커스텀 함수(action={fn}) props을 자신의 컴포넌트에 구현할 수 있습니다. 우리의 의도는 라이브러리가 컴포넌트 API를 설계할 때 Actions 패턴을 채택하여 React 개발자에게 일관된 경험을 제공하는 것입니다. 예를 들어 라이브러리에서 <Calendar onSelect={eventHandler}> 컴포넌트를 제공하는 경우 <Calendar SelectAction={action}> API 노출도 고려하십시오.

처음에는 클라이언트-서버 데이터 전송을 위한 Server Action에 중점을 두었지만, React를 위한 우리의 철학은 모든 플랫폼과 환경에서 동일한 프로그래밍 모델을 제공하는 것입니다. 가능하면 클라이언트에 기능을 도입하면 서버에서도 작동하도록 만드는 것을 목표로 하고, 그 반대의 경우도 마찬가지입니다. 이 철학을 사용하면 앱이 실행되는 위치에 상관없이 작동하는 단일 API 세트를 만들 수 있으므로 나중에 다른 환경으로 쉽게 업그레이드할 수 있습니다.

Actions은 이제 Canary channel에서 사용할 수 있으며 다음 React 배포에 포함될 예정입니다.

New Features in React Canary

우리는 React Canaries를 stable semver version으로의 배포 이전 상태의 거의 디자인이 완료된 새로운 기능을 도입할 수 있는 옵션으로 제공하고 있습니다.

Canaries 는 React를 개발하는 방식의 변화입니다. 이전에는 Meta 내부에서 기능을 비공개로 연구하고 구축했기 때문에 사용자는 stable로 출시될 때만 최종 연마된 제품을 볼 수 있었습니다. Canaries 를 통해 React Labs 블로그 시리즈에서 공유하는 기능을 완성하기 위해 커뮤니티의 도움을 받아 공개적으로 구축하고 있습니다. 새로운 기능이 완성된 후가 아니라 완성되기 때문에 새로운 기능에 대해 더 빨리 들을 수 있습니다.

React Server Components, Asset Loading, Document Metadata 및 Actions가 모두 React Canaries에 포함되었으며, react.dev에 이러한 기능에 대한 문서를 추가했습니다:

• Directive: "use client"와 "use server"는 full-stack React frameworks를 위해 설계된 번들러 기능입니다. 이들은 두 환경 사이의 "split points"을 표시합니다. "use client"는 번들러에게 <script> 태그(Astro Islands와 같은)를 생성하도록 지시하는 반면, "use server"는 번들러에게 POST endpoint(tRPC Mutations와 같은)을 생성하도록 지시합니다. 이들을 함께 사용하면 관련 서버 측 로직과 클라이언트 측 상호 작용을 구성하는 재사용 가능한 컴포넌트를 작성할 수 있습니다.
• Document Metadata: 구성 요소 트리의 어느 곳에서나 <title>, <meta> 및 metadata <link> 태그 렌더링에 대한 내장 지원을 추가했습니다. 이들은 완전한 클라이언트 사이드 코드, SSR 및 RSC를 포함한 모든 환경에서 동일하게 작동합니다. 이는 React Helmet과 같은 라이브러리가 개척한 기능에 대한 내장 지원을 제공합니다.
• Asset Loading: Suspense를 stylesheets, fonts, scripts와 같은 리소스의 로딩 라이프사이클과 통합하여 React가 <style>, <link>, <script>와 같은 요소의 콘텐츠를 표시할 준비가 되었는지 확인합니다. 또한 리소스를 로드하고 초기화해야 하는 시기를 더 잘 제어할 수 있도록 preload 및 preinit와 같은 새로운 Resource Loading APIs를 추가했습니다.
• Actions: 위에 공유된 바와 같이 클라이언트에서 서버로 데이터 전송을 관리하기 위한 Actions을 추가했습니다. <form /> 과 같은 요소에 Actions을 추가하고, useFormStatus로 상태에 액세스하고, useFormState로 결과를 처리하고, useOptimistic로 UI를 낙관적 업데이트할 수 있습니다.

이 모든 기능은 함께 작동하기 때문에 Stable channel에 개별적으로 릴리스하기가 어렵습니다. 폼 상태에 액세스하기 위한 보완적인 훅 없이 Actions을 릴리스하면 Actions의 실제 사용성이 제한됩니다. Server Actions을 통합하지 않고 React Server Components를 도입하면 서버의 데이터를 수정하는 작업이 복잡해집니다.

Stable channel에 일련의 기능을 공개하기 전에 이 기능들이 일관되게 작동하고 개발자들이 이 기능을 프로덕션에 사용하는 데 필요한 모든 것을 갖추고 있는지 확인해야 합니다. React Canaries를 사용하면 이러한 기능을 개별적으로 개발할 수 있으며 전체 기능 세트가 완료될 때까지 안정적인 API를 점진적으로 공개할 수 있습니다.

React Canaries의 현재 기능 세트는 완성되었으며 출시 준비가 완료되었습니다.

The Nexst Major Version of React

react@canary 는 몇 년 동안 반복한 후 이제 react@latest로 배포될 준비가 되었습니다. 위에서 언급한 새로운 기능은 앱이 실행되는 모든 환경과 호환되어 프로덕션 사용에 필요한 모든 것을 제공합니다. Asset Loading 및 Document Metadata는 몇몇 앱에겐 꽤 큰 변경 사항일 수 있으므로 React의 다음 버전은 메이저 버전인 React 19가 될 것입니다.

릴리즈를 준비하려면 아직 해야 할 일이 더 있습니다. React 19에서는 Web Components 지원과 같은 오랫동안 요청된 개선 사항(꽤 큰 변경 사항)도 추가하고 있습니다. 이제 우리의 초점은 이러한 변경 사항을 제공하고 릴리즈를 준비하며 새로운 기능에 대한 문서를 마무리하고 포함된 내용에 대한 공지 사항을 게시하는 것입니다.

React 19에 포함된 모든 정보, 새로운 클라이언트 기능 채택 방법, React Server Components에 대한 지원을 구축하는 방법에 대한 자세한 내용을 앞으로 몇 달 안에 공유하겠습니다.

Offscreen (renamed to Activity).

지난 업데이트 이후로 저희는 연구 중인 기능의 이름을 "Offscreen"에서 "Activity"로 바꿨습니다. "Offscreen"이라는 이름은 앱의 보이지 않는 부분에만 적용된다는 것을 암시했지만, 기능을 연구하는 동안 우리는 모달 뒤의 콘텐츠와 같이 앱의 일부가 보이고 비활성화되는 것이 가능하다는 것을 깨달았습니다. 새로운 이름은 앱의 특정 부분을 "active" 또는 "inactive"으로 표시하는 행동을 더 밀접하게 반영합니다.

Activity는 아직 연구 중이고 남은 작업은 라이브러리 개발자들에게 노출되는 기본 요소들을 마무리하는 것입니다. 우리는 릴리즈할 더 완벽한 기능에 집중하면서 이 영역을 후순위로 미뤘습니다.

---

추가로, 우리 팀은 컨퍼런스에서 혹은 팟캐스트에서 우리의 작업에 대해서 이야기하거나 질문에 답하곤 하였습니다.

• Sathya Gunasekaran 은 React India 컨퍼런스에서 React Compiler에 대해 발표하였습니다.
• Dan Abramov는 RemixConf에서 “React from Another Dimension”이라는 제목으로 React Server Components와 Actions가 어떻게 탄생하였는지에 대한 과정을 발표하였습니다.
• Dan Abramov는 the Changelog’s JS Party podcast에서 React Server Components에 대해 인터뷰했습니다.
• Matt Carroll는 그가 The Two Reacts에 대해 논의했던 Front-End Fire podcast에서 인터뷰했습니다.

본 포스트를 리뷰해준 Lauren Tan, Sophie Alpert, Jason Bonta, Eli White 그리고 Sathya Gunasekaran에게 감사드립니다.

읽어주셔서 감사하며, see you at React Conf에서 뵙시다!