뒤늦은 늦깍이 프론트엔드 개발..

서세윤·2025년 2월 28일

이제 본격적인 LMS개발에 앞서
팀과 공유를 하고자 프론트에 아는선에서 정리하고 공부하고있는 중이다.

이전에 얕은개발로 얼추 라이프사이클은 알고있엇으나,

리덕스 , 스테이트 등 간단한걸로만 구현했다는걸 이번에 뼈저리게 느꼇다..

사실 이전에 개발했을때
전역상태관리는 리덕스 원툴...?? 처럼 사용했엇으나
이번에 새로 개발하기에 앞서 다시 제대로 조사해보는 중이었다.

그래서 간단하게 정리할까 한다.



리덕스 vs react-query
이건 사실상 무의미한 질문이다.
왜냐하면 리덕스는 클라이언트 상태관리
react-query는 서버 상태관리이기 때문이다.

그렇다면 클라이언트 상태는 뭐고 서버 상태는 무엇인가?

대표적으로는
클라이언트 상태 : 테마 / 메뉴배치 등 기기에 특화된 상태 라고 생각하면 쉽다.
서버 상태 : DB를 통해서 가져와야하는 정보 등 (대표적으론 로그인{닉네임,프사 등})

이 있으며 명확하게 관리하는 대상이 다르다는걸 알 수 있다.

느낌이 왔다.
사실상 요즘 DB로 상태를 관리하는게 대부분이지 않나..?

테마 , 메뉴배치등도 기기에서 정보를 가지고 있기 보단 DB에 계정마다 설정을 저장해두는지라
클라이언트 상태보단 서버상태에 더 집중이 되는듯 하다.
https://tech.kakaopay.com/post/react-query-1/
조금 지난 게시글이지만, 카카오페이도 리덕스->리액트쿼리로 옮겨가는 듯 하다.

리덕스가 리액트쿼리보다 더 안좋다 라는 개념보단, 리액트쿼리로 옮겨져도 될 만큼 서버에서 상태관리를 많이 하고있으며, 디바이스에 의존하지 않으니 옮길수 있다 라고만 생각을 하고있다.

리덕스는 주로 주스탠드와 비교가 많이된다.
그러나 주스탠드(Zustand)는 리덕스에비해 풀이 좁다라는 의견이 대부분이다.
리덕스는 redux-saga 등 다양한 비동기 라이브러리를 보유하고있다.
그러나, 비동기가 왜 필요할까?
fetch가 필요한 작업이기 떄문이다.
fetch는 왜 필요할까? 서버에서 상태를 가져와야 하기 때문이다.

서버상태를 react-query로 사용한다면 쓰기 복잡한 리덕스는 굳이? 라는 생각이 들게 된다.
그러면서 간결하고 가벼운 주스탠드에 눈낄이 갈 수 밖에 없다.
리덕스도 RTX-query를 가지고있다.
ㅎㅎ
조합이 있는걸 봐선 주스탠드와 리액트쿼리를 조합으로 써야겠다는 생각이 강하게 든다.

주스탠드 = 겁나 쉽고 간단한 리덕스 버전
이라고 나는 이해하고 넘어가려 한다

이 글에서 집중하고 싶은건 리액트 쿼리

리액트 쿼리는 결국은 클라이언트단에서 캐시해주는 fetch라고 생각한다.
지속적으로 일정시간마다 fetch를 전송해 데이터를 따끈따끈한 새로운 데이터로 교체해준다.
???
그럼 setInterval fetch랑 뭐가다르냐? 할수있지만
생각보다 이 리액트쿼리는 몹시 똑똑하다.
우선, 브라우저를 보고있을떄만 동작을 한다.
또한 자동으로 캐싱이 되기때문에, 불피요한 fetch를 제외시킨다.
수동으로도 갱신 가능하다.
이 루프또한 설정이 쉽게 가능하다.
캐시는 1시간 유지, 데이터 가져오는 주기는 1시간 반마다.
혹슨 주기를 40분마다
뭐 이런식으로 관리가 쉽게 된다.

아직 작업은 안해봣지만, 상상해보았다.
회원 로그인 혹은 상태체크를 리액트쿼리로 1시간마다 체크하며 지속적으로 따끈따근한 회원상태를 유지한다.
그리고 일정시간이되면 즉시 값을 수정한다.

리덕스로만 사용할떄? 우선 전역상태 업데이트한뒤, 다른디바이스에서 수정하면, 리덕스 상태를 업데이트 할 일이있을대까지 업데이트가 절대 되지않는다.
여러모로 효율적이고, 사용하기도 쉽다.

그래서 결정했다
리액트쿼리를 주력으로 상태관리로 사용할 예정이다.
그렇게 어필할 생각이다.

profile
개잡부..

0개의 댓글