Chunho’s DevLife

[React] createPortal을 사용한 z-index 제어

룰렛을 구현하던 중 React-Tooltip과 디자인이 맞물려 원하는대로 툴팁의 레이어가 위치하지 않게되는 문제가 발생하였다.우선 룰렛은Wheel(원판)outline(원판 외부 테두리)pointer(룰렛 포인터)tooltip(원판에 있는 각 아이템을 클릭했을 시 나오는 툴팁) 으로 구성이 되어있다.wheel: 1   outline: 2   tooltip: 4   pointer: 3그리고 각 요소의 z-index는 위와 같이 나타나야 한다. 즉 툴팁은 가장 상단에 위치해야하는 상황이다. 이 때 디자인상 컴포넌트 트리 구조가wheel 내부에 outline, tooltip이 위치해야 하였고, pointer는 wheel 외부에 독립적으로 존재해야하는 상황이였다. 이 때 문제는 tooltip이 wheel 안에 있..

{status !== "RESULT" && ( )} {status === "RESULT" && ( )}위와 같이 React Status에 따라서 조건에 맞는 컴포넌트가 mount, unMount 될 때 각각의 애니메이션이 실행되도록 motion.div를 사용하여 initial 값과 exit, animation의 값을 설정해주었다. 하지만 status가 변경되는 동시에 아무런 애니메이션이 실행되지 않았고, 원인을 찾아보았다. 원인은 생각보다 간단했다,,,Framer Motion이 DOM에서 제거되는 구성 요소를 처리하기 위해 AnimatePresence가 필요하기 때문에 MotionDiv..

