sharingStorage

useEffect에 대해 깊게 알아보고 useEffect는 무엇이며 어떻게 활용해야하는지에 대해 아티클을 작성해보겠습니다.useEffect를 들여다보기 전에 state와 rendering, rerendering에 대한 배경지식과 이해가 있으면 Deep dive가 조금 더 수월합니다. React component에는 두가지 유형의 로직이 있다.렌더링 코드 (UI와 인터랙션을 구성)순수해야하며 순수하다는것은 같은 입력에 대해 항상 같은 결과를 내는 것을 말합니다. === pure functionevent handlerinput field 변경 (event)HTTP 요청navigate를 통한 스크린 변경2번 event handler는 side effect를 포함합니다. What is useEffect?eff..

오늘은 Turborepo의 컴파일 전략인 Just-in-Time packages 를 알아보고 그 과정에서 만났던 문제 해결 과정을 공유해보도록 하겠습니다.저는 Turborepo를 활용한 모노레포 내부에 apps/web으로 웹서비스를 관리하고 packages 폴더 내부에 디자인 시스템과 공통으로 사용하는 각종 config 파일을 모아두는 구조를 선택했습니다.디자인시스템은 tailwind와 shadcn으로 구성했으며 Internal Package방식을 사용해 모노레포에서 쉽고 빠른 코드 공유를 가능하게 했고 Turborepo의 Just-In-Time package 방식을 사용해 배포했습니다. Just-in-Time Packages란?Just-in-Time(JIT)이라는 용어는 Turborepo 뿐만 아니라 ..

서론npm installnpm error code ERESOLVEnpm error ERESOLVE unable to resolve dependency treenpm errornpm error While resolving: falling-game@0.1.0npm error Found: react@19.0.0-rc-02c0e824-20241028npm error node_modules/reactnpm error react@"19.0.0-rc-02c0e824-20241028" from the root projectnpm errornpm error Could not resolve dependency:npm error peer react@"^16.8.0 || ^17.0.0 || ^18.0.0" from @re..

타입스크립트는 타입을 정의하는 다양한 같은 방식을 제공합니다.예를 들면 index signature를 위해 아래 두가지의 같은 동작의 다른 코드를 사용해볼 수 있습니다. (물론 index signature는 문자열 리터럴이 안돼서 맵드 타입을 쓴다던가 하는 아주 사소한 차이는 있습니다. )type Data1 = Recordtype Data2 = { [key in string]: unknown }대부분은 더 읽기 쉽고 쓰기 쉬운(?) Record를 선호할 것 같지만이런 것들이 타입을 더 견고하게 사용할 수 있게 돕기도 하고 유연하게 사용하기 위한 방법을 제시한다고 생각합니다. Optional (?) vs 명시적 undefined우리가 매우 자주 사용하는 PropsType에서는 어떨까요? 아래 두 코드는 어..

쿠키를 사용한 상태관리HTTP는 stateless 프로토콜이기 때문에 과거에 교환했던 리퀘스트와 리스폰스의 상태를 관리하지 않습니다.이는 과거 상태를 근거로 한 현재 리퀘스트 처리는 어렵다는 것을 뜻합니다. 쿠키이러한 stateless한 특성으로 인해 발생하는 문제를 해결하기 위해 도입된 시스템이 쿠키입니다.리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트 상태를 파악하기 위한 시스템이며서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 쿠키를 클라이언트(브라우저)에 보존하고 다음 리퀘스트 요청에 자동으로 쿠키 값을 넣어서 송신합니다.이로 인해 서버는 클라언트가 보낸 쿠키를 확인하여 어느 클라이언트가 접속했는지나 서버상의 기록을 확인할 수 있습니다. 쿠키의 매커니즘쿠키라는 데이터는 =..

