2025년 4월 23일, Ricky Hanlon

오늘 저희는 테스트할 준비가 완료된 두 가지 새로운 실험적 기능에 대한 문서를 공개하게 되어 기쁩니다.

• View Transitions
• Activity

또한 현재 개발 중인 새로운 기능들에 대한 업데이트도 공유합니다.

• React Performance Tracks
• Compiler IDE Extension
• Automatic Effect Dependencies
• Fragment Refs
• Concurrent Stores

새로운 실험적 기능

View Transitions와 Activity는 이제 react@experimental에서 테스트할 준비가 되었습니다. 이러한 기능들은 프로덕션에서 테스트되었으며 안정적이지만, 피드백을 반영하는 과정에서 최종 API가 여전히 변경될 수 있습니다.

가장 최신 실험적 버전으로 React 패키지를 업그레이드하여 사용해볼 수 있습니다.

• react@experimental
• react-dom@experimental

앱에서 이러한 기능을 사용하는 방법을 알아보려면 계속 읽어보시거나, 새로 공개된 문서를 확인해보세요.

• <ViewTransition>: Transition에 애니메이션을 활성화할 수 있는 컴포넌트입니다.
• addTransitionType: Transition의 원인을 지정할 수 있는 함수입니다.
• <Activity>: UI의 일부를 숨기거나 보여줄 수 있는 컴포넌트입니다.

View Transitions

React View Transitions는 앱의 UI 전환에 애니메이션을 더 쉽게 추가할 수 있게 해주는 새로운 실험적 기능입니다. 내부적으로, 이러한 애니메이션은 대부분의 최신 브라우저에서 사용할 수 있는 새로운 startViewTransition API를 사용합니다.

엘리먼트의 애니메이션을 활성화하려면, 새로운 <ViewTransition> 컴포넌트로 감싸주세요.

// 애니메이션할 "대상"
<ViewTransition>
  <div>animate me</div>
</ViewTransition>

이 새로운 컴포넌트를 사용하면 애니메이션이 활성화될 때 무엇을 애니메이션할지 선언적으로 정의할 수 있습니다.

View Transition에 대한 다음 세 가지 트리거 중 하나를 사용해서 “언제” 애니메이션할지 정의할 수 있습니다.

// 애니메이션할 "시점"

// Transitions
startTransition(() => setState(...));

// Deferred Values
const deferred = useDeferredValue(value);

// Suspense
<Suspense fallback={<Fallback />}>
  <div>Loading...</div>
</Suspense>

기본적으로, 이러한 애니메이션은 View Transitions의 기본 CSS 애니메이션이 적용됩니다 (일반적으로 부드러운 크로스 페이드). view transition 의사 선택자를 사용해서 애니메이션이 “어떻게” 실행될지 정의할 수 있습니다. 예를 들어, *를 사용해서 모든 전환에 대한 기본 애니메이션을 변경할 수 있습니다.

// 애니메이션하는 "방법"
::view-transition-old(*) {
  animation: 300ms ease-out fade-out;
}
::view-transition-new(*) {
  animation: 300ms ease-in fade-in;
}

startTransition, useDeferredValue, 또는 Suspense 폴백이 콘텐츠로 전환되는 것과 같은 애니메이션 트리거로 인해 DOM이 업데이트되면, React는 선언적 휴리스틱을 사용해서 애니메이션을 위해 활성화할 <ViewTransition> 컴포넌트를 자동으로 결정합니다. 그러면 브라우저가 CSS에서 정의된 애니메이션을 실행합니다.

브라우저의 View Transition API에 익숙하고 React가 이를 어떻게 지원하는지 알고 싶다면, 문서의 How does <ViewTransition> Work를 확인해보세요.

이번 게시글에서는 View Transitions를 사용하는 몇 가지 예시를 살펴보겠습니다.

다음과 같은 상호작용을 애니메이션하지 않는 앱부터 시작하겠습니다.

• 비디오를 클릭해서 세부 정보를 봅니다.
• ”back”을 클릭해서 피드로 돌아갑니다.
• 목록에서 타이핑해서 비디오를 필터링합니다.

네비게이션 애니메이션

저희 앱에는 Suspense가 활성화된 라우터가 포함되어 있으며, 페이지 전환이 이미 Transitions로 표시되어 있습니다. 이는 네비게이션이 startTransition으로 수행된다는 의미입니다.

function navigate(url) {
  startTransition(() => {
    go(url);
  });
}