서버에서 응답으로 내려주는 데이터 중 게임 실행 준비가 완료되었다는 상태가 있을 경우, 폴링을 사용하여 로딩 Indicator를 돌리다가 실행 처리를 해줄 수 있다. 위 기능을 간단하게 구현해보기 위해 hook을 하나 만들어주었다. const wrapPollingRef = useRef(false); 우선 Ref 하나를 생성해 준다. const { mutate: play, isLoading } = usePostAPIExEndPoint({ mutation: { onSuccess: (data) => { if (data.result === "SUCCESS") { showLoading(); setGameStatus({ ...gameS..

Next/Image를 사용하여 이미지 최적화를 하기위해 Next.js로 프로젝트를 진행하고 있지만, 게임 특성 상 Loaing  상태일 경우 loading indicator가 보여지는게 더 적합할 것 같아 프로젝트 전체적으로 CSR을 사용하고 있었다. 이 때, 적합한 페이지는 SSR을 적용해봐도 좋지 않을까 고민하다 상점 페이지에 SSR을 적용해본 뒤 CSR을 했을때와 어느정도의 성능 차이가 있고, 어떤 방식이 더 효율적일지 테스트를 해봐야겠다고 생각했다. 상점은 API에서 특히 더 많은 양의 데이터를 받고 있으며 렌더되는 이미지의 양도 많았다. 우선 React-Query를 사용하고 있는 환경에서 SSR을 적용하기 위해 공식문서에 나와있는 대로 SSR을 위한 초기 설정을 해주었다.https://tanst..

React Cycle 내에서 앱 전반적으로 Task를 Scheduling 할 수 있는 Core Class가 필요했다. Task를 순차적으로 처리해야 하므로 FIFO 구조의 Queue를 사용하였으며,  type Task = () => void;class TaskService_ { private queue: Task[] = []; private isProcessing: boolean = false; enqueue(task: Task): void { this.queue.push(task); } execute(): void { if (!this.isProcessing) { this.processQueue(); } } processQueue(): void { this.i..

각종 이벤트, 미션을 통해 보상을 받는 경우 유저가 Claim 버튼을 단시간 내에 여러번 클릭하여 서버에 여러번 요청이 들어가고 중복 요청으로 인한 비정상적인 응답 및 에러가 발생하는 이슈가 있었다. 위 문제를 해결하기 위해 여러가지 방법을 사용할 수 있었고, 나는 lodash에서 제공하는 debounce 함수를 사용해 문제를 해결했다. View Model에서 mutation을 정의하고 const { claim, claimAll } = ExViewModel();위와 같이 mutate 함수를 구독해 사용하는 과정에서   const debouncedClaimAll = debounce(claimAll, 600); debounce를 걸어주면지정해놓은 시간이 끝나고 하나의 요청을 보낼 수 있었고, 문제를 해결할 ..

상위 컴포넌트에서 props로 배열을 받아 와 배열 요소를 뒤집어서 뿌려줘야하는 상황에서 크로스 브라우징 이슈가 발생했다. API에서 받아온 원본 배열의 무결성을 지키기 위해 하위 컴포넌트 내부에서 const copiedArr = [ ...apiArr, ].reverse(); 위와 같이 얕은 복사를 해주었다. chrome 환경에서는 reverse가 된 배열이 렌더되었지만, safari 환경에서는 reverse된 배열이 렌더되지 않았다. 디버깅 결과 copiedArr에 reverse된 데이터가 아닌 apiArr의 데이터가 있는 것을 확인하였고, 브라우저간의 렌더 과정에서 변수에 값을 할당하는 시점에 차이가 있을 것이라고 추측했다. dependancy를 걸어 apiArr의 값이 변할 경우 다시 얕은 복사를 ..

현재 협업을 진행하며, ClassName이 충돌하는 문제를 방지하기 위해서 그리고 컴포넌트 단위의 스타일링을 하기 위해 SCSS-Module 방식을 사용하고 있다. SCSS-Module을 사용하며, Swiper의 Pagenation Bullets에 Custom Stlye을 적용할 때, className을 찾지 못하는 Issue가 있었다. Module방식이 아닌, 일반적인 방식에서는 {_.map(products, (item) => ( ))} 위와 같이 슬라이드와 Pagenation Bullet을 만들어 준 뒤, Elemen탭에서 bullet을 선택했을 때 확인할 수 있는 .swiper .swiper-pagination { position: absolute; bottom: 65px } .swiper .swi..

소개 프로젝트를 시작할 때, 나는 Header, Nav, Section, 그리고 Footer로 기본 레이아웃을 구성했다. Nav는 항상 화면의 왼쪽 중앙에 고정되어야 했기 때문에, 화면을 Header, Section, 그리고 Footer로 나누어 설계했다. Header와 Footer의 높이는 고정되어 있었지만, Section은 나머지 영역의 100%를 차지해야 했다. 문제 레이아웃을 설정하고 Section의 높이를 100%로 지정했지만, 화면 높이를 꽉 채우지 못하는 문제가 발생했다. 이후 문제 해결을 위해 높이 값을 부모 요소인 html 및 body에 의존해야 한다는 점을 깨달았다. 원인 하지만 문제는 계속해서 발생했고, 개발자 도구를 사용하여 Elements 탭을 검사한 결과, html 및 body ..

Next/Image에서는 Lazy Loading, 이미지 사이즈 최적화, placeholder, 캐싱 등의 이미지 최적화 기능을 제공한다. lazy loading 기본적으로 다른 속성을 주지 않으면 lazy loading이 적용되어 뷰포트에 이미지가 들어왔을 때 이미지를 로드한다. 만약, loading prop에 ''eager' 값을 주면 뷰포트에 상관 없이 모든 이미지가 동시에 로드된다. 이미지 사이즈 최적화 디바이스 크기에 맞게 이미지의 사이즈가 조절되며, 용량이 작은 webp 포맷으로 변경되는 작업이 Next 서버에서 이루어지게 된다. placeholder CLS(Cumulative Layout Shift), 레이아웃이 흔들리는 현상을 방지하기 위해 placeholder 기능을 제공한다. 이미지가 ..