Front-end
웹페이지에서는 데이터 요청 상태에 따라 UI는 다른 상태를 보여주어야 한다.데이터가 패칭 중 일 때 로딩 UI, 에러가 났을 때 에러 UI 등이 있다.위 상황을 처리하기 위해 다양한 방법을 사용할 수 있다.프로젝트에 적용하면서 유지보수성 및 가독성이 좋은 방법이 뭐가 있을까 고민하던 중Suspense와 ErrorBoundary를 활용한 선언적 데이터 패칭 처리 방법을 채택하게 되었고, 블로그로 정리하고자 한다.전통적인 데이터 패칭 처리@tanstack/react-query에서는 useQuery 값 내 isLoading, isError 상태값을 제공해 준다.아래는 useQuery를 사용해 standard 한 방법으로 비동기 요청으로 데이터를 받아와 사용자에게 전달하는 OrderList 페이지다.import..
기존 사내 프로젝트는 session방식으로 인증 구현을 해왔다.현재 유지보수하고 있는 프로젝트에서 추후 확장성을 이유로 session에서 JWT으로 인증 방식을 바꾸게 되었다.session과 JWT 구현 방식이 무엇이고 어떤 차이가 있는지 정리하고, 발생했던 동시성 이슈와 해결 방법에 대해 정리해보고자 한다.Session세션 방식이 인증되는 방식은 아래와 같다.클라이언트가 인증정보(email, password)를 서버에 전송서버는 메모리에 사용자를 저장하고 Session Id를 클라이언트에 쿠키로 전달 클라이언트는 쿠키에 저장된 Session Id를 사용해 요청 서버는 일치하는 Session Id를 메모리에서 검색한 후 있다면 권한 부여Session 방식의 장점Session Id를 서버에서 관리하기 때문..
React.lazy와 SuspenceReact.lazy & Suspence는 React 16.6에서 소개된 기능으로, 성능 최적화와 사용자 경험 개선을 목적으로 반영되었다. lazy – ReactThe library for web and native user interfacesreact.dev이전 웹 애플리케이션은 사용자가 아직 필요로 하지 않는 코드까지도 전부 불러와야 했다(SPA의 특징).이는 애플리케이션의 초기 로딩 속도를 증가시키고 성능 저하로 이어질 수 있다.React.Lazy&Suspence는 이 문제를 해결하기 위해 등장했는데, 개발자가 동적으로 컴포넌트를 로드할 수 있게 하여 애플리케이션의 번들 크기를 줄이고, 초기 로딩 성능을 개선할 수 있게 해준다.React.lazy컴포넌트를 동적으로 ..
문제 상황 현재 진행하고 있는 프로젝트가 배포 마무리 단계에 이르렀는데, 한 가지 문제점이 존재했다. 메인 페이지의 초기 렌더링 시간이 너~무 느리다는 것이었다. 페이지에 접속해 전체 콘텐츠가 로드되기까지 거의 7초 이상이 소요됐었다. 웹에서는 next/image Image 컴포넌트를 사용해 최적화를 진행하고 있었다. Image 컴포넌트를 사용하면, 기본적으로 이미지를 자동으로 최적화하고 크기를 조절해 더 작은 파일 크기로 로드하게끔 도와준다. 진행 프로젝트의 메인페이지를 불러오는 리소스만 36.7MB가 사용되었다. 반면 네이버의 경우 전체 메인 페이지를 불러오는 리소스는 8.9MB 정도였다. 개발사이트의 메인페이지에서는 불러오는 이미지만 12.6MB였는데, 네이버의 경우 4.1MB 정도였다. 제공하는 ..
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번이나 호출되고 나서야 원하는 값을 줄 수 있을 것이다. 디바운싱은 연이어 호출되는 함수들 중 마지막 함수만 호출하는 것을 말한다. 나는 특정 서비스 상에 구현되어 자동 계산식이라는 한정된 용어를 사용했지만, 기본적으로 검색 기능을 구현할 때 사용한다고 보면 ..
