brunch

You can make anything
by writing

C.S.Lewis

react-query로 데이터 처리하기

파트너스 레거시 코드 리팩토링(2) api 로직, react-query

안녕하세요, 플랫폼 개발팀 프론트엔드 개발자 제리입니다.

오늘은 지난 시간에 소개드린 파트너스 서비스의 레거시 코드들을 어떻게 개선하였는지 소개해드리겠습니다.


리덕스 스토어 안의 덕스 패턴에 얽힌 API 분리하기


 기존 파트너스 프로젝트는 Redux를 활용하여 전역 상태의 값을 관리하였고 actionTypes , actions , reducer을 하나의 파일로 관리하는 덕스패턴으로 구성되어 있었습니다. 그리고 api의 엔드포인트까지 actions 안에 묶여있어, React-query를 도입하기 앞서 api의 엔드포인트를 별도의 폴더로 분리하여 관리할 필요성을 느꼈습니다.

덕스패턴으로 관리되던 기존의 파트너스 리덕스 스토어, 액션 안에 API까지 묶여있다.


클래스형 vs 함수형


 API들을 모아서 관리할 API 폴더를 생성하고, 클래스형과 함수형 중 어떤 스타일로 api 파일을 작성할지 고민하였습니다. 

 클래스형으로 작성되면, API가 어떤 클래스의 매서드로 관리되는지 해당 클래스 명칭으로 명확하게 알 수 있습니다. 즉 사용할 때의 직관성과 개발 편의성을 높여주는 장점이 있습니다. 하지만 클래스 전체를 호출해 오기 때문에, 같은 클래스에 묶여있는 사용하지 않는 다른 api도 가져온다는 성능상의 단점이 있습니다.

클래스형으로 작성된 api파일


 반면 함수형으로 작성되면, 사용하는 api 함수만 가져와서 쓸 수 있어, 클래스형으로 작성된 코드보다 이론상 성능상의 이점이 있습니다. 하지만, 어떤 api의 로직인지 알아보기 어려워 클래스 형태보다 직관성이 떨어져서, 네이밍을 더 구체적으로 해줘야 한다는 개발 편의상의 단점이 있습니다.

함수형으로 작성된 api 파일


결론 - 클래스형으로 작성


 새로운 api를 정의하는 것이 아닌, 기존에 있던 api를 분리하는 리팩토링 작업이라서 기존의 액션네임을 api명으로 가져오는 것이 이후의 리팩토링 작업 시에도 혼란이 적을 것이라고 판단하였습니다. 또한 클래스 전체를 불러와도 컴포넌트 상에서 같은 클래스에 묶인 메소드들은 같은 컴포넌트에서 사용될 가능성이 많고, 함수형태로 작성된 방식이 체감할 만큼의 성능 개선을 가져오지는 못한다고 판단하여 api 파일을 클래스형으로 작성하기로 결정하였습니다.



주입된 store를 react hooks로 개선하기 


 기존 파트너스 웹에서는 클래스형 컴포넌트와 함께, connect로 작성된 중첩 HOC로 inject 컴포넌트를 만들어 컴포넌트 단위로 필요한 리덕스 스토어를 주입해서 사용했습니다. 하지만 함수형으로 리팩토링을 진행하고 React hooks를 사용할 수 있게 되며,  useSelector로 그 기능을 대체할 수 있습니다. 이는 훨씬 더 직관적이며, 불필요한 props drilling을 걷어낼 수 있습니다. 

컴포넌트에서 사용할 스토어 명을 직접 주입한 경우
useSelector로 개선한 코드 - 불분명한 props 넘기기 탈출!


불필요하게 전역상태로 관리되던 값들을 react-query로


 리덕스를 사용하고 있지만 실제로 전역에서 사용되지 않고 있던 값들을 react-query로 리팩토링 하였습니다. react-query를 통해 불필요한 스토어 사용을 없애며, 리덕스로 값을 관리하기 위해 작성되었던 코드들을 걷어낼 수 있게 되었습니다. 또한 데이터의 처리를 간편하고 효율적으로 관리할 수 있게 되었습니다.


 기존에 useState를 활용하여 pending 처리를 직접 관리하던 코드는 react-query를 통해 간편하게 pending 상태를 처리할 수 있게 되었습니다.

기존의 pending 처리(useState와 useEffect로 함수호출 전, 후 직접 관리)
react query 도입 이후, invitationStaffsQuery.isLoading으로 간편하게 pending 상태 처리


다음은 staff 데이터와 초대를 받은 staff 데이터를 각각 호출 후 비교하여 같은 staffId에 대해 초대를 받은 staff 데이터 안에 들어있는 전화번호 정보를 staff 데이터에 추가해 주는 기존 코드입니다. 하나의 함수 안에 너무 많은 기능이 있고 코드의 가독성이 좋지 못한 상태입니다. 또한 이 함수 내부에서 에러가 발생해도 추적이 어렵습니다.

너무 많은 처리를 맡은 기존의 파트너스 코드 내 함수.

react-query를 도입하면서, 위의 코드는 데이터 호출, 에러 및 상태처리, 데이터 가공의 과정으로 각각 분리되었습니다. 이를 통해 각 기능이 작동되는 곳에서 필요한 상태에 따라 명확하게 사용할 수 있도록 개선되었습니다.

react-query 도입 이후 기능과 목적이 명확해짐.


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari