본문 바로가기
React

React에서의 상태관리

by 2__50 2023. 2. 13.
공부한 내용을 정리한 글입니다 
내용에 오류가 있거나 더 좋은 의견이 있다면 댓글로 남겨주세요.
배움에 큰 도움이 됩니다. 🖋

 

 

프론트앤드 개발을 하며 만나는 상태


우리가 관리하는 상태는 서버와 교류가 필요한지 여부에 따라 client, server 2가지로 나뉜다.
모달, 토스트, 다크모드 설정 등 데이터를 브라우저 내에서만 관리한다면 client 상태이고, 서버에서 받아온 데이터이거나 인스타처럼 내가 사이트에서 상호 작용한 내용이 다른 사용자 화면에도 똑같이 반영되어야 한다면 server 상태에 해당한다.

 

개발하던 서비스는 주로 서버에서 데이터를 받아와 처리하는 일이 많았기 때문에 client 상태는 코드 설정이 가벼운 recoil, server 상태는 react-query로 관리하게 되었다.

 

 

Client 상태


recoil을 사용해 전역으로 관리

  • 모달, 토스트 같이 여러 컴포넌트에서 호출하는 경우

 

https://recoiljs.org/

 

props를 이용해 자식 컴포넌트로 전달

  • 나머지 대부분의 상태

 

https://javascript.plainenglish.io/react-context-do-you-really-need-it-this-will-help-you-decide-bcbdae589f70

 

팀에서는 클라이언트 상태를 위와 같이 관리했다.

조금 번거롭더라도 전역에서 불필요하게 많은 상태를 관리하는 것은 지양했기에 대부분의 상태는 props를 사용해 지역적으로 관리했다.
전역 상태의 생명 주기는 애플리케이션의 생명 주기와 같기 때문이다. 상태가 전역에 있으면 실제 해당 상태가 필요한 컴포넌트는 2군데 뿐 일지라도 항상 메모리를 차지하게 된다.

 

상태를 전역으로 관리할 필요가 있을 경우 recoil을 사용했다. 리덕스를 도입할 만큼 방대한 양은 아니었기 때문이다. 관리할 상태가 많지 않고 간단한 경우라 빌트인 hooks Context API를 사용해도 되지만, recoil을 써보고 싶은 마음이 있었다. 선배의 제안으로 사용해보니 편리해 그 뒤로 계속 사용하게 되었다.

 

지금와서 생각해보니 서비스에서 상태를 관리하는 것에 대해 충분히 고민해본 적이 없었기 때문에 그저 팀에서 제안하는 방식을 따라갔던 것 같다. props drilling 방식은 컴포넌트가 여러 단계로 나눠져 있을 경우 props를 필요한 모든 곳에 추가해야 되기 때문에 개발 과정에 번거로움이 있다. 또한 전달하는 props와 이를 위한 함수가 많아질수록 코드가 정갈함과는 거리가 멀어진다.

이번에 상태 관리에 대해 생각하며, 서비스를 개발 할 때 코드를 유지보수하기 편하도록 정갈하게 관리하는 것, 개발 과정이 수월한 것 또한 메모리 관리만큼이나 중요한 부분이라고 생각되었다. 팀이 더 좋은 방향으로 나아갈 수 있도록 함께 고민하고 방법을 제시하는 사람이 되어야겠다.

 

 

Server 상태


 

React Query 상태의 흐름


이전에는 서버와 통신 시 응답 결과 외에 별도의 success 값을 내려주어 성공 여부를 판별했다. 그러나 react query에서 제공하는 onSuccess, onError 등의 내장 메서드는 통신 이후의 처리를 굉장히 간단하게 만들었다. 이외에도 서버 상태를
불러오고, 캐싱하고, 동기화하고 업데이트하는 것을 돕는 각종 기능을 기본으로 제공해 서버 통신 작업이 간결해지도록 돕는다. 사용 만족도가 높은 라이브러리다.

 

 

 

 

참고


https://jbee.io/react/thinking-about-global-state/

 

전역 상태 관리에 대한 단상 (stale-while-revalidate)

이 글의 부제는 Stop Using Redux for Caching for API Response이다. 한 때 전역 상태 관리 도구로 Redux를 즐겨썼던 개발자로서 이제 더이상 Redux를 사용하지 않게 된 이유와 회고를 담은 글이다. Table of Contents

jbee.io

 

https://yrnana.dev/post/2021-08-21-context-api-redux/

 

Context API가 존재하지만 여전히 사람들이 redux와 전역 상태관리 라이브러리를 쓰는 이유 | nana.log

context api는 글로벌 상태관리 라이브러리를 대체할 수 없고, 여전히 많은 리액트 개발자들이 redux, mobx 등을 사용하고 있다.

yrnana.dev

https://tech.kakao.com/2022/06/13/react-query/

 

My구독의 React Query 전환기

안녕하세요, 톡FE파트에서 My구독, 이모티콘 스토어를 개발하고 있는 Hugo입니다.My구독은 정기 결제를 통해 ‘이모티콘 플러스’, ‘톡서랍 플러스' 서비스를 이용할 수 있는 구독형 서비스입니

tech.kakao.com

https://tech.osci.kr/2022/07/13/react-query/

 

React-Query 도입을 위한 고민 (feat. Recoil) - 오픈소스컨설팅 테크블로그 - 강동희

Web Frontend 개발을 할 때 React 를 사용하면서 마주하게 되는 여러 가지 문제점 중 하나는 state, 상태 관리에 관한 부분입니다. 프론트엔드 개발자라면 state 와 뗄 수 없는 인연을 맺고 있습니다.오늘

tech.osci.kr

 

'React' 카테고리의 다른 글

[React] 오픈소스 살펴보기_Hook의 구현체를 찾아서  (1) 2023.12.01
[Next.js] Redux  (0) 2023.08.06
React의 useMemo와 useCallback  (0) 2023.02.09
React Component와 Hooks의 Lifecycle  (0) 2023.02.09
[React] React vs Vue  (0) 2020.07.02

댓글