나의 코딩일지

카카오맵 api를 구현하는데, 타입스크립트로 작성하다보니 window객체에 kakao가 없어서 자꾸 에러가 생겨서 따로 window 객체에 추가해줘야했다. 그러다가 window 객체에 대해 궁금해졌다. 콘솔에 찍어보면 알 수 없는 속성들만 몇백개라 스크롤 내리기도 버겁다. Widow 객체 브라우저의 요소들과 자바스크립트 엔진, 그리고 모든 변수를 담고 있는 객체 브라우저 전체를 담당하는 건 Window 객체이고, 웹사이트만 담당하는 건 Document 객체 window 객체는 모든 객체가 포함된 최상위 객체이며, 전역변수와 전역스코프에서 선언된 함수는 window 객체의 property이고, 식별자 window를 통해 접근가능하며 호출 시 생략할 수 있음 DOM: 웹페이지의 문서를 제어하기 위한 객체모델..

아무도 보여주고 싶지 않은 첫 프로젝트에서 styled-components를 사용했다가, CSS-in-JS는 현업에서 선호하지 않는다는 말을 듣고, DM으로 물어봤다가 장문의 답장을 받은 이후 강박적으로 styled-components는 사용하지 않았다. 그러다가 chakra UI 같은 UI 컴포넌트 라이브러리를 사용하면 편하다는 말을 듣고 프로젝트에 도입해 사용하고 있었다. 하지만 사용하면 할수록 styled-components보다 느리겠다는 생각을 하게 되었다. 그리고 생각해보면 이것도 CSS-in-JS 아닌가 싶었다. 그리고 해커톤에서 다른 레포를 살펴보면 거의 styled-components를 사용하고 계셨다. 울면서 styled-components 떠나보냈는데 다시 품 안으로 데려와야하나싶다. ..