startTransition은 View Transition 트리거이므로, 페이지 간 애니메이션을 위해 <ViewTransition>을 추가할 수 있습니다:

// 애니메이션할 "대상"
<ViewTransition key={url}>
  {url === '/' ? <Home /> : <TalkDetails />}
</ViewTransition>

url이 변경되면, <ViewTransition>과 새로운 라우트가 렌더링됩니다. <ViewTransition>이 startTransition 내부에서 업데이트되었으므로, <ViewTransition>이 애니메이션을 위해 활성화됩니다.

기본적으로, View Transitions는 브라우저 기본 크로스 페이드 애니메이션을 포함합니다. 이를 예시에 추가하면, 이제 페이지 간 네비게이션할 때마다 크로스 페이드가 적용됩니다.

Since our router already updates the route using startTransition, this one line change to add <ViewTransition> activates with the default cross-fade animation.

If you’re curious how this works, see the docs for How does <ViewTransition> work?

// Layout.js
<ViewTransition default="none">
  {children}
</ViewTransition>

Customizing animations

By default, <ViewTransition> includes the default cross-fade from the browser.

To customize animations, you can provide props to the <ViewTransition> component to specify which animations to use, based on how the <ViewTransition> activates.

For example, we can slow down the default cross fade animation:

<ViewTransition default="slow-fade">
  <Home />
</ViewTransition>

And define slow-fade in CSS using view transition classes:

::view-transition-old(.slow-fade) {
    animation-duration: 500ms;
}

::view-transition-new(.slow-fade) {
    animation-duration: 500ms;
}

Now, the cross fade is slower:

See Styling View Transitions for a full guide on styling <ViewTransition>.

Shared Element Transitions

When two pages include the same element, often you want to animate it from one page to the next.

To do this you can add a unique name to the <ViewTransition>:

<ViewTransition name={`video-${video.id}`}>
  <Thumbnail video={video} />
</ViewTransition>

Now the video thumbnail animates between the two pages:

By default, React automatically generates a unique name for each element activated for a transition (see How does <ViewTransition> work). When React sees a transition where a <ViewTransition> with a name is removed and a new <ViewTransition> with the same name is added, it will activate a shared element transition.

For more info, see the docs for Animating a Shared Element.

Animating based on cause

Sometimes, you may want elements to animate differently based on how it was triggered. For this use case, we’ve added a new API called addTransitionType to specify the cause of a transition:

function navigate(url) {
  startTransition(() => {
    // Transition type for the cause "nav forward"
    addTransitionType('nav-forward');
    go(url);
  });
}
function navigateBack(url) {
  startTransition(() => {
    // Transition type for the cause "nav backward"
    addTransitionType('nav-back');
    go(url);
  });
}

With transition types, you can provide custom animations via props to <ViewTransition>. Let’s add a shared element transition to the header for “6 Videos” and “Back”:

<ViewTransition
  name="nav"
  share={{
    'nav-forward': 'slide-forward',
    'nav-back': 'slide-back',
  }}>
  {heading}
</ViewTransition>

Here we pass a share prop to define how to animate based on the transition type. When the share transition activates from nav-forward, the view transition class slide-forward is applied. When it’s from nav-back, the slide-back animation is activated. Let’s define these animations in CSS:

::view-transition-old(.slide-forward) {
    /* when sliding forward, the "old" page should slide out to left. */
    animation: ...
}

::view-transition-new(.slide-forward) {
    /* when sliding forward, the "new" page should slide in from right. */
    animation: ...
}

::view-transition-old(.slide-back) {
    /* when sliding back, the "old" page should slide out to right. */
    animation: ...
}

::view-transition-new(.slide-back) {
    /* when sliding back, the "new" page should slide in from left. */
    animation: ...
}

Now we can animate the header along with thumbnail based on navigation type:

Animating Suspense Boundaries

Suspense will also activate View Transitions.

To animate the fallback to content, we can wrap Suspense with <ViewTranstion>:

<ViewTransition>
  <Suspense fallback={<VideoInfoFallback />}>
    <VideoInfo />
  </Suspense>
</ViewTransition>

By adding this, the fallback will cross-fade into the content. Click a video and see the video info animate in:

We can also provide custom animations using an exit on the fallback, and enter on the content:

<Suspense
  fallback={
    <ViewTransition exit="slide-down">
      <VideoInfoFallback />
    </ViewTransition>
  }
