React Query와 상태관리 :: 2월 우아한테크세미나

1월에 이어 회사 분들이랑 같이 들었다. 1부는 기초 내용이었고 2부는 원리도 조금 설명해주셨다. 1월보다 기대를 덜 하고 들었는데 더 재밌었던 듯!

1부

•

Store에서 비동기 통신 분리하기 (feat. React Query)

•

프론트엔드에서 상태관리란? 

•

이 화면들을 모두 다른 레포지토리에서 3명이서 관리했었음

•

react-saga 등이 현재에도 적정 기술인가? 

•

어떤 상태를 관리하기 위해서

•

어떤 적정 기술을 사용해야 하는지

•

string 형태도 내부에서는 결국 배열으로 바뀌어요

•

enabled 

•

발표자 답변: 1번을 쓰고 1번이 불가능하면 2번을 쓸 것이다

•

발표자 답변: option.onSuccess에서 처리

2부

•

주문 데이터 → 데이터의 최신성이 중요해서 많이 사용하지 않음

•

중복 상태는 어떻게..? API 

•

QueryProvide가 필요한 이유 

•

storage 접근: experimental로 persist 기능 제공 

•

best practice 리서치중.. 

Q&A

•

생산성, 유지보수, 기술스택 측면

•

레거시: 우아한 JS → 유지보수가 끝난 프레임워크

•

비슷한 역할. 

•

react-query가 더 많은 기능과 인터페이스를 제공하는 걸로 알고 있다

•

비교 페이지 보면 나와있음 

•

ㅇㅇ.. isLoading 합치는 편. isLoading 관리하는 변수 두고 사용 

•

먼저 보여줄 애들은 먼저 보여주기도 함 → 상황에 따라 다르게 처리 

•

mobX 사용중. 

•

리덕스 너무 길어서 간략하고 도메인 단위로 묶이는 mobX 사용 

•

도메인 별로 모으니 중복되지 않음 

•

함수명? 자체를 쿼리키로 사용. 

•

enum 으로 관리하자는 제안도 했음

•

팀이 많아서 다 다르다

•

크게 신경쓰지 않는다 

•

API 별로 커스텀할 일이 많아 각각 옵션 따로 넣어서 사용 

•

컴포넌트가 비대해지는 문제점 

•

onSuccess 시 첫 번째 성공인 경우에만 뭔가 처리할 수 있게 해주는 기능이 추가되면 좋겠다 

•

공부하는 입장에서 둘 다..

•

사가 공부하고 불편한 점도 느껴보고 쿼리로 넘어와라 

•

‘대체 가능하다’ 라고 하긴 어렵지만.. api 관련된 전역 상태를 대체. 

•

데이터 성격에 따라 다를 것 같다 

•

쿼리 캐시에 있는 자체로 쓰거나, 로컬 스토리지에 넣어서 쓰거나, 클라이언트 state .. 등등 

•

데이터 가공하는 함수를 만들 것 같다?? 

•

에러 바운더리는 쓰지만 suspense로 호출하지는 않는다 

•

suspense 안 쓰는 이유는 experimental 단계라서. 

•

섞어 쓰면 편하다. 나는 experimental이라서 안쓰지만.

•

도메인: 배너, 오더 등등.. 이 있고, 코어 라는 도메인을 따로 빼거나 할 것 같다

•

백엔드 도메인을 따라갈 수도 있을 것 같다 

•

뮤테이션도 마찬가지 

•

별개로 사용. 컴포넌트에서 필요한 값들이 합쳐진다 

•

갓재후 ui 관련?? 공통 스테이트들 

•

재후님 이름 캡쳐하다 못들음 

•

이걸 왜 물어봐! 

•

아키텍쳐 통합과 엮어서 진행. 프로덕트별로 하나씩 옮김. 주문 내역 → 주문 이후 → 등등.. 

•

프로덕트가 작다면 한 번에 해도 될 것 같고.. 프바프

•

쿼리는 스트링 말고 배열로도 사용할 수 있음. 페이지 숫자를 쿼리에 넣으면 됨

•

검색조건을 state로 관리하면 refetch 잘 되더라고요.

•

enabled: false 주면 됩니다~

•

fetch 를 인위적으로 호출하면 실행은 되니 참고~

•

뷰 컴포넌트는 분리하는 편. 

◦

ui test 편하고 

◦

로직과 분리하기 위해서

•

화면에 보이는 이상 캐시에 있는 것.

•

staleTime이 cacheTime보다 긴 거는 설정을 잘못 한 것..

•

코드가 더 짧아졌고 관리하기 편해졌다 

•

client state, server state 잘 분리해서 관리해야 복잡도를 낮출 수 있다 

•

먼 미래의 일

•

부끄럽지만 커버리지가 높지는 않다 