😠 문제 상황

1. 복잡한 데이터 구조

UNIRO는 페이지의 개수가 적은 대신, 기능과 데이터의 밀도가 높습니다.

데이터를 제공해주는 UNIRO의 API는 노드와 간선들의 복잡한 집합으로 이루어진 응답을 받기 때문에, 서버에서 처리되는 동안 지연되는 응답시간을 고려해야 하는 경우가 많았습니다.

2. 컴포넌트 복잡도 증가

이런 데이터들을 지도에 표시하는 것도 DOM Element를 직접 다뤄줘야 하기 때문에, 컴포넌트에 복잡한 비즈니스 로직이 들어가야 했습니다.

안그래도 복잡한 비즈니스 로직에, API의 상태 관리를 하는 코드를 작성하면, 컴포넌트의 순수성과 코드의 가독성이 많이 떨어졌습니다.

3. 정확한 데이터 표시

지도에 길이나 위험요소, 주의요소를 표시할 때, 정확한 정보를 제공하는 것이 중요했습니다. 특히 배리어프리 맵인만큼, 갈 수 있는 길, 가다가 어떤 점이 위험한지, 주의해야 하는 부분인지를 빠짐없이 보여줘야 했습니다.

예시 화면

<aside> 🔥

아래는 기능을 사용할 수 있는 가장 초기 화면입니다.

호출해야 하는 API는 3개(길 전체에 대한 정보, 위험 / 주의 요소 전체에 대한 정보, 건물에 대한 정보) 정도이고, 데이터량이 많을 경우

raw json으로 2~3MB[50Mbps의 경우 600ms 소요]의 Body를 받게 됩니다.(길, 위험/주의 요소, 건물)

</aside>

😆 Suspense가 어떻게 이를 해결해주었을까요?

<aside> ✅

데이터 로딩 책임을 Suspense에 위임할 수 있었습니다.

</aside>

Suspense를 사용하지 않았을 때의 단점

흔한 데이터의 로딩을 관리하기 위해서는, 주로 isLoading, isFetching등 state를 사용해 조건부 렌더링을 하게 됩니다.

이럴 경우, 데이터 로딩 로직, 비즈니스 로직, 뷰가 모두 섞이면서, 컴포넌트 내에서 복잡도가 증가하게 됩니다.

특히 API를 불러오게 되면, 어떤 데이터를 불러오면 그 데이터를 보여줘야하는 렌더링에 대한 로직도 모두 통제하며 작성해야 하는데, 이럴 경우 구현 및 유지보수가 어려워져, 코드가 자연스럽게 복잡해지고 가독성과 순수성이 떨어지게 됩니다.

Suspense를 사용했을 때의 장점

Suspense를 사용하게 되면, 데이터를 로딩하는 로직이 단순해집니다.