>
  <ViewTransition enter="slide-up">
    <VideoInfo id={id} />
  </ViewTransition>
</Suspense>

Here’s how we’ll define slide-down and slide-up with CSS:

::view-transition-old(.slide-down) { 
  /* Slide the fallback down */
  animation: ...;
}

::view-transition-new(.slide-up) {
  /* Slide the content up */
  animation: ...;
}

Now, the Suspense content replaces the fallback with a sliding animation:

Animating Lists

You can also use <ViewTransition> to animate lists of items as they re-order, like in a searchable list of items:

<div className="videos">
  {filteredVideos.map((video) => (
    <ViewTransition key={video.id}>
      <Video video={video} />
    </ViewTransition>
  ))}
</div>

To activate the ViewTransition, we can use useDeferredValue:

const [searchText, setSearchText] = useState('');
const deferredSearchText = useDeferredValue(searchText);
const filteredVideos = filterVideos(videos, deferredSearchText);

Now the items animate as you type in the search bar:

Final result

By adding a few <ViewTransition> components and a few lines of CSS, we were able to add all the animations above into the final result.

We’re excited about View Transitions and think they will level up the apps you’re able to build. They’re ready to start trying today in the experimental channel of React releases.

Let’s remove the slow fade, and take a look at the final result:

If you’re curious to know more about how they work, check out How Does <ViewTransition> Work in the docs.

For more background on how we built View Transitions, see: #31975, #32105, #32041, #32734, #32797 #31999, #32031, #32050, #32820, #32029, #32028, and #32038 by @sebmarkbage (thanks Seb!).

Activity

In past updates, we shared that we were researching an API to allow components to be visually hidden and deprioritized, preserving UI state with reduced performance costs relative to unmounting or hiding with CSS.

We’re now ready to share the API and how it works, so you can start testing it in experimental React versions.

<Activity> is a new component to hide and show parts of the UI:

<Activity mode={isVisible ? 'visible' : 'hidden'}>
  <Page />
</Activity>

When an Activity is visible it’s rendered as normal. When an Activity is hidden it is unmounted, but will save its state and continue to render at a lower priority than anything visible on screen.

You can use Activity to save state for parts of the UI the user isn’t using, or pre-render parts that a user is likely to use next.

Let’s look at some examples improving the View Transition examples above.

Restoring state with Activity

When a user navigates away from a page, it’s common to stop rendering the old page:

function App() {
  const { url } = useRouter();
  
  return (
    <>
      {url === '/' && <Home />}
      {url !== '/' && <Details />}
    </>
  );
}

However, this means if the user goes back to the old page, all of the previous state is lost. For example, if the <Home /> page has an <input> field, when the user leaves the page the <input> is unmounted, and all of the text they had typed is lost.

Activity allows you to keep the state around as the user changes pages, so when they come back they can resume where they left off. This is done by wrapping part of the tree in <Activity> and toggling the mode:

function App() {
  const { url } = useRouter();
  
  return (
    <>
      <Activity mode={url === '/' ? 'visible' : 'hidden'}>
        <Home />
      </Activity>
      {url !== '/' && <Details />}
    </>
  );
}

With this change, we can improve on our View Transitions example above. Before, when you searched for a video, selected one, and returned, your search filter was lost. With Activity, your search filter is restored and you can pick up where you left off.

Try searching for a video, selecting it, and clicking “back”:

Pre-rendering with Activity

Sometimes, you may want to prepare the next part of the UI a user is likely to use ahead of time, so it’s ready by the time they are ready to use it. This is especially useful if the next route needs to suspend on data it needs to render, because you can help ensure the data is already fetched before the user navigates.

For example, our app currently needs to suspend to load the data for each video when you select one. We can improve this by rendering all of the pages in a hidden <Activity> until the user navigates:

<ViewTransition>
  <Activity mode={url === '/' ? 'visible' : 'hidden'}>
    <Home />
  </Activity>
  <Activity mode={url === '/details/1' ? 'visible' : 'hidden'}>
    <Details id={id} />
  </Activity>
  <Activity mode={url === '/details/1' ? 'visible' : 'hidden'}>
    <Details id={id} />
  </Activity>
<ViewTransition>

With this update, if the content on the next page has time to pre-render, it will animate in without the Suspense fallback. Click a video, and notice that the video title and description on the Details page render immediately, without a fallback:

Server-Side Rendering with Activity

When using Activity on a page that uses server-side rendering (SSR), there are additional optimizations.

