코드노트

현재 사이드 프로젝트를 진행하면서 SWR을 사용해보자는 생각으로 시작했다. 그렇게 리액트쿼리랑 조금씩 멀어지면서 느낀건 리액트쿼리 만한 라이브러리가 없다는 것... 프로젝트가 끝나가면서 팀원들과 디자인을 새로 변경해보자는 의견이 나왔고.. 새로 디자인 작업을 하면서 지금까지 만든 로직들을 전부 변경해야하는 일이 발생했다. 그렇게 api도 조금씩 수정해나가야했는데 그냥 리액트쿼리로 변경할까요? 라는 의견에 다른 프론트엔드 팀원도 좋다고하여 리액트쿼리로 다시 변경했다. 그렇게 리액트쿼리 공식문서를 모두 읽었다. 내가 모르는것들이 많았다... 이번에 리액트쿼리 v5를 사용하면서 기존에 있었던 것들과 추가된 것들에 있어서 더 편하게 사용할 수 있는 기능들을 정리해보려고 한다. 그리고 알고 넘어가야 하는것들도 같..

이번 팀 프로젝트에서 리액트쿼리를 사용하고있다. 팀프로젝트를 하면서 공통된 로직들을 줄이는게 가장 좋다고 생각이 들었고, 로직구현이 완료되고 API 연동 작업을 하면서 에러핸들링에 있어서 팀원들끼리 상의를 하여 나온 공통 에러 핸들링! 공통 에러 핸들링을 구현하면서 만난 문제들 1. trt catch를 사용하면 useMutation에서 onSuccess에서 에러가 잡힌다. 2. useQuery에서는 onSuccess, onError를 사용할 수 없다. - 공식문서에서 나오길 무한루프이슈때문에 더 이상 사용할 수 없다고 한다...ㅜㅜ 우리는 axios를 사용하면서 then이 아닌 try catch를 사용하기로 컨벤션을 정하였고, 에러핸들링을 하면서 문제들이 생겼다. 그렇게 구글링을 했지만 try catch..

리액트를 하면서 항상 고민하게되는 부분은 상태관리인거 같다. 이번 팀 프로젝트를 진행하면서 리덕스를 사용하지않고 ReactQuery와 Zustand를 통해 상태관리를 하기로 하였다. 두 상태관리 라이브러리의 차이와 목적에 대해서 정리해보려고 한다. 프론트엔드에서 상태관리에 있어서 가장 처음 만나게된건 리덕스였다. 리덕스를 하게되면서 전역관리를 알게되고 redux-toolkit, redux-saga, redux-thunk 등등 미들웨어도 사용했다. 리액트 상태관리는 리덕스? - 컴포넌트끼리 상태값을 직접 소통하게된다면 컴포넌트 재사용에 있어서도 좋지 않으며, 불필요한 리렌더링이 발생하거나 코드들도 복잡해지게된다. - 리덕스로 상태관리를 할때 장점도 있었지만 단점들이 있었다. 먼저 리덕스에 대해서 정리해보자..