API 응답으로 쿠키가 오기는 하는데, 그 쿠키를 읽을 수도 없고 브라우저에 자동으로 저장되지도 않았다. 프리지링크 때도 refresh token을 헤더로 받아왔지만 클라이언트에서 접근 불가능했던 이슈가 있었는데, 같은 맥락으로 발생한 듯 했다. 결국 도메인이 달라서 그렇다고 판단을 하고 서브 도메인을 추가하고 vercel에 도메인을 등록하여 해결할 수 있었다. 멀고 어려운 도메인의 세계다. CS가 없어서 인프라를 건들지도 못하겠고 봐도 전혀 모르겠다. 역시 프로젝트는 그만하고 CS 공부해야하는거겠지..도메인인터넷 상에서 고유한 식별자를 가지는 웹사이트나 네트워크의 주소일반적으로 도메인은 웹사이트의 주소로 사용되며, 인터넷 사용자들이 해당 웹사이트에 엑세스할 때 사용됨도메인은 DNS(Domain Name..

왜 임시저장으로 목차만 만들어놓고 안쓴건지.. 그치만 원래 한달 지난 시점에서 하는 회고가 젤 재밌다엘리스에서 나와서 백엔드와 나 단둘이 호기롭게 시작했던 프로젝트를 흐지부지 끝내면서 마감기한이 있는 곳에서 프로젝트를 진행해야한다는 사실을 깨달았다. 그리고 둘 다 기술 구현하고 싶어서 기획은 빨리 빨리 끝내놓고 개발에 들어갔기 때문에, 프로젝트를 어떻게 마무리해야할지 답이 없어서 중단하게 되었다. 그냥 둘이서 으쌰으쌰 결제 시스템 만져본걸로 만족했지만, 제대로 된 팀에서 프로젝트를 진행하고 싶어 연합동아리에 신청하게 되었다. 1년 사이에 개발변태가 된 나를 좋게 봐주셔서 운좋게 합격할 수 있었고, 마라팀에 들어가 냉장고 관리 애플리케이션을 제작하게 되었다.CI/CD 세팅 해두기로컬에서 거의 완성된 상태에..

누적 레이아웃 이동(Cumulative Layout Shift, CLS) 웹 페이지의 시각적 안정성을 측정하는 지표 중 하나로 페이지의 생명주기 동안 발생하는 모든 예기치 않은 이동에 대한 지표를 계산하며 사용자가 예상치 못한 레이아웃 이동을 경험하는 빈도를 수량화한다. 사용자가 페이지를 로드하는 동안 렌더링되는 요소들의 위치 변화로 인해 발생하는 사용자 경험의 불안정성을 나타내므로 CLS가 낮으면 사용자 경험을 악화시킨다. 리소스가 비동기식으로 로드되거나, DOM 요소가 기존 콘텐츠 위의 페이지에 동적으로 추가 되어 발생한다. 사용자의 인터렉션으로 인한 레이아웃 변경인 경우는 포함되지 않으며, 레이아웃 이동이 발생한 요소의 전체 높이와 뷰포트 높이의 비율을 의미하는 영향분율과 레이아웃 이동이 발생한 요..

사실 이 프로젝트는 프론트엔드 개발자에게 기술적 챌린지가 있던 것도 아니었고, 오히려 대시보드라서 비슷하지만 애매하게 api를 재사용하는 컴포넌트만와 다른 페이지 수만 많아 시간 싸움이었기 때문에 해커톤에는 악조건이었다. 2차 합류하느라 기획이 거의 끝난 상태여서 개발 사이즈를 줄이지도 못했다. 그럼에도 이 프로젝트를 선택한건 일단 아이템이 왜 필요한지와 해결방안이 명확해 매력있었고, 첫 대화했을 때 디자이너분이 예사롭지 않은 분이었기 때문이다. 매력적인 디자이너의 존재는 프론트엔드를 움직이게 한다. 그리고 예전에 테오의 스프린트에서 프론트엔드 개발자들이 서로 프레임워크와 라이브러리, 컨벤션을 맞출 때 편리하게 도움을 주는 프로덕트를 진행했을 때 디벨롭되면 진짜 사용하고 싶었던 맥락도 있었다. 무엇보다,..

npm과 yarn의 차이를 명확히 몰라서 yarn을 쓰기로 해놓고 npm을 사용하는 듯의 빌런짓을 했다. 그러다가 lock 파일에서 에러가 나서 커밋을 되돌리는 고생을 겪었고 이후 package manager에 대해서 알아보게 되었다. Package Manager 개발에 필요한 다양한 패키지를 설치하고 또 수정하고 업데이트 하는 등의 작업을 편리하게 도와주는 도구 프로젝트에 필요한 다양한 패키지들을 의존성 있게 관리해주는 도구 npm 프로젝트의 의존성을 수동으로 다운로드해야 했던 불편함을 개선한 패키지 매니저 node.js에 내장되어 있기 때문에 추가적인 설치가 필요하지 않음 다른 사용자들이 만들어 놓은 다양한 모듈을 다운로드 가능 npm | Home (npmjs.com) npm | Home Bring ..

Next.js는 파일 시스템을 기반으로 라우팅을 구현하며, 그 방법에는 app router와 page router가 존재한다. 기존 Next.js는 /page 폴더에 모든 웹 사이트의 페이지 컴포넌트를 처리했다. 파일 구조만으로 라우팅을 손쉽게 할 수 있기 때문에 편리한 개발이 가능했다. 그리고 Next.js 13부터 App router가 등장했다. App router는 상태를 유지하고 Rerendering을 방지하면서 자체 경로 안의 컴포넌트와 UI를 쉽게 공유할 수 있다. App router react server components를 기반으로 구축되어 있으며, 서버 데이터 가져오기에 맞춰져 있다. 전체 애플리케이션에 대한 전반적인 라우팅 및 탐색을 처리한다. URL을 기반으로 올바른 페이지를 렌더링..

TanStack Query makes fetching, caching, synchronizing and updating server state. new QueryClient로 인스턴스를 생성하고 QueryClientProvider를 통해 전역에서 생성한 QueryClient에 접근 가능하도록 만든다. QueryClient 내에는 QueryCache와 MutationCache가 있다. useQuery를 호출하여 QueryClient, 렌더링 트리거 여부를 파악하기 위한 현재 결과값 등이 담 Observer를 생성하고, 이 Observer를 통해 Query가 생성되어 cache에 저장되며 Query와 컴포넌트가 연결된다. import axiosInstance from '@/api/axiosInstance';..

tanstack-query의 useInfinityQuery를 통해 무한 스크롤을 구현하였는데, 데이터를 추가/ 삭제/ 수정해도 이전에 받아온 데이터가 유지되는 현상이 발생했다. 처음에는 당연히 queryClient.invalidateQueries를 통해서 간단히 해결될 문제라고 생각했는데, 안된다. useInfinityQuery의 refetch를 사용하면 될 줄 알았는데, 안된다. 콘솔을 찍어보니 냉장고 id가 undefined로 들어가고 있었다. URL params에서 useState로 변경하던 중에 이런 에러가 발생했던 것 같다. 하지만 냉장고 id를 제대로 보내줘도 결과는 똑같았다. 왜 안되는건지 이해가 안되는 중에, 일단 마감기간은 다가오니 캐시데이터를 삭제하는 방법을 사용하기로 했다. 하지만 q..