If part of the page is rendered with mode="hidden", then it will not be included in the SSR response. Instead, React will schedule a client render for the content inside Activity while the rest of the page hydrates, prioritizing the visible content on screen.

For parts of the UI rendered with mode="visible", React will de-prioritize hydration of content within Activity, similar to how Suspense content is hydrated at a lower priority. If the user interacts with the page, we’ll prioritize hydration within the boundary if needed.

These are advanced use cases, but they show the additional benefits considered with Activity.

Future modes for Activity

In the future, we may add more modes to Activity.

For example, a common use case is rendering a modal, where the previous “inactive” page is visible behind the “active” modal view. The “hidden” mode does not work for this use case because it’s not visible and not included in SSR.

Instead, we’re considering a new mode that would keep the content visible—and included in SSR—but keep it unmounted and de-prioritize updates. This mode may also need to “pause” DOM updates, since it can be distracting to see backgrounded content updating while a modal is open.

Another mode we’re considering for Activity is the ability to automatically destroy state for hidden Activities if there is too much memory being used. Since the component is already unmounted, it may be preferable to destroy state for the least recently used hidden parts of the app rather than consume too many resources.

These are areas we’re still exploring, and we’ll share more as we make progress. For more information on what Activity includes today, check out the docs.

개발 중인 기능

저희는 아래의 일반적인 문제들을 해결하는 데 도움이 되는 기능들도 개발하고 있습니다.

가능한 솔루션을 반복 개발하면서, 저희가 진행하고 있는 PR을 기반으로 테스트 중인 잠재적 API들이 공유되는 것을 보실 수 있습니다. 다양한 아이디어를 시도하면서, 시도해본 후 다른 솔루션을 자주 변경하거나 제거한다는 점을 기억해 주세요.

저희가 작업하고 있는 솔루션을 너무 일찍 공유하면, 커뮤니티에 혼란과 혼동을 일으킬 수 있습니다. 투명성과 혼란 제한 사이의 균형을 맞추기 위해, 염두에 두고 있는 특정 솔루션을 공유하지 않고 현재 솔루션을 개발하고 있는 문제들을 공유합니다.

이러한 기능들이 진전을 보이면, 여러분이 시도해볼 수 있도록 문서와 함께 블로그에서 발표하겠습니다.

React Performance Tracks

React 앱의 성능에 대한 더 많은 정보를 제공하기 위해 커스텀 트랙 추가를 허용하는 브라우저 API를 사용하여 성능 프로파일러에 새로운 커스텀 트랙 세트를 작업하고 있습니다.

이 기능은 아직 진행 중이므로, 실험적 기능으로 완전히 출시하기 위한 문서를 발행할 준비가 되지 않았습니다. React의 실험적 버전을 사용하면 미리 보기를 할 수 있으며, 이는 자동으로 프로필에 성능 트랙을 추가합니다.

성능과 스케줄러 트랙이 일시 중단된 트리에서 작업을 항상 “연결”하지 않는 등 해결할 계획인 몇 가지 알려진 문제들이 있어서, 아직 시도할 준비가 완전히 되지 않았습니다. 또한 트랙의 디자인과 사용성을 개선하기 위해 얼리 어답터들로부터 피드백을 계속 수집하고 있습니다.

이러한 문제들을 해결하면, 실험적 문서를 발행하고 시도할 준비가 되었다고 공유하겠습니다.

Automatic Effect Dependencies

hooks를 출시했을 때, 저희는 세 가지 동기가 있었습니다:

• 컴포넌트 간 코드 공유: hooks는 렌더링 props와 고차 컴포넌트 같은 패턴을 대체하여 컴포넌트 계층을 변경하지 않고도 상태가 있는 로직을 재사용할 수 있게 해주었습니다.
• 생명주기가 아닌 함수의 관점에서 사고: hooks는 생명주기 메서드를 기반으로 한 분할을 강제하는 것이 아니라 관련된 부분(구독 설정이나 데이터 가져오기 등)을 기반으로 하나의 컴포넌트를 더 작은 함수로 분할할 수 있게 해주었습니다.
• 사전 컴파일 지원: hooks는 생명주기 메서드로 인한 의도하지 않은 최적화 해제 문제와 클래스의 제약사항을 줄이면서 사전 컴파일을 지원하도록 설계되었습니다.

