지금까지 React Query에 대해서 공부를 했었는데, redux devTools은 있는 것을 알았는데, React-Query DevTools이 있다는 것은 방금(글쓰기 전 ㅋ ) 알아서 지금 추가로 정리하려고 글을 작성한다. 기본적으로 Dev Tools은 React-Query에서 기본적으로 제공하기 때문에 추가적인 패키지를 설치할 필요가 없다. 또한 Development 모드에서만 작동하고, Production 모드, 즉 배포 상태에서 제외 시키는 작업은 안해도 된다. import React from "react"; import ReactDOM from "react-dom/client"; import "./index.css"; import App from "./App"; import reportWeb..

정말 많은 글이 있고, 많이들 알아보는 내용이다. 과연 이 둘의 차이는 어떤 것이 있을까? 프레임워크 ▶ 설계부터 코드 작성 스타일까지 모두 도구의 방식을 따라야 한다. ▶ 짜여진 프레임 내에서 작업하기 때문에 프레임워크이다. 라이브러리 ▶ 도구를 사용해서 생산성을 개선하는 것에 포커스가 잡혀있다. ▶ 인터페이스를 크게 제약하지 않는다. ▶ 전체 설계까지 영향을 미치지 않는 것이 보편적이다. 강제성 개발을 할 때 정해진 방식으로 개발을 해야하는지? 자유롭게 개발을 할 수 있는지? 제어권이 개발자에게 있는지? 툴에 있는지? 강제성에서의 차이가 있을 것이다. 그렇다면 내 블로그에 많이 올라오는 React는 라이브러리일까? 프레임워크일까? ▶ 자유도가 높으니 라이브러리이다! ▶ 홈페이지에 라이브러리라고 적혀있..

프론트엔드 개발을 하다보면 API를 사용하는 경우가 당연히 있다. 로그인 처리, 게시글 목록 등등 아주 다양하게 당연하게 필요하다. 이것을 가져와서 연동하는 작업을 수행하기 위해서 따로 모킹 서버를 만들어줄 수 있지만, 아주 번거로운 작업이다. 이것을 Mock Service Worker를 통해서 해결할 수 있다. 어떤 방법으로? 풀 네임 그대로 Service Worker를 사용해서 기능을 제공한다. 간략하게 Service Worker에 대해서 설명하자면, 일종의 대리 서버로 리소스 요청을 가로채 수정을 할 수 있고, 리소스를 세부적으로 캐싱해 조작할 수 있다. 이것을 활용해서 네트워크를 사용하지 못하는 환경에서도 어떤 방식으로 동작하는지 조작이 가능하다 MSW도 Service Worker와 비슷하게 동작..

앞서 겉핥기에서 React Query의 캐싱은 stale과 cacheTime을 통해 이루어 진다고 말했다. Stale 말 그대로 " 신선하지 않은 " 을 뜻한다. React Query에서는 캐싱된 데이터를 기본적으로 stale 상태로 여긴다. 여기서 말하는 신선하다는 것은 서버에서 조회한 데이터는 요청한 당시의 snapshot이고, 외부 요청으로 데이터가 변경된 경우 브라우저가 가진 데이터는 오래된 데이터가 되어버려서 stale하다고 하는 것이다. 그러므로 stale 상태란 뜻은 최신화가 필요하다는 것으로 refetch 상황에 refetch가 발생한다. refetch가 되는 조건으론 ▶ 새로운 Query Instance가 마운트 될 때 ( 페이지를 이동했다가 왔을 경우 ) ▶ 브라우저 화면을 이탈했다가 ..

이번에는 React-Query를 사용하면서 일어날 수 있는 상황을 직접 테스트하고, 해당 상황에 전역 상태 관리가 필요할지, 필요 없다면 어떤 방식으로 처리할 지 공부하려고 한다. 전역 상태 관리를 사용하는 목적 중 하나가 서버의 데이터 요청을 처리하고 그것을 전역으로 관리하는 목적이였다. 근데 이것을 React Query를 사용하면 조회했던 데이터는 useQueryClient 를 사용해서 같은 트리에 있는 컴포넌트로 사용할 수 있게 된다. 그렇게 되면 전역 컴포넌트를 사용하는 경우가 많이 줄어들지 않을까? 생각한다. 로그인 유지하기 유저 정보를 가져온 다음 mypage로 이동 후 유저 정보를 useQueryClient로 조회하고, 새로고침 시 어떻게 되는가? 일반적으로 유저 정보를 로그인 후 가져오고 ..

들어가며 지난번 React-Query에 대한 필요성을 간략하게 알아봤다. 이번에는 React-Query 자체에 대해서 정리를 해보려고 한다. React-Query ? 서버에서 값을 가져오거나, 캐싱, 값 업데이트, 에러 핸들링 등 비동기 과정을 사용할 때 도움을 준다. 기존 Redux, Mobx, Recoil 같은 상태 관리 라이브러리가 있지만, 서버 데이터와 클라이언트 데이터를 분리시킬 수 있다는 장점이 있다. React-Query의 장점 ▶ 서버의 상태 업데이트, 데이터 패칭, 캐싱 등을 쉽게 할 수 있도록 도와준다. ▶ Redux 등, 전역 상태 관리를 통해서 서버의 데이터를 비동기로 가져오기 위해서는 추가적으로 작성해야하는 코드 많지만 React-Query는 간단하게 처리해준다. ▶ 코드가 간단해..

들어가며 벨로퍼트님의 테스팅 튜토리얼을 공부한 내용을 정리하는 글입니다. 작업환경 설정 간단한 자바스크립트 환경에서 함수 테스트 코드를 작성하기 위해서 테스트 환경을 만들어보자! npm init -y npm install --save jest @types/jest npm init -y 명령어를 통해서 자바스크립트 프로젝트를 만들고 jest를 설치해준다. 테스트 작성하기 // javascript/sum/sum.js function sum(a, b) { return a + b; } export default sum; // 본인은 귀찮아서 그냥 react 환경에서 작성 ㅎㅎ... 아주 간단한 sum 함수이다. 테스트 코드를 작성하기 위해서 sum.test.js 파일을 작성하자 // javascript/sum/..

들어가며 바로 어제 테스팅 게시글을 하나 작성했는데, 이번에 또 좋은 글을 하나 더 발견해서 추가로 작성하려고 한다. 테스트란? 테스트 개발에서 테스트는 우리가 작성한 코드가 잘 동작하는지 검증하는 것을 의미한다. 솔직히 프론트엔드에서의 테스트는 어제 글을 작성했지만서도 실행해서 직접 확인하면 되는 거니 필요성을 못느꼇다. 하지만 테스트를 수동으로 하나하나하는 것은 번거로운 일이다. 이것을 자동화한다면 편하게 검증이 가능하다. 테스트 자동화의 이점 협업을 하다보면 내가 작성한 코드를 다른 사람이 수정해야하는 경우가 있고, 내가 다른사람의 코드를 수정하는 경우가 있다. 규모가 점차 커지면 커질수록 수동으로 확인하는 일에 많은 시간을 사용하거나 특정 상황을 고려하지 못한 경우 기능의 일부가 고장날 수 있다...