지난번에는 React와 Nginx를 함께 사용해서 배포하는 작업을 진행했다. 이번에는 React와 Nginx를 Docker를 사용해서 이미지화 시켜서 컨테이너로 클라이언트를 배포할 계획이다. 환경 정보 Server : Naver Cloud os : Ubuntu 20 필요한 파일 설치 apt install npm // npm 설치 sudo apt-get install build-essential libssl-dev curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash source ~/.bashrc // nvm 설치 nvm install 18.12.1 // 필요한 npm 버전 설치 npm을 설치하고 defaul..

React 프로젝트를 만들고 이제 배포를 하는 작업이 필요하다. 여러가지 방법이 있겠지만 역시 가장 만만한건 Nginx가 아닐까 생각된다. Naver Cloud에 Nginx를 사용해서 배포하는 작업을 진행할 것이다. 환경 정보 Server : Naver Cloud os: 우분투 20 서버를 만드는 작업은 이전에 작성한 글이 있기 때문에 그것을 참고하길 바란다! 그리고 기본적으로 배포할 React 프로젝트가 있다는 것은 전제로 진행하겠다. 필요 파일 설치 apt install npm npm이 서버에 설치되어 있지 않을 것이기 때문에 설치해준다. apt install nginx 마찬가지로 nginx도 설치되어 있지 않기 때문에 설치해준다. 패키지 가져오기 뭐 별거 없다. 깃허브에 저장되어 있는 Repo를 클..

지금까지 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는 간단하게 처리해준다. ▶ 코드가 간단해..