[%] 리액트 쿼리는 어떨때 쓰는건가요? 서버상태랄게 뭐가 있나요?

[익명(nhswynxcvun3)]

서버에서 바로바로 DB 값을

바로 가져오고, 수정해서 또 바로 가져오고 하는데

서버상태랄게 뭐가 있나요?

DB에서 다 관리하는데 서버상태랄게 뭐가있나요?

프롬프트

DB

네거티브
프롬프트

샘플링

DPM++ 2M Karras

스타일

None

- dc official App

[익명(116.251)]

하나의 요청에 여러 컴포넌트에 필요한 값이 있다고 하면 예전에는 그걸 리덕스 사가에서 요청해서 전역상태에 담아서 사용하는 방식이였음. 존나 번거로움 요즘은 그냥 리액트쿼리로 필요한 모든 컴포넌트에서 다 요청하는데, 쿼리 키만 똑같이 해놓으면 딱 한번만 요청해서 그 컴포넌트들에서 리턴값을 다 쓸수있음. 그걸 그냥 서버상태라고 부름 ㅇㅇ

[익명(nhswynxcvun3)]

아하 그럼 리덕스의 store 역할을 api.js가 하고 있는거라고 생각하면 되나요? - dc App

[익명(nhswynxcvun3)]

리덕스도 쓰면서 리액트쿼리도 쓴다는 사람이 있었데 그런 경우는 뭔가요? - dc App

[익명(116.251)]

마즘 근데 리덕스나 주스탠드같은 전역상태 관리 도구들은 여전히 쓰이는데 걔들은 이제 클라이언트에서 파생된 상태들만 관리하는거지. 그래서 그거랑 구분해서 리액트쿼리는 서버상태라고 부르는거고. 실제로 쿼리키값에 캐싱되어있는 상태가 맞기도 하고 리액트쿼리나 SWR같은 서버상태 라이브러리가 처음 나왔을때 저걸 가지고 클라이언트 상태까지 관리하는 이상한 짓거리를 하는 사람들도 있었음

[익명(126.28)]

제가 그 병신중 한명입니다

[익명(116.251)]

그래서 요즘 보면 리덕스를 쓰더라도 사가는 거의 안쓰고 리덕스의 스토어 구조가 옛날에 비해서 아주 단순한 경우가 많음 그런데 아직 그 시절 버릇 못버리고 리액트쿼리로 서버에 요청하고, 그 값을 또 리덕스에 넣고, 이렇게 개발하는 사람들이 많음. 도도가 그거에 개빡쳐서 왜 그딴짓 하냐고 리액트쿼리에서 요청 성공시 실행해주는 콜백을 아예 없애버림. 아직은 쓸수있는데 차기 버젼부터 못쓴다고 들었음

[익명(116.251)]

126.28 // 네이버 다니는 사람들도 하던 병신짓이니까 니가 이상한거 아님

[black7375(221.168)]

Optimistic 업데이트할때 나는 post 결과로 바꿔치는걸 선호하는데, refetch해야하는게 마음에 안들긴함

[black7375(221.168)]

아, 추가적인 불만이 있는데 스트리밍 데이터 처리하기가 힘듦;;;; isPending 같은 것 쓸때 딱 필요한데...

[익명(211.209)]

서버상태는 님말대로 좀 이상한단어임. 더 헷갈리만듬. 정확히는 Promise 성격의 의도를 가진 데이터만 별도 보관하는 상태관리자임. 그럼 왜 Promise만 별도 상태관리자일까?

[익명(211.209)]

Promise 데이터는 FE개발에서 보통 독특한 특성을 가지고 있음. 1. 호출을 보통 특정 뷰가 mount되는 시점에 시도함 (특히 리액트같은 선언형을 추종하는 곳에서는 더더욱) 2. React 상태관리로는 Promise state를 다룰 수 없음.

[익명(211.209)]

이 두가지를 해결하는게 react-query임. 1. mount시점에 알아서 refetch를 시도하고 비효율적인 호출을 방지하기위해 캐시값도 관리함. 2. Promise State를 자연스럽게 녹아들게 함. 이게 함수형(선언형)에 더 근접한 방식이고, 리액트 랜더링과 같이 데이터 페칭을 다룰 때 응집도를 높일 수 있는 좋은 방법임.

[익명(211.209)]

어떤 상태던지간에 의도에 딱맞는 솔루션이 있음. API에서 쏴주는 데이터면 앤간하면 react-query같은게 좋긴하겠지. 근데 리얼월드는 모든 케이스가 내 맘처럼 돌아가지는 않으니까. 어쩔수없이 redux를 쓸 수 도 있음. 그럼 거기서 생기는 불편함을 이해하고 줄이려는 노력은 해야지 redux toolkit처럼.

[익명(116.251)]

너무 복잡할때는 그냥 예전처럼 리덕스, 리덕스 사가 쓰는게 낫긴 하더라. 그런면에서 좀 아쉬운게, 나는 useQuery의 onSuccess 콜백이 이런 복잡한 경우에서 쓸수 있는 간편하고 괜찮은 대안이라고 생각했는데 지들 방향과 다르다고 갑자기 없애버리는게 좀 맘에 안들었음

[익명(211.209)]

복잡하다는 정의가 내가 알기로는 '선언형'에서 외부 의존성이나 파생상태를 다루기 버거워질때 일거임? 원래 함수형에서 그게 제일 첼린징한 포인트야. 아마 문서 잘 찾아보면 그 문제를 해결할 수 있는 방법을 충분히 제공해주고있거나, 리덕스, 리덕스 사가없이 리액트 도구만으로도 해결할 수 있을걸?

