Suspense를 사용하기에 앞서

진행하고 있는 프로젝트에서 Suspense 를 사용하려고 한다. 다만 제대로 사용해본 적이 없어서 마구잡이로 사용해보다가 별로 도움이 되지 않고 있다고 느끼게 되었고, 잘못된 Suspense 사용이 아닌가 싶어서 알아보게 되었습니다.

 

비동기 데이터 관리

Suspense 와 비동기 데이터를 이용하여 로딩로직을 짤 수 있는 것은, Suspense가 Promise를 catch하는 것이 요점이다. Promise 상태를 throw 해주는 라이브러리와 함께 사용하면 Promise가 resolve 되기 전까지 Suspense가 fallback을 보여주는 것

 

가장 먼저, Recoil 은 클라이언트 전역 데이터 관리를 담당한다.

현재 작업에는 리코일을 사용하고 있다. 리액트 쿼리를 사용해야하나의 여부에선 지금까진 굳이 사용할 필요가 없다고 여겨져 사용하지 않고 있었는데, DB의 데이터가 점점 비대해질 수록 확연히 느려지는 속도가 문제 되고 있다. 그러므로 Suspense가 Promise를 catch 하려면 Recoil이 아닌 리액트 쿼리를 사용해야함을 느낀다.

 

Suspense는 불러오는 단위와 같다.

개별적인 로딩화면을 구성하려면 각 컴포넌트에 Suspense 를 따로 씌워줘야 한다. 다만 같은 Suspense 를 써주는 것도 가능하나 빠르게 로딩된 컴포넌트가 준비 되더라도 오래 걸리는 컴포넌트가 데이터 가져오기를 완료해야만 같이 보여진다. 

 

2개 이상의 요청에서의 Suspense의 잘못된 사용

Suspense는 Promise 를 catch 하여 Promise 상태에 따라 children 또는 LoadingFallback 컴포넌트를 반환한다. pending 상태일 땐 Loading을 반환하고 자식 컴포넌트는 실행시키지 않는다는 것이다.

하나의 api 요청이 발생하면 자식 컴포넌트의 실행은 멈추고 Loading을 반환하고 -> Promise가 settled 상태가 되면 자식 컴포넌트를 반환하여 렌더링할 것이다. 그렇기에 Suspense가 감싸고 있는 하나의 컴포넌트에서 2개 이상의 요청을 할 때 네트워크 병목이 발생하는 것이다.

Suspense 내 컴포넌트에서 두 개 이상의 요청이 발생하면 네트워크 워터폴 현상이 생기게 되므로 컴포넌트를 n개로 분리하여 각각 Query 요청을 수행해주는 것이 방법이 될 수 있다. 그러면 병목 현상이 병렬처리가 될 것이다.