모노레포란? (모노레포, 멀티레포)모놀리식 어플리케이션모노레포를 설명하기 전에 모놀리식 어플리케이션과 멀티레포에 대한 개념을 알아야합니다.모노레포가 등장한 이유는 모놀리식 애플리케이션의 한계에 대한 비판에서 출발합니다.우리가 일반적으로 사용하는 모놀리식 방식은 소스코드를 모듈화하지 않고 하나의 레포지터리에 모두 넣은 구조이며 모든 코드가 단일 버전으로 직접 의존하기 때문에 코드 재사용이 용이하고 빌드 및 배포 과정도 단순하지만, 관심 분리가 어렵고 기능 추가나 삭제가 전체에 영향을 주어 모든 작업이 거대한 단위로 처리된다는 단점이 있습니다.멀티레포이러한 문제를 해결하기위해 모듈화가 제안되었고 재사용하기 위한 프로그램을 모듈화하여 독자적인 저장소에 위치시키고 여러 레포지터리를 관리하는 것을 멀티레포 구조라..

서론최근 성능에 대한 관심을 보이면서 몇몇 글모임의 상세페이지에서만 유독 좋지 않은 LCP지표를 보이고 있는 것을 확인하였습니다. 이것에 대한 원인을 유추하던 중 presigned url을 활용하여 서비스를 운영하며 10MB에 육박하는 대용량 이미지가 아무런 전처리나 최적화 작업 없이 S3에 업로드되었고 이것이 곧 LCP의 Load Time과 전체 Network 요청 리소스에 큰 영향을 주고있는 것을 확인하였습니다. 이러한 문제를 NEXT JS에서는 모든 이미지를 WebP로 변환하는 과정을 통해 이미지 최적화를 진행한다는 것에서 착안하여 업로드 과정에서 이미지 최적화를 진행하여 개선해보려고 합니다.  위에서 말씀드린 성능에 대해 조금 더 자세히 확인해보자면 아래와 같이 유독 LCP점수만 낮게 측정된 것을..

이 글은 한 초보 개발자의 간단한 질문에서 부터 시작되었다.  헤더헤더 123123123 위 코드는 header의 fixed를 통해 상단에 고정시키고 main에 컨텐츠를 담기 위해 간단한 작업을 할 때 사용하는 코드인데 위 코드를 실행하면 우리가 의도한 바대로 작동하지 않는다. 위 코드를 실행해본 결과이다 body의 위치를 이해하기 쉽도록 green을 주었다. 분명 main에 margin-top을 주었는데 왜 형제 요소인 fixed 헤더까지 내려올까?? 문제점 1 fixed에 offset값을 넣지 않았다.너무나 당연한 답입니다.fixed는 뷰포트 기준으로 top, left, rigth, bottom에 의해 결정되는데 이를 적용하지 않았을 때 초기위치에 absolute값과 동일하게 적용..

들어가며이전 시간엔 web성능에서 중요한 지표인 core web vitals와 성능을 확인할 수 있는 도구인 Lighthouse를 알아보았으니 이를 통해 현재 서비스중인 mile의 성능을 확인하고 개선해보려고 합니다.가장 먼저 Lighthouse로 현재 mile의 성능을 측정해본 결과 main페이지부터 아래와 같은 엄청나게 성능이 좋지 않다는 것을 확인했고 vite-bundle-visualizer 와 같은 도구로 번들사이즈를 확인하며 데모데이를 향해 달려가면서 놓친 부분과 크고 작은 실수들을 바로 잡으면서 성능을 개선해보겠습니다.성능 확인과 번들사이즈 확인아래와 같이 Lighthouse로 엄청나게 좋지 않은 메인페이지의 성능을 확인하였고 이와 관련해서 vite-bundle-visualizer를 사용하여 ..

이번엔 웹서비스의 성능지표 core web vitals를 공부해보고 lighthouse의 성능지표에는 무엇이 있는지 알아보겠습니다.웹 성능 개선을 고려해야하는 이유웹 성능은 객관적인 측정치(로딩 시간, 초당 프레임 수, 상호작용에 반응할 수 있게 되는 시간)와 유저의 주관적인 경험(콘텐츠의 로딩 시간이 얼마나 길게 느껴지는지)이 포함됩니다. 우리는 웹 성능 개선을 왜 고려해야할까요?웹성능 지표는 비지니스에도 많은 영향을 주기 때문입니다. 일반적으로 빠른 로딩은 좋은 사용자경험(UX)을 제공하고 반대로 사용자가 웹사이트에 들어갔을 때 하얀 화면을 노출시키거나 로딩이나 지연이 길게 발생하면 사용자는 자연스럽게 이탈하게 됩니다.아래는 2017년 Google 모바일 부문 글로벌 제품 리드인 Daniel An이 ..