[익명(211.209)]

내가 생각했을 때 리덕스의 가장 큰 장점은 리덕스는 get/set을 할 때 그 메소드 호출방식이 모두 'string' action key로 함. 많이 느슨해서, 이벤트가 실행되기전, 실행된 후에 온갖 이벤트를 다 붙일 수 있음( redux saga같은 애들이 해주는 거..) 요런게 클라이언트에서 정규화나 값 조작할 때 꽤 유용하게 먹히긴 함.

[익명(116.251)]

내가 겪은 복잡한 케이스는 서버에서 응답받은 값과, 뮤테이션에 넣는 페이로드와, 클라이언트 인터랙션에서 파생된 상태가 같이 엮여있을때였음. 지금 만드는 제품이 다 그런방식의 구현이 필요해서. 원래는 onSuccess 콜백으로 전역상태를 업데이트하는 옛날방식 쓰다가 지금은 다 갈아엎어서 리액트 도구만으로 다 해결하고 있긴 함 그런데 그냥 리덕스, 리덕스사가로 해결하는게 더 편하지 않았을까 하는 생각이 들어서 말이야

[익명(211.209)]

응 그게 내가말한 함수형에서 외부값(side-effect)에 대한 문제가 아닌가 싶다. 젤 단순한 방식은 useEffect 떡칠. 이게 제일 최악. 두번째 방식은, 전통적인 명령형 개발방식 XX할떄 다음에 YY 하고 기다렸다 ZZ하자. 같이 fsm을 그리는거. 로직을 코드로 표현하기 젤 쉽고. 이게 님이 말한 Redux-Saga방법. 마지막으로, 함수형으로 fetching시작했으면 모든 상태변환과 관리를 함수형으로 만들어두는것도 좋지. 근데 요건 함수형 처리에 대한 어느정도의 지식이 있어야 하거나, 님 상태에서는 가지고 있는 도구로도 처리 못할 수 있음.

[익명(211.209)]

적당히 타협보는건 useSyncExternalStore같은거로 내부 비즈니스 로직 감춰서 처리하는것도 나쁘지 않을것같기도하고. 함수형이 이래서 참 까다로워. 선언형으로 모든걸 다 맞추려고 하면 누군가 뭔 기능을 지원해줘야해서 거기에 의존해야하기도 하고 말이야..

[익명(211.209)]

form에 얽힌 문제라면 차라리 redux-toolkit query처럼 lazy하게 호출을 컨트롤 할 수 있게 만드는 솔루션을 쓰는것도 나쁘지 않았을거임.

[익명(116.251)]

fsm으로 처리했고, 몇몇 페이지는 특정 시점에 뮤테이션의 onSuccess에서 useQuery를 리패칭하는 방법도 씀. 그 이전에 이걸 좀 명확하게 보이도록 하려고 인터렉션이 진행되는 컴포넌트와, 쿼리와 뮤테이션이 처리되는 컴포넌트를 완전 분리함. 인터렉션이 진행되는 컴포넌트에 데이터와 뮤테이션 콜백을 주입하는 방식으로

[익명(116.251)]

폼보다는 조금 더 복잡한게, 퍼널페이지로 구성된 서비스이고, 복수의 퍼널페이지들의 상태들이 상호작용이 필요한 앱임 여튼 이미 구현이 다 끝나서 유지보수만 하고있긴 함

[익명(211.209)]

오 그것도 하나의 방법인듯. 컴포넌트 분리 후 주입시키기. 컴포넌트 레벨이면 훅보다는 컨트롤하기 쉬우니까.

[익명(211.209)]

님 케이스를 들어보면 rtk가 더 적합했을수도... 하지만 이미 선택한거 님처럼 처리한 경험 얻은게 더 꿀

[익명(116.251)]

컨트롤 하기도 쉽고, 인터랙션하는 페이지의 인터그레이션 테스트가가 쉬운것도 이점임. 고민 많이해서 만들었다

[익명(116.251)]

무엇보다도 팀원들이 리덕스 경험이 아예 없었던것도 선택에 큰 이유중 하나였음. 러닝커브가 좀 높긴 하니까

[익명(211.209)]

테스트 환경 어케했는지 궁금하긴하네. 그냥 모킹데이터 같은거 컴포넌트에 직접주입으로 푸는건가? 나도 비슷하게 하려고 준비중인데, 테스트까지 잘풀리면 완전 좋을 것 같아서

[익명(116.251)]

ㅇㅇ 인터그레이션은 모두 모킹 넣어서 돌리는 식으로 했음. 근데 이게 3가지 어플리케이션의 상호작용이 필요한 서비스라, 이건 인터그레이션으로 할 수가 없어서 e2e 테스트의 비중이 제법 큼. 유닛테스트는 전혀 없고, 인터그레이션 70%에 e2e 30% 정도?

[익명(211.209)]

고생했네. 뿌듯할듯. 퍼널, 폼은 진짜 어떤걸 선택할지, 기획이 어떻게 될지에 따라 난이도가 극악으로 달릴듯. 컴포넌트 위주로 분리하고 테스트해보는건 나도 이번 플젝에서 써봐야겠음 좋은 아이디어 ㄱㅅ.

[익명(125.143)]

공홈에 친절히 떠먹여주고 있는데 그냥 가서 읽어..