서론

• UI는 다양한 부분으로 구성되고, 각 부분은 사용자 상호 작용에 각기 다른 속도로 응답한다
• 양식의 입력 필드와 같은 일부 부분들은 사용자 상호 작용에 거의 즉각적으로 응답하는 반면 매우 긴 필터링된 목록이나 페이지 간 탐색과 같은 부분은 느리고 응답하는 데 시간이 걸릴 수 있다
• concurrent 기능이 없는 리액트 (및 다른 모든 JS UI 라이브러리 / 프레임워크)가 작동하는 방식인 동기 렌더링을 사용하면 UI의 느린 부분이 실행을 차단해 빠른 부분을 끌어내림으로써 응답성이 저하되는 경우가 있다

React의 concurrent 렌더러는 빠른 부분을 차단하지 않고 느린 부분을 백그라운드에서 렌더링함으로써 빠른 부분과 느린 부분을 분리하여 각 부분이 자신의 속도로 사용자 상호작용에 응답할 수 있도록 한다

• 따라서 React의 concurrent 렌더링이 애플리케이션을 더 빠르게 만들지는 못하지만, UI의 응답성을 높여 더 빠르게 느껴지도록 할 수 있다
• 이 글에서는 리액트 Concurrent에 대해 자세히 살펴보고, 어떤 문제를 해결하는지, 어떻게 작동하는지 Concurrent 기능을 사용하여 어떻게 활용할 수 있는지 알아본다.

문제

• 필터링된 목록을 렌더링하는 컴포넌트를 작성 중이고, 이 필터링은 클라이언트에서 이루어진다
  • 필터링으로 인해 서버에 대한 추가 호출이 발생하지 않음
• 또한 어떤 이유로든 필터링된 목록을 렌더링하는 것은 CPU 집약적인 작업이므로 렌더링하는데 몇 밀리초가 걸린다고 가정해보자
• 위 가정에서 목록 필터링에 사용될 텍스트 입력과 목록 자체의 두 가지 주요 UI 요소가 있다
• 이 예시에서는 CPU를 많이 사용하는 작업을 시뮬레이션하기 위해 메인 스레드를 동기적을 ㅗ차단하는 sleep 함수를 사용해 <List />의 속도를 인위적으로 낮췄다
• 이 컴포넌트를 최적화하여 렌더링 속도를 높이는 방법을 찾는 것이 이상적이지만, 최적화 측면에서 할 수 있는 일은 한정되어 있으며 때로는 최적화로는 해결할 수 없는 느린 렌더링이 발생할 수 있다
• 그러나 여기서는 다른 부분은 느려지더라도 UI의 빠른 부분은 응답성을 유지하고자 한다
• 이 예시에서는 <List />만 느린데 느린 컴포넌트 하나 때문에 전체 UI가 느려지고 있다

동기 렌더링

concurrent 기능을 사용하지 않는 경우 (즉, startTransition, useTransition 또는 useDeferred

(번역) Concurrent 리액트에 대해 알아야 할 모든 것(그리고 Suspense에 대해서 약간)