Front-end/React

웹페이지에서는 데이터 요청 상태에 따라 UI는 다른 상태를 보여주어야 한다.데이터가 패칭 중 일 때 로딩 UI, 에러가 났을 때 에러 UI 등이 있다.위 상황을 처리하기 위해 다양한 방법을 사용할 수 있다.프로젝트에 적용하면서 유지보수성 및 가독성이 좋은 방법이 뭐가 있을까 고민하던 중Suspense와 ErrorBoundary를 활용한 선언적 데이터 패칭 처리 방법을 채택하게 되었고, 블로그로 정리하고자 한다.전통적인 데이터 패칭 처리@tanstack/react-query에서는 useQuery 값 내 isLoading, isError 상태값을 제공해 준다.아래는 useQuery를 사용해 standard 한 방법으로 비동기 요청으로 데이터를 받아와 사용자에게 전달하는 OrderList 페이지다.import..

React.lazy와 SuspenceReact.lazy & Suspence는 React 16.6에서 소개된 기능으로, 성능 최적화와 사용자 경험 개선을 목적으로 반영되었다. lazy – ReactThe library for web and native user interfacesreact.dev이전 웹 애플리케이션은 사용자가 아직 필요로 하지 않는 코드까지도 전부 불러와야 했다(SPA의 특징).이는 애플리케이션의 초기 로딩 속도를 증가시키고 성능 저하로 이어질 수 있다.React.Lazy&Suspence는 이 문제를 해결하기 위해 등장했는데, 개발자가 동적으로 컴포넌트를 로드할 수 있게 하여 애플리케이션의 번들 크기를 줄이고, 초기 로딩 성능을 개선할 수 있게 해준다.React.lazy컴포넌트를 동적으로 ..

보호되어 있는 글입니다.

loading loading = 'lazy' // {lazy} | {eager} 기본값은 lazy로 사용 된다. lazy일 경우, viewport에서 계산 된 거리에 도달할 때까지 이미지 로드를 연기해준다. 만약 eager일 경우 이미지를 즉시 로드해준다. Recommendation: This property is only meant for advanced use cases. Switching an image to load with eager will normally hurt performance. We recommend using the priority property instead, which will eagerly preload the image. 하지만, eager로 이미지를 긴급 로드 해버리면 ..

UTC (협정 세계시) UTC는 협정 세계시를 나타내는 국제 표준 시간이다. UTC는 그리니치 평균 시간 (GMT)과 동일한 값을 나타낸다. UTC는 고정된 시간대로, 시간대 변환 또는 일광 절약 시간(DST) 적용이 없으므로 시간 관리와 데이터 동기화를 훨씬 더 쉽게 만들어 준다. 서버에서 UTC 시간 사용 국제적인 일치성: UTC는 국제적인 시간 표준으로 사용되며, 서버에서 UTC 시간을 사용하면 모든 지역의 사용자에게 일관된 시간을 제공할 수 있다. 데이터 분리: 서버에서 UTC 시간을 사용하면 데이터를 지역 또는 시간대에 따라 구분하기가 더 쉽다. 서버 측에서는 위와 같은 이유로, UTC 시간을 기본으로 사용한다. 내가 진행하고 있는 프로젝트의 경우 다국어를 지원하는 웹사이트로, 숙박 예약 시설이..

사이드 프로젝트에서 타이머 기능을 구현했다. setInterval 함수를 사용해 1초마다 타이머를 갱신해주도록 설계했는데 몇가지 문제점이 존재했다. 문제점 예상했던 1초보다 더 느리게 갱신된다. ms 단위로 측정이 불가능하다. 먼저 이전 코드를 살펴보자. export interface Time { hour: number; min: number; sec: number; } function Timer() { const [isRunning, setIsRunning] = useState(false); const [isPaused, setIsPaused] = useState(false); const [time, setTime] = useState({ hour: 0, min: 0, sec: 0, }); useEff..

프로젝트에서 견적 요청 값에 따른 자동 계산식을 보여줘야 되는 기능을 만들게 되었다. 사용자가 선택한 여러 옵션값들을 종합하여, 자동으로 계산된 값을 보여줘야 했다. input으로 값을 받을 때, onChange 값이 바뀔 때마다 api를 전송한다면(위 사진 참고) 쓸모없는 api 요청이 발생하여, 웹 성능이 저하될 것이다. 예를 들어 유저가 수량 input에 숫자 100을 입력하려고 할 때, 디바운싱을 적용하지 않는다면 1 10 100 api가 3번이나 호출되고 나서야 원하는 값을 줄 수 있을 것이다. 디바운싱은 연이어 호출되는 함수들 중 마지막 함수만 호출하는 것을 말한다. 나는 특정 서비스 상에 구현되어 자동 계산식이라는 한정된 용어를 사용했지만, 기본적으로 검색 기능을 구현할 때 사용한다고 보면 ..

프로젝트 내에 한 리스트 페이지를 구현하면서 무한 스크롤 페이징 기능을 만들었다. react-query의 useInfiniteQuery와 IntersectionObserver를 사용하여 구현해 보았는데, 다른 페이지에서 반복적으로 사용될 수 있는 로직이 있어 custom hooks으로 분리하여 리팩토링을 해주었다. 이를 블로그로 정리해보고자 한다. 무한 스크롤 페이징의 구현 무한 스크롤 페이징의 구현방식은 다음과 같다. useInfiniteQuery를 통해 리스트 데이터를 일부 호출하여 보여준다. IntersectionObserver를 통해 view에서 지금까지 호출된 데이터의 리스트가 다 보였을 때를 target으로 인지하고 target이 보였을 때 && list에 다음 페이지 데이터가 있을 때 다음 ..

보통 개발환경의 주소는 http://localhost:3000을 사용한다. Api 서버의 주소가 https://dev-api.com 일때, 따로 cors 설정을 해놓지 않는다면, cors 에러가 난다. CORS 일반적으로 브라우저는 보안 문제상의 이유로 동일 출처 정책(SOP)을 따른다. 요청 URL과 응답 URL 두 URL의 프로토콜, 호스트, 포트가 모두 같아야 동일 출처로 볼 수 있다. 출처가 다른 호스트로 데이터를 요청하는 경우 CORS 정책을 위반하게 된다. 예를 들어 a-url.com 페이지에서는 b.url.com 호스트로 데이터를 요청할 수 없다. proxy proxy는 웹팩 개발서버로, proxy를 통해 브라우저에서 API 를 요청 할 때 백엔드 서버에 직접적으로 요청을 하지 않고, 현재 ..

create-next-app을 깔아보자. npx create-next-app create-next-app가 설치되고, 기본적으로 세팅되어 있는 page, public, styles 파일을 살펴보자. styles styles 폴더에서는 스타일 파일을 저장해준다. public public에는 페이지에서 사용할 공개 리소스를 넣을 수 있다. (ex. image) 그런데, public 파일 내부를 보면 우리가 이전에 사용했던 react 프로젝트, create-react-app와 달리 index.html 파일이 안보인다. 그 이유는 nextJS는 사전 렌더링 기능을 내장하기 때문이다. (pages에서 계속) pages NextJS는 싱글 페이지 어플리케이션(spa)을 제공한다. 서버에 요청이 오면 이 싱글 페이지..