출시 이후 hooks는 컴포넌트 간 코드 공유에서 성공적이었습니다. Hooks는 이제 컴포넌트 간 로직을 공유하는 선호되는 방법이 되었고, 렌더링 props와 고차 컴포넌트의 사용 사례는 줄어들었습니다. Hooks는 또한 클래스 컴포넌트로는 불가능했던 Fast Refresh와 같은 기능을 지원하는 데도 성공적이었습니다.

Effects는 어려울 수 있습니다

안타깝게도, 일부 hooks는 여전히 생명주기 대신 함수의 관점에서 사고하기 어렵습니다. 특히 Effects는 여전히 이해하기 어렵고 개발자들로부터 듣는 가장 일반적인 고민거리입니다. 작년에 저희는 Effects가 어떻게 사용되는지, 그리고 이러한 사용 사례가 어떻게 단순화되고 이해하기 쉬워질 수 있는지에 대해 상당한 시간을 연구했습니다.

종종 혼란은 필요하지 않을 때 Effect를 사용하는 데서 온다는 것을 발견했습니다. You Might Not Need an Effect 가이드는 Effects가 올바른 솔루션이 아닌 경우들을 많이 다루고 있습니다. 하지만 Effect가 문제에 적합한 해결책일 때조차도, Effects는 클래스 컴포넌트 생명주기보다 여전히 이해하기 어려울 수 있습니다.

혼란의 이유 중 하나는 개발자들이 Effects 관점(Effect가 무엇을 하는지)이 아니라 컴포넌트의 관점(생명주기 같은)에서 Effects를 생각하기 때문이라고 생각합니다.

문서의 예시를 살펴보겠습니다:

useEffect(() => {
  // Your Effect connected to the room specified with roomId...
  const connection = createConnection(serverUrl, roomId);
  connection.connect();
  return () => {
    // ...until it disconnected
    connection.disconnect();
  };
}, [roomId]);

많은 사용자들은 이 코드를 “마운트 시에 roomId에 연결하고, roomId가 변경될 때마다 이전 방으로부터 연결을 해제하고 새로운 연결을 생성한다”고 읽을 것입니다. 하지만 이는 컴포넌트의 생명주기 관점에서 생각하는 것이며, 이는 Effect를 올바르게 작성하기 위해 모든 컴포넌트 생명주기 상태를 생각해야 한다는 의미입니다. 이는 어려울 수 있으므로, 컴포넌트 관점을 사용할 때 Effects가 클래스 생명주기보다 어려워 보이는 것이 이해할 만합니다.

의존성 없는 Effects

대신 Effect의 관점에서 생각하는 것이 좋습니다. Effect는 컴포넌트 생명주기에 대해 알지 못합니다. 단지 동기화를 시작하는 방법과 중지하는 방법만 설명합니다. 사용자가 이런 식으로 Effects를 생각할 때, 그들의 Effects는 작성하기 더 쉬워지고, 필요한 만큼 여러 번 시작되고 중지되는 것에 더 탄력적이 됩니다.

Effects가 컴포넌트 관점에서 생각되는 이유를 연구하는 데 시간을 보냈고, 그 이유 중 하나가 의존성 배열이라고 생각합니다. 작성해야 하므로, 바로 거기에 있고 여러분이 무엇에 “반응”하고 있는지를 상기시키며 ‘이 값들이 변경될 때 이것을 하라’는 멘탈 모델로 유도합니다.

hooks를 출시할 때, 사전 컴파일로 사용하기 더 쉽게 만들 수 있다는 것을 알고 있었습니다. React Compiler를 사용하면, 이제 대부분의 경우 useCallback과 useMemo를 직접 작성하는 것을 피할 수 있습니다. Effects의 경우, 컴파일러가 의존성을 자동으로 삽입할 수 있습니다:

useEffect(() => {
  const connection = createConnection(serverUrl, roomId);
  connection.connect();
  return () => {
    connection.disconnect();
  };
}); // 컴파일러가 의존성을 삽입했습니다.

이 코드를 사용하면, React Compiler가 의존성을 추론하고 자동으로 삽입하므로 보거나 작성할 필요가 없습니다. IDE 확장 프로그램과 useEffectEvent 같은 기능을 통해, 디버깅이 필요한 시점이나 의존성을 제거하여 최적화할 때 Compiler가 삽입한 것을 보여주는 CodeLens를 제공할 수 있습니다. 이는 언제든지 실행되어 컴포넌트나 hook의 상태를 다른 것과 동기화할 수 있는 Effects를 작성하는 올바른 멘탈 모델을 강화하는 데 도움이 됩니다.

