react-query 즉 Tan Query 를 통해 서버 상태를 선언적으로 관리하여 많은 문제 해결을 할 수 있습니다. 아래와 같은 시나리오를 가정해보죠. 현재는 리덕스 툴킷을 사용하여 프론트 측의 전역 상태에 스키마를 정의하고 정규화를 수행하면서 채팅앱을 구현하였습니다.로그인한 내가 있고 나는 프로필 이미지와 성별, 닉네임, 이미지들, 게시물들, 등등의 정보를 가집니다.일대일 채팅방은 채팅방 아이디, 마지막 메시지 타입, 마지막 메시지 내용, 채팅방 참여자 두명의 정보, 읽지 않은 갯수 등의 정보를 가집니다.채팅 메시지는 아이디와 타입, 내용, 보낸사람 아이디, 보낸사람 닉네임, 받는사람 아이디, 받는사람 닉네임, 채팅방 아이디 등의 정보를 가집니다.게시물은 아이디, 제목, 이미지, 작성자, 좋아요 ..
react-query 는 서버 리소스 기준으로 fetching 하고 상태관리 하는 라이브러리라고 보면 되겠죠? 간단하게 사용할 때는 유용할 거 같긴한데 redux, thunk 조합 보다 유연성은 떨어질 거 같은데 또 redux-persist 같은거 사용도 안 될 거 같고, 두개를 동시에도 많이 사용하시나요?저는 개인적으로 그냥 올라운드라 커버 가능한 redux, thunk 조합을 사용하는게 일관되고 유연성이 있어서 더 좋아보이긴 하는데요.. 그럼 redux, thunk 기본 조합에 캐싱? 그런 기능 필요시 그에 맞게 추가해야겠죠? react-query 는 그냥 그 자체만으로 따로 취급해야 하는거겠죠? redux, thunk 방식에 react-query 를 연동한다던가 하는 그런 성격의 것은 아닌거죠?만약..
React Boundaries 라는 것은 선언형으로 전체 에러처리에 좋다. 그리고 react- https://www.youtube.com/watch?v=hszc3T0hdvU react-error-boundary 라는 라이브러리를 추가로 사용해야 한다. react-query 와 같은 api 단계의 에러 처리는 onError 부분에서 처리해주면 좋다. react-error-boundary 를 사용한 React Boundaries 는 전체 에러 처리용. (앱 전체에 걸쳐 예기치 않은 에러 모두 포함) api 단계의 에러처리 부분은 해당 부분 에러처리를 위한 것. 또한 api 부분 외에도 각 포인트 별로 에러처리가 필요하다면 적절한 곳에 포인트를 주면 된다. Exception 와 Error State 는 다르게..
번역: https://react-query.tanstack.com/guides/paginated-queries Paginated/Lagged Queries 페이지네이션 데이타를 렌더링하는 것은 리액트 쿼리에서 매우 일반적인 UI 패턴입니다. 단지 페이지 정보만을 포함하면 작동합니다. const result = useQuery(['projects', page], fetchProjects) 하지만, 이 예제를 실행하면 이상한 걸 알 수 있습니다: success / loading 상태를 들락날락거립니다. 왜냐하면 각 새로운 페이지는 새로운 쿼리로 취급되기 때문입니다. 이러한 부분은 적절하지 않습니다. 그리고 운 나쁘게도 많은 툴들이 이렇게 동작합니다. 하지만 리액트 쿼리는 아닙니다! 예상하듯이, 리액트 쿼리는..
infinite scroll 을 구현하는 경우 useQuery 로는 대응이 안된다. infinite scroll 의 경우 page 가 한개씩 늘어나면서 늘어난 page 가 데이터에 추가되는 식이다. 참고로 pagination 은 새로운 page 로 데이터가 갱신된다. react-query 는 useQuery, useInfiniteQuery 를 대표적으로 사용한다. pagination 은 useQuery 로 대응한다. https://react-query.tanstack.com/reference/useQuery https://react-query.tanstack.com/guides/paginated-queries https://react-query.tanstack.com/guides/infinite-quer..
자꾸 한번씩 의심을 하게 된다. redux 대신 좀 더 쉽게 사용할 수 있는 전역 상태 라이브러리는 없는가에 대해서... 하지만 다른 것들은 쉬운게 아니라 기능이 없는 것이다. redux 가 아직까지는 제일 낫다. 그러나 recoil 은 아직 experimental 인데 이 경우는 아직 잘은 모르겠고 (왜냐하면 리액트 팀의 공식 라이브러리이니깐...) constate 라던가 뭐 이런건 그냥 거의 contextAPI 와 hook 를 사용한 단순한 라이브러리 정도여서 그냥 기능이 없을 뿐이지 심플한 것이 아니다. React 의 useState, useReducer 같은 거 사용한 contextAPI 와의 조합 정도... 전역 상태는 redux-toolkit 이 현재로서는 최고의 선택. flux 패턴의 구현체..
정리해보면 nextjs + react-query + redux-toolkit + rtk-query + react-hook-form + yup 의 구성이 좋다. SSR 이 아니라면 CRA (create-react-app) 로. SSR 이면 CNA (create-next-app) 로. 물론 모두 typescript 를 적용. React-Query, RTK-Query, SWR 등은 요청 캐싱용 라이브러리이지 리액트에서 말하는 컴포넌트의 상태, 리덕스의 전역 상태와는 관련이 없다. Hook 와 단일자원(웹소켓이라던가 DB 라던가)의 조합은 마치 전역 상태와 같은 늬앙스를 줄 수 있는데 이는 Hook + 단일자원 이 원래 그러한 역할을 할 수 있기 때문이다. 이것이 늬앙스가 비슷하다하여 마치 리덕스 전역 상태를 ..
redux toolkit 과 함께 사용하기에는 rtk-query 가 더 좋아보인다. rtk-query-docs.netlify.app RTK Query - Powerful data fetching and caching for Redux | RTK Query RTK Query is an advanced data fetching and caching tool, designed to simplify common cases for loading data in a web application. rtk-query-docs.netlify.app github.com/klis87/redux-requests klis87/redux-requests Declarative AJAX requests and automatic net..