앞서 비즈니스 로직에 대한 피드백을 받은 후 술먹은 듯한 게시글을 쓰고 다시 한번 비즈니스 로직에 대해서 공부를 해봤다. 멘토님께서도 너무 고민하고 있는 것이 눈에 보이셨는지, 본인이 생각하는 비즈니스 로직이란 특정 도메인에서 해당 도메인의 데이터를 중심으로 일어나는 서비스의 핵심 로직이라고 하셨다. 여기서 내가 생각하지 못한 단어가 등장했는데, 바로 도메인이다. 지금까지 비즈니스 로직을 알기 위해서 공부했을 때 디자인 패턴에서 사용하는 비즈니스 로직 등 자연스럽게 디자인 패턴으로 구분한 로직은 전부 비즈니스 로직이라고 생각했다. 하지만 도메인을 추가해서 검색을 했을 때는 전혀 다른 검색 결과가 나오게 되었다. 그래서 비즈니스 로직과 비즈니스 로직이 아닌 것으로 공부를 이어나갔다. 먼저 비즈니스 로직에 ..

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

서비스 워커는 브라우저가 백그라운드에서 실행하는 스크립트로, 웹페이지와 별개로 작동하면서 웹페이지 또는 사용자의 인터랙션이 필요하지 않는 기능을 제공한다. 오프라인에 문제가 생겼을 때 해결을 하기 위해서 등장하였다. 개발자에게 오프라인 환경을 통제할 수 있는 권한을 부여해서, 오프라인 환경에서 캐시와의 상호작용, 백그라운드 동기화, 푸시 알람 등의 기능을 가능하게 했다. 서비스 워커의 특징 ▶ 사용자가 요청해야 동작하고, 목표하는 일이 끝날 때까지 꺼지지 않는다. ▶ 웹페이지 밖에서 동작하기 때문에 브라우저의 열고 닫힘과는 무관하게 동작한다. ▶ 브라우저 밖에서 동작하므로 DOM 요소에 접근할 수 없다. 활용 예시 ▶ 캐시와의 상호 작용 서비스 워커가 Fetch 이벤트의 중간자 역할로 HTTP를 통해 정..

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

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

개발을 하다보면 CI 또는 CD에 대한 이야기를 많이 들어본다. 간단하게 알기론 내가 git에 코드를 올리면 누군가가 빌드와 테스트, 배포를 해줘서 쓸대없는 시간이 낭비되는 것을 방지할 수 있다 프로젝트를 진행할 때 수정, 빌드, 배포하는 과정을 통해 작업한 내용이 실제로 동작하는지 테스트하고 검증할 필요가 있다. 이것을 매번 수동으로 반복하면 시간이 걸리고 실수를 할 수 있다. 이를 위해서 CI / CD가 생겻다. CI ? 지속적인 통합이라는 뜻이다. 개발을 진행하면서 품질도 관리할 수 있는 것으로 여러 명이 하나의 코드에 수정을 진행해도 지속적으로 통합해서 관리할 수 있다. CI는 개발자가 빌드와 테스트를 직접 하지 않고도 수정한 코드를 브랜치에 병합하기만 하면 자동으로 빌드와 테스트를 검증할 수 있..

프로젝트를 진행하면서 나는 지금까지 View Logic과 Business Logic이 각각 JSX 영역은 View Logic이야! 그외 모든 함수 및 상태는 Business Logic이야! 라고 생각했었다. 그래서 Business Logic을 나누기 위해서 Custom Hook을 사용하겠어! 라는 생각을 하게 되었다. 그리고 멘토님께 해당 부분에 대한 피드백을 받았는데, Custom Hook을 사용하는 것은 중복된 Logic을 해결하기 위해서 사용한 것으로 보인다. 하지만 " 이것이 Business Logic은 아닌 것 같다. " 라는 이야기를 들었다. 많이 당황했다. 내가 너무 쉽게 생각한걸까? 하지만 이 역시 오히려 좋은게 내가 실무에 들어갔다면 잘못 생각하고 있었다는 사실을 알고 있어도 바로바로 공..

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