저희의 희망은 의존성을 자동으로 삽입하는 것이 작성하기 더 쉬울 뿐만 아니라, 컴포넌트 생명주기가 아닌 Effect가 하는 일의 관점에서 생각하도록 강제함으로써 이해하기도 더 쉽게 만든다는 것입니다.

Compiler IDE Extension

이번 주 초에 React Compiler 릴리스 후보를 공유했으며, 앞으로 몇 달 안에 컴파일러의 첫 번째 SemVer 안정 버전을 출시하기 위해 작업하고 있습니다.

또한 React Compiler를 사용해서 코드 이해와 디버깅을 향상시킬 수 있는 정보를 제공하는 방법을 탐구하기 시작했습니다. 저희가 탐구하기 시작한 아이디어 중 하나는 Lauren Tan의 React Conf 발표에서 사용된 확장 프로그램과 유사한, React Compiler를 기반으로 하는 새로운 실험적 LSP 기반 React IDE 확장 프로그램입니다.

저희의 아이디어는 컴파일러의 정적 분석을 사용해서 IDE에서 직접 더 많은 정보, 제안, 최적화 기회를 제공할 수 있다는 것입니다. 예를 들어, React의 규칙을 위반하는 코드에 대한 진단을 제공하거나, 컴포넌트와 hooks가 컴파일러에 의해 최적화되었는지 보여주는 호버, 또는 자동으로 삽입된 Effect 의존성을 볼 수 있는 CodeLens를 제공할 수 있습니다.

IDE 확장 프로그램은 아직 초기 탐구 단계이지만, 향후 업데이트에서 진행 상황을 공유하겠습니다.

Fragment Refs

이벤트 관리, 위치 지정, 포커스를 위한 DOM API들은 React로 작성할 때 구성하기 어렵습니다. 이는 종종 개발자들이 Effects에 의존하거나, 여러 Refs를 관리하거나, findDOMNode(React 19에서 제거됨)와 같은 API를 사용하게 만듭니다.

저희는 단일 엘리먼트가 아닌 DOM 엘리먼트 그룹을 가리키는 Fragments에 refs를 추가하는 것을 탐구하고 있습니다. 저희의 희망은 이것이 여러 자식을 관리하는 것을 단순화하고 DOM API를 호출할 때 구성 가능한 React 코드를 작성하기 더 쉽게 만드는 것입니다.

Fragment refs는 아직 연구 중입니다. 최종 API가 완성에 가까워지면 더 많은 내용을 공유하겠습니다.

Gesture Animations

저희는 또한 메뉴를 열기 위한 스와이프나 사진 캐러셀을 스크롤하는 것과 같은 제스처 애니메이션을 지원하기 위해 View Transitions를 향상시키는 방법을 연구하고 있습니다.

제스처는 몇 가지 이유로 새로운 도전을 제시합니다:

• Gestures are continuous: as you swipe the animation is tied to your finger placement time, rather than triggering and running to completion.
• Gestures don’t complete: when you release your finger gesture animations can run to completion, or revert to their original state (like when you only partially open a menu) depending on how far you go.
• Gestures invert old and new: while you’re animating, you want the page you are animating from to stay “alive” and interactive. This inverts the browser View Transition model where the “old” state is a snapshot and the “new” state is the live DOM.

We believe we’ve found an approach that works well and may introduce a new API for triggering gesture transitions. For now, we’re focused on shipping <ViewTransition>, and will revisit gestures afterward.

Concurrent Stores

When we released React 18 with concurrent rendering, we also released useSyncExternalStore so external store libraries that did not use React state or context could support concurrent rendering by forcing a synchronous render when the store is updated.

Using useSyncExternalStore comes at a cost though, since it forces a bail out from concurrent features like transitions, and forces existing content to show Suspense fallbacks.

Now that React 19 has shipped, we’re revisiting this problem space to create a primitive to fully support concurrent external stores with the use API:

const value = use(store);

Our goal is to allow external state to be read during render without tearing, and to work seamlessly with all of the concurrent features React offers.

This research is still early. We’ll share more, and what the new APIs will look like, when we’re further along.

Thanks to Aurora Scharff, Dan Abramov, Eli White, Lauren Tan, Luna Wei, Matt Carroll, Jack Pope, Jason Bonta, Jordan Brown, Jordan Eldredge, Mofei Zhang, Sebastien Lorber, Sebastian Markbåge, and Tim Yung for reviewing this post.