발단
포트폴리오에서 전역 상태 관리 및 비동기 작업을 Redux toolkit 을 사용해 관리하고 있다. 그런데 거의 변하지 않는 데이터임에도 불구하고 컴포넌트가 마운트 될때마다 서버에 요청을 보내는게 불필요(낭비라고)하다고 느껴졌고, 자주 변하는 데이터와 그렇지 않은 데이터를 구분할 필요가 있다는 생각이 들었다.
생각이 여기까지 닿자, 현재 구조에서 Redux toolkit 을 사용하는게 적합한가? 라는 또 다른 의문점이 생겼다. 오버엔지니어링은 아닌지, 이번 프로젝트에서 state 를 관리하는데 최적의 방법이 무엇인지에 대해 고민도 해보고 다양한 방법을 찾아보았는데 여기저기 흩어져 있던 생각을 정리해봤다.
State 를 어떻게 관리할 것인가?
state 가 해당 컴포넌트에서만 혹은 부모-자식의 얕은 관계에서만 쓰인다면 굳이 Redux 를 사용할 필요는 없다. Redux 는 전역 관리 상태 라이브러리 라는 정의에 맞게 전역에서 사용하는 state 를 다룰때, 흔히 props driling 을 방지하기 위해 사용하곤 한다. 하지만 지금 만들고 있는 애플리케이션 속 핵심 로직이 부모 컴포넌트 밑에 자식 컴포넌트들이 동등한 형제관계로 존재하고 있다.
따라서 위 구조에서는 형제 컴포넌트끼리 props 를 주고 받아야 한다면, 부모 컴포넌트를 통해야만 가능해진다. 이럴경우 부모 컴포넌트로 모든 데이터를 보내서 각 컴포넌트에 props 로 내려줘야 하므로 부모 컴포넌트는 점점 비대해지고, 렌더링 될때마다 하위 모든 컴포넌트들이 쓸데없이 렌더링 된다는 문제점이 생긴다.
그래서 각 컴포넌트에서 필요한 데이터를 가져다 쓸 수 있도록 전역 상태 관리 라이브러리가 필요하다는 결론이 나왔다.
Redux 로 데이터를 처리하면서 생긴 다른 문제점
Redux 를 사용하면서 몇가지 다른 고민들이 생겨났다. 예약 시스템은 실시간으로 데이터가 변하기 때문에 컴포넌트가 렌더링 될 때마다 API 를 요청해서 새로운 데이터를 가지고 오는 편이 맞다.
반면, 단순 정보만 제공하는 컴포넌트는 매번 API 요청을 할 필요가 없다. (자주 변하는 데이터가 아니므로)
이처럼 불필요한 서버 요청을 막기 위해 캐싱의 필요성을 느끼게 되었고, 캐싱 처리를 하는 로직을 직접 설계하기 보다는 fetching, 캐싱 등을 도와주는 라이브러리를 사용해보면 어떨까 하는 생각이 들어 각각의 특징을 살펴봤다.
Redux-toolkit 과 RTK-Query 를 같이 사용하자
데이터 처리 및 캐싱을 도와주는 대표적인 라이브러리는 React-Query 와 RTK-Query 가 있다. 찾아보니 두 라이브러리의 역할 및 사용 방법은 비슷해보였다.
따라서 현재 Redux-toolkit 을 사용하고 있기 때문에 별도의 패키지 설치 없이 사용 가능한 RTK-Query 를 사용하기로 결정했다.
RTK-Query 와 Redux-toolkit 을 같이 사용하면서 가장 좋았던 점은 리덕스 툴킷의 보일러플레이트로 작성해야 했던 로직들이 확 줄었다는 점이다.
export const massageSlice = createSlice({
name: "massage",
initialState,
reducers: {},
extraReducers: (builder) => {
builder.addCase(fetchMassageList.pending, (state) => {
state.status = "loading";
});
builder.addCase(fetchMassageList.fulfilled, (state, action) => {
state.status = "succeeded";
state.massageList = action.payload;
});
builder.addCase(fetchMassageList.rejected, (state, action) => {
state.status = "failed";
state.errorMessage = action.payload;
});
},
});위에 error, status 작업 처리를 아래 한줄로 가능해졌다.
const { data: massageList, isFetching, isError } = useGetMassageListQuery();생각을 정리하면서...느낀점
불과 몇개월전만해도 서버에 요청해서 응답받는 것만으로도 만족했었던 적이 있었다. 그리고 리팩토링이라고 해봤자 코드를 조금 더 보기 좋게 다듬는 정도였는데, 조금씩 공부하다보니 이 방법이 최선일까? 라는 생각이 들기 시작하면서 다른 방법을 찾아보고 적용시켜도 보고 하면서 조금씩 더 나은 개발자가 되어가고 있는 것 같다는 생각이 들었다🤗
프론트엔드 영역에서는 서버와의 API 통신, 그리고 서버로부터 받은 데이터를 어떻게 처리할 것인지가 핵심적인 부분이라고 생각한다. 이 부분이 사용자 경험 측면에서도 큰 부분을 차지하기 때문에 어떻게 하면 서버 데이터를 최대한 효율적인 방식으로 처리할 수 있을까에 대해 더 많이 고민해봐야겠다.
