🥀 레벨로그의 리액트 쿼리 도입기

🤔 왜 리액트 쿼리?

먼저 리액트 쿼리가 뭐하는 라이브러리인지를 가볍게 설명하자면, 데이터 Fetching, 캐싱, 동기화, 서버 쪽 데이터 업데이트 등을 쉽게 만들어 주는 라이브러리이다. 이전에 내가 다뤄봤던 Redux와는 다르게 클라이언트 데이터가 아니라 서버 데이터들을 관리하기 쉽게 도와준다.

고민 끝에 리액트 쿼리를 도입하게된 흐름을 아래에서 상세한 이유와 적용해보니 어땠는지 알아보도록 하자!

---

1️⃣ 선언적인 코드 작성

지난 5차 데모데이 때, 백엔드의 쿼리 개선으로 API Response의 변경이 있었다. 그래서 메인페이지에서 팀 상세 페이지로 들어갈 때, 팀 상세 정보를 새로 요청해야했기에 화면 깜빡임이 발생했다.

추가적으로 팀 필터링 기능이 추가되면서도 팀이 필터링이 되는 동안, 필터링 되기 전 팀 화면에서 가만히 기다리고 있어야하는 상태가 발생했다.

사용자가 느끼기에 답답한 점이 있을 것 같아 “스켈레톤 UI”를 활용하려고 마음을 먹었으나, 지금 코드는 꽤나 명령형이라 컴포넌트 렌더링 전에 분기문을 통해 처리를 해줘야했다.

const Components = () => {
	// ...

	if (isLoading) return <Loading />
	if (isError) return <Error />
		
	return (
		<div>data</div>
	)
} 

간단히 작성해보면 이런식이다!

하지만 페이지에서 가져오는 상태가 많다면 isLoading , isError 값이 많아지고 일일히 분기 처리를 해주어야했다. 값이 늘어나면 누가 먼저 도착할 지 모르는 비동기의 경쟁 상태도 상당히 골치 아픈 문제가 되었다.

그렇다면 다른 방법으로 가져오는 상태를 하나로 묶어서 전체가 로딩되기 전까지 렌더링을 하지 않아야했다. 하지만 컴포넌트가 아닌 뒷면에서는 이를 처리하는 코드가 늘어나고, 무엇보다 위와 같은 분기처리가 컴포넌트에서 늘어나고 비즈니스 로직에서 에러 처리 코드가 반복되고 늘어나면서 컴포넌트와 함수가 하는 역할이 점점 가려지는 문제가 발생했다!

이를 위해 리액트의 Suspense 와 ErrorBoundary 를 이용해 비동기로 가져오는 상태의 성공, 실패, 로딩에 관한 처리를 역할에 맞는 곳에 위임해 코드를 선언적으로 리팩터링하는 과정을 거치려했다.

---

2️⃣ “waterfall”식 상태관리의 문제점

그러나, 레벨로그에서는 하위 컴포넌트를 멍청하게 만들기 위해 Page 단위의 최상위 컴포넌트에서만 데이터를 요청하고 하위 컴포넌트를 이를 받아서 화면을 그려주는 역할만 하도록 설계했다.

Suspense 를 도입하려했지만, 이미 최상위 컴포넌트인 Page 에서 데이터를 모두 기다렸다가 화면을 그리기 때문에 하위 컴포넌트에서 Suspense 를 사용할 수가 없다.

이를 위해서는 상위 컴포넌트에서 모든 상태를 받아와 생겼던 의존성을 제거하고, 하위 컴포넌트가 자신이 필요한 상태값을 직접 요청하도록 하도록 해야했다.

즉 전체적인 상태관리의 방식이 변화해야했다. 이러한 문제점들을 리팩터링 과정에서 인지하고 도입할 수 있는 가장 적합한 라이브러리가 리액트 쿼리라는 결론이 내려졌다.

---

🥀 리액트 쿼리

아직까지 ErrorBoundary 는 도입을 하지 못했고, (아마 그대로 가져다 쓰기엔 좀 아쉬운 부분들이 조금 있어서 살짝 개조해서 쓰게 될 것 같다) Suspense 의 경우에는 대부분 도입했다. 생각보다 리액트 쿼리가 지원하는 기능들이 많아서 복잡했던 데이터 fetching과 커스텀 훅들이 간소화되는 효과를 배우 많이 봤다.

리액트 쿼리를 도입하면서 이전에 가지고 있었던 문제점들이 해결이 되었는지 페이지 컴포넌트 코드의 변화를 살펴보자!

---

리액트 쿼리 도입 이전

해당 사진의 코드는 InterviewTeams 페이지로, 전체 팀을 불러와 보여주는 페이지이다. 보다시피, 여러 문제점이 있었는데 하나씩 살펴보자.

1. isActive 는 status(전체 데이터 fetching이 성공했는지, 아직 response가 도착하지 않았는지, 실패했는지를 가지는 값이다.)를 통해 "전체 팀"의 상태를 알려주고, 이를 통해 컴포넌트에서는 알맞는 처리를 일일히 해주어야 했다.

2. 전체 팀의 데이터와 어떤 유형의 팀(진행중, 종료, 나)을 불러오는지도 페이지 컴포넌트에서 처리를 완료해 아래로 내려주기 때문에 Suspense 나 ErrorBoundary 를 사용할 수 없다.

---

리액트 쿼리 도입 이후

이제는 위에 있던 문제점들을 어느정도 해결했음을 살펴볼 수 있다!

1. 더 이상 isActive 의 status 프로퍼티는 필요 없어졌다! 당연한 것이 해당 컴포넌트에서 전체 팀 데이터를 fetching을 하지 않고 하위 컴포넌트에서 역할을 넘겨 주었기 때문이다.

2. 그렇기 때문에 Suspense를 사용해 하위 컴포넌트에서 필요한 상태를 아직 불러오지 못했다면 <Loading /> 컴포넌트를 보여주도록 깔끔하게 처리가 됐다! 이제 ErrorBoundary만 적용된다면 비즈니스 로직에 있는 복잡한 에러 처리 코드들도 걷어낼 수 있을 것이다.

---

🧐 후기

아직 부족하거나, 모르는 부분들이 많아서 다음주에 마지막 데모 준비가 끝난다면 한 번 더 이 주제로 포스팅을 하고 싶다!