⭐️리액트쿼리(tanstack query) 도입 근거

1. 서버 상태를 관리하기 위한 코드를 직접 구현하다보면 코드가 길어지고 이로인해 유지보수가 어렵다.

우리가 웹 개발을 할 때 리액트에서는 다양한 상태를 사용한다. useState와 다양한 전역상태 관리 라이브러리를 통하여 우리는 이를 관리한다.

우리가 기존에 서버 상태를 받아와 사용했던 방식은 다음과 같다

const MainPage = () => {
	const [simmy, setSimmy] = useState(null); // useState를 통해 상태를 선언

	const userDataFetch = async () => {
		try{
			const response = await axios.get(API_URL);
			setSimmy(response.data.simmyData) // api를 통해 받아온 데이터를 useState에서 선언한 상태로 관리
		}
		catch(error){
			console.error(error.message)
		}		
	}
	
	useEffect(() => {
		useDataFetch()
	},[])
	
	return 
		<div>
			<h1> 시미 데이터 가져오기 </h1>
			{simmy && <p>{simmy}</p>}
		</div>
}

useState로 관리?

위 코드를 보게 되면 서버에서 받아온 데이터, 즉 서버상태를 useState를 통해서 관리하게 된다.

하지만 다른 여러가지 클라이언트 상태를 관리할 때도 useState를 사용하게 되며, 결국에 useState 를 통해서 서버 상태와 클라이언트 상태를 “모두” 관리하게 되는것이다…

→ 이렇게 되면 서버 상태를 관리할 때에도 컴포넌트의 생명주기를 고려해야하고( 필수적으로 사용하는 서버 데이터 캐싱 같은 전략을 구현하기 어렵다), 클라이언트 상태와 분리해서 관리할 수 없으니 코드가 길어지고 지저분해진다….

그렇다면 전역 상태 관리 라이브러리로 서버 상태와 클라이언트 상태를 분리해서 관리하면 되는거 아니야?

React-Query 를 사용했을 때와 비교해보면 코드가 너무 장황해지고, React-Query에서 간단하게 제공되는 기능들(데이터 캐싱, 로딩 상태, 에러 상태 ...) 을 직접 구현해야하며, 이에 대한 규격화된 방식이 없기 때문에 모두 개발자가 결정하고 구현해야한다.

→ 코드가 길어지면 유지보수가 어렵고, 직접 기능들을 구현하려면 불편하고 시간이 많이들겠다. React-Query가 있는데 굳이 직접구현을 할 필요가 없다.

<aside> ⭐ 리액트 쿼리(탄스택 쿼리)는 리액트쿼리 자체만으로 서버 상태 관리가 가능하며 기본 적으로 제공하는 다양한 기능들을 직접 구현할 필요가 없어서 코드의 길이가 줄어들고 유지보수가 용이하다

</aside>

2. 리액트 쿼리의 API 요청 수행을 위한 규격화된 방식 제공