코딩을 잘하고 싶은 코린이 동토니

Next.js에서 현재 route에 접근하거나 다른 route로 이동하는 등 라우터에 대한 접근이 필요할 때 next/router패키지를 사용하게 됩니다 (page router 기준)해당 모듈은 다음과 같은 방법들로 사용할 수 있습니다. useRouter 훅 사용 default로 export되는 Router 싱글톤 객체를 사용하기 Next.js에서는 싱글톤 객체 사용 방법은 현재 사라진 상태이며 useRouter를 이용하는것을 권장하고 있습니다. Next.js 동작 방식우선 next/router에 대해서 알아보기전에 Next.js 동작방식에 대해서 이해할 필요가 있습니다.SSG (Static Site Generation) : 빌드 타임에 HTML 생성 & 캐싱된 HTML을 기반으로 매 요청마다 재사용SS..

사내 결제 페이지 개편이유 사내 결제 페이지 (이하 payment) 프로젝트가 1차적으로 릴리즈되었을 당시 통일되지 않은 부분들이 굉장히 많았었습니다.1.  기존의 payment 프로젝트가 억지로 끼워 맞춘 부분이 많았다.예를들어 api호출을 할때 axios, react-query가 혼합되어 사용 되었다거나,니콘머니 충전, 콘구매 페이지 까지의 처리방식과 실제 결제를 진행하는 페이지에서의 처리방식이 다르거나,컨벤션이나 구조가 잡혀있지 않아서 각 파일마다 코드의 흐름이 다르다던가 등등 여러가지의 이유가 있었습니다.2. 불필요한 컴포넌트 분리가 너무 많았다.리팩토링을 진행한 가장 큰 이유였습니다.컴포넌트가 굳이 분리가 되지 않아도 되는 부분에서 분리가 되어 있었고 오히려 분리가 되지 않아야 할 부분에서 분리..

사내 비즈니스 프로젝트인 제휴몰에서의 결제방식을 내부 결제 시스템으로 연결하는 작업이있었고 이를 위해 MSW를 통해 결제시스템 연결을 사전준비하기로 했다. 이슈사내 결제시스템으로 연결하기 위해선 구매하려는 콘아이템의 정보가 필요하다.하지만 구매 이전 단계의 화면들이 기획되지 않았고 API를 어떤 라우터를 사용해야하는지도 명확하지 않았기 때문에 어차피 결제 페이지 연동만 할거라면 주문서 작성에 필요한 데이터만 모킹해서 사내 결제시스템으로 연결하기로 결정했다.MSWMSW는 mock service worker의 줄임말로 브라우저의 서비스 워커를 통해 서버로 호출하는 실제 네트워크 요청을 intercept해서 가상의 response를 보내주는 API mocking 라이브러리이다.MSW를 사용하면 실제 data를..

주요 변경점useQuery1. 컨벤션의 변화기존 : queryOptions에 queryKey와 queryFn이 포함되지 않았음const { data: paymentPromotions, isSuccess } = useQuery(PaymentPromotionsKey.all(),fetchPaymentPromotions,)변경 : queryOptions에 모들 property 추가const { data: paymentPromotions, isSuccess } = useQuery({queryKey: PaymentPromotionsKey.all(),queryFn: fetchPaymentPromotions,})2. options의 변화(많은 변화가 있지만 제일 많이 사용하는 위주로 정리)cacheTime (삭제) =..

1. data 캐싱 여부에 따른 initial status- cached = true - status === 'success'- cached = false - status === 'loading'2. loading status- 캐싱된 데이터가 없다면 항상 true- 데이터를 호출 하고 나서야 false로 변경 (호출 이후 status = loading => 'success' | 'error')- react-query에서의 loading의 의미는 데이터를 불러오는 중이 아닌 아직 데이터가 없는 상태3. fetchStatus- 기본 값 'idle' (쿼리가 아무런 동작도 하지 않는 상태)- query 실행시 'fetching' 으로 상태 변경4. enabled의 고찰- useQuery 혹은 useQueri..