로딩화면, 렌더링화면을 분리하도록 돕는다.

에러 바운더리를 사용하면 에러 UI / 상태도 위임할 수 있다.

• React Suspense는 컴포넌트가 무언가를 렌더하기 위해 “wait”할 수 있도록 도와주며, 여기서의 “wait”은 데이터 로딩을 포함한 모든 비동기 요청이 해당될 수 있다.
• (Error Boundary와 함께) Suspense를 사용하면 개발자는 컴포넌트에서 사용할 데이터가 “정상적으로 로드되었을 때”의 UI만 고려하면 되고, 로딩 중이나 에러의 상태에서의 UI는 위임하면 된다. (하나의 컴포넌트에서 각각의 상태에 대한 관리를 명령적으로 관리할 필요가 없다)
• Suspense는 Fallback UI를 보여주는 동안에도 Child Component를 렌더한다(단지 보이지 않을 뿐.) 따라서 보다 Concurrent하게 데이터를 요청할 수 있고, 결과적으로 그렇지 않을 때 보다 더 나은 사용자 경험을 제공한다.
• Suspense가 Fallback UI를 보여주기 위해 사용하는 개념적인 방식은 “promise를 Throw하는 것이다.” promise가 throw되면 이 promise가 resolve되기 전까지 Fallback UI를 보여주고 resolve되면, hidden 상태였던 Child Component를 “보여준다”

예시)

아래는 위의 예제를 실행한 결과입니다. user를 가져오는 API에는 1000ms의 딜레이를 주었고, post를 가져오는 API에는 1100ms의 딜레이를 주었습니다. 여기서 주목할 만한 점은 UserData가 도착한 뒤에 또 다른 1100ms를 기다렸다가 PostData가 로드되는 것이 아니라 UserData와 PostData가 동시에(정확하게는 Concurrent 하게) 요청되고 이에 따라 1100ms 안에 모든 데이터가 로드되어 모든 화면이 나타나게 된다는 것입니다.

SSR 관련

• 현재 SSR API로서는

  • hydration이 시작하기 전에 모든 자바스크립트가 로드되어 있어야 한다.
  • 모든 hydration이 마칠 때까지 상호작용할 수 없다. 한번에 모든 hydration 작업을 처리한다.

• 이러한 문제가 발생하는 이유는 이 모든 과정들이 “Concurrent” 하게 이루어지지 못하기 때문입니다. (Waterfall)

  1. 서버에서 데이터를 가져오는 과정이 모두 끝나야

  2. 서버에서 HTML로 렌더링할 수 있고

  3. 클라이언트에 모든 자바스크립트 코드가 렌더링 된 후에야 Hydration을 수행할 수 있고

  4. 모든 Hydration이 끝나야 임의의 컴포넌트가 상호작용이 가능한 상태가 될 수 있다는 것입니다.

  5. 그리고 이 Waterfall 방식의 SSR 동작이 이 모든 것을 비효율적으로 만드는 이유입니다.

  이에 대해 React Core Team이 제시하는 해결책은 이 모든 과정을 “Concurrent” 하게 만드는 것입니다. 즉, 앞에서 언급한 작업을 쪼개, 전체 애플리케이션이 아닌 각각의 부분들에 대해 이 단계들을 수행할 수 있게 하는 것입니다. 그리고 이 문제를 React 18의 Suspense를 사용해서 해결할 수 있습니다.

Reat18에서는 Suspense를 통해 다음 2가지 SSR Feature를 사용할 수 있습니다.