NextJS를 사용하면, 무조건 거치게 되는 기능이 있다. 바로 Image Optimization이다. 필자도 현록을 개발하면서 LCP 시점을 개선하기 위한 방법을 찾던 중 알게 됐는데, 파면 팔수록 Vercel은 정말 무서울 지경이다. 오늘연 여기서 placeholder prop에 blur를 부여하고 blurDataURL prop value를 직접 부여하는 경우를 다뤄보겠다.

올해 1분기 쯔음 회사에서 처음으로 배포한 Nuxt 프로젝트가 있었다. 서비스가 운영 단계로 들어서면서 소스 수정이 매우 잦아졌고, 배포 과정마다 사용자는 정상적으로 서비스를 사용하기 어려운 상황을 마주했다. 원인을 분석한 결과, build 과정 초기에 .nuxt 폴더에 있는 번들파일을 제거하기 때문에 사용자들이 번들파일을 내려받지 못하여 벌어진 현상이었다.

Vue의 메인 버전이 3가 된지 꽤 됐다. 주로 Nuxt 환경에서 작업해왔기 때문에, 그리고 아직 Vue 3를 채용한 Nuxt 3가 RC 단계이기 때문에 Product에 적용하기에는 어려움이 있었다. 그래서 궁금하고 심심하던 참에 간단한 Todo Applink icon을 만들어봤다.

이슈를 마주쳤을 때, 구글링을 하다보면, 가끔 npm ci를 사용하라는 솔루션을 만나고는 했다. 오늘은 npm ci에 대해 좀 더 알아보고자 한다. npm install과 다른점은? package-lock.json이 존재해야 한다. npm ci는 npm install과는 다르게 package-lock.json이 존재하는 환경에서만 실행 가능하다. lock파일과 package.json 파일이 다른 의존성을 가지면 안된다. 만약 package-lock.json파일이 package.json파일과 다른 의존성을 가지고 있다면,npm ci는 package-lock.json을 업데이트하는 대신 error와 함께 종료된다.

storybook을 사용해보려고 하다 마주한 이슈의 해결법을 알아보다가 등장한 .npmrc라는 파일에 대해 공부해보았다. .npmrc 파일이란? .npmrc 파일은 npm에 대한 config 파일이다. (npm에 대한 rc 파일) 주로 환경변수 등을 설정할 때 사용된다는데, 흡사 자주 사용하는 dot-env의 .env파일처럼 작동한다고 보면 되는 것 같다.

storybook은 UI Component들을 모아서 보여주고, 문서화 해주는 오픈소스 도구이다. 만약 조직에서 CDD(Component Driven Development)를 추구한다면, 스토리북이 필수일 것 같다. 또한 FrontEnd framework들과도 친화적이어서 개발된 component들을 테스트하고 싶다면 스토리북을 통하여 테스트까지 가능하다.

TTV는 Time to View이며, 사용자가 화면을 보는 시점을 의미한다. TTI는 Time to Interact이며, 사용자가 웹에서 특정 동작을 수행할 수 있는 시점을 의미한다.

현록을 개발하면서 티스토리에 있던 포스트들을 markdown으로 변환하여 올리고 있는데, 간혹 이미지 가로 사이즈가 viewport width보다 크면 overflow되는 현상이 있었습니다. 사실 css로 해결하였지만, styled-components 환경에서 nesting하는 것을 꺼리기도 하고, marked에서 직접 inline style을 넣는 방법이 궁금하기도 해서 찾아보았습니다.

오늘 회사 동료의 PR 리뷰 과정에서 좋은 기능을 공유해주셔서 TIL로 남겨봅니다. 아래와 같이 상수에 언더바(_)로 콤마처럼 구분을 시켜줄 수 있습니다. 앞으로 깔끔하고 좋은 코드를 작성하기 위해 자주 사용해야겠습니다 :)

오늘 next에서 `getStaticProps`와 `getLayout` 패턴을 함께 사용할 때, typescript generic을 넘겨주는 작업을 하고 있었는데, 기본값이 없다보니 기존 코드에 에러가 발생했었다. 이를 해결하기 위해 찾아보니 단순히 아래 예시처럼 `= {}`을 추가해주면 해결된다고 한다.

안녕하세요. 오늘은 Maria DB 초기 세팅 시, 외부에서 접속이 안될 때 매뉴얼을 작성해보겠습니다. dotenv 패키지를 통해서 환경변수로 관리한다면, 별도의 추가 작업을 할 일이 없으실 겁니다.

안녕하세요. 오늘은 제가 올해 초 진행했었던 유튜브 뮤직 클론코딩 프로젝트를 리팩토링하면서.  개선이 필요한 코드를 발견하여 수정한 경험을 공유해보고자 합니다. 해당 페이지에서는 nested router를 통해 재생목록, 앨범, 노래, 아티스트, 구독 탭을 보여주고 있습니다. url에 child route를 입력해주지 않은 경우 탭에서 아무것도 보여주지 않아 리다이렉트를 시켜주고자 했었던 것 같습니다. 여기서 문제는 ... mounted 훅에서 검사를 시켜주고 있었네요 ...

안녕하세요. 프론트엔드 개발자의 경우, 가끔 백엔드의 API Response 값이 snake_case일 경우 어떻게 관리할 지에 대해 고민에 빠지게 됩니다. 저도 오늘 같은 상황을 겪게 되었는데,  이번엔 네이밍 컨벤션을 맞춰주기로 했습니다. 컨벤션을 맞추는 데에는 여러가지 방법이 있겠지만, 고민 끝에 저는 axios의 interceptors를 통해 해결을 해보았습니다.

안녕하세요. 오늘은 CSS로 글래스모피즘 디자인을 구현하는 법을 알아보겠습니다. 개인적으로 애플의 디자인 스타일을 좋아해서 좋은 레퍼런스 소재로 구경을 하는데, 오늘 문득 궁금해진 것이 CSS로 어떻게 글래스모피즘을 구현했느냐였습니다.

안녕하세요. 오늘은 Nuxt의 Fetch API와 라이프사이클의 Created 훅에서 API를 호출 했을 때 각각의 차이점에 대해 알아보겠습니다. SSR 기준으로, Nuxt 2.12 버전 이후 Fetch API는 Vue instance가 create 된 후에 실행 됩니다. 그러면 created 훅에서 실행하는 편이 더 빠른 API Response를 가져오지 않을까 궁금해졌는데요. 이를 따로 비교한 글을 찾지 못해 제가 직접 한번 테스트를 해보았습니다.

안녕하세요. 오늘은 node 환경의 개발자라면 한번쯤 궁금했을만한 package-lock.json의 역할에 대해 알아보겠습니다. 우리는 node 환경에서 개발을 할 때 다양한 패키지들을 설치하여 활용하곤 합니다. 우리가 설치하는 패키지 또한 다른 npm 패키지를 활용하여 만든 패키지들이고 이들 또한 설치를 하게 됩니다. 이렇게 직간접적으로 설치된 패키지들은 대부분 호환성을 "^1.1.5"와 같이 표현하여, 범위로 지정해두고 있습니다.

안녕하세요. 요즘 포트폴리오를 만들면서 서버 상에 자주 반영할 일이 생겼는데, 매번 명령어들을 타이핑하는 것이 비효율적이라 생각이 들어 배포 자동화를 생각해보게 되었습니다. 현재 레벨에서는 단순히 명령어들만 단축시켜도 효율적이라 생각이 들어 간단한 쉘 스크립트만 작성하였습니다. 정말 간단하니 여러분도 도전해보시길 바랍니다.

안녕하세요. 오늘은 Prettier이라는 도구에 대해 알려드리고자 합니다. 개발자는 각자의 코딩스타일이 존재합니다. 그러다보니 같은 프로젝트에서도 작성하는 소스마다 스타일이 제각기 다르기 일쑤입니다. 그럴 때 도입하면 좋은 것이 Prettier입니다. 프로젝트 root 폴더에 .prettierrc 라는 파일을 생성한 뒤, 위 예시와 같이 원하는 옵션을 JSON 형식으로 작성해주면 됩니다.

오늘은 Promise를 통해 구문을 동기 처리 할 때, 여러 Promise들을 다루는 법을 소개해보겠습니다. Javscript를 작성하다 보면, 가끔 여러 Promise들을 다룰 때가 있습니다. 필자도 Nodejs 서버에서 동시에 여러 쿼리를 실행할 때 자주 마주쳤었는데요. 오늘은 어떻게 하면 Promise들을 유연하게 다룰 수 있는지 알아보겠습니다. 시작하기 앞서, 네 가지 Promise를 선언하고, 그들을 하나의 Array에 묶어보겠습니다.

오늘은 Next JS에서 import 시 복잡한 relative path 대신 absolute path 사용을 위한 설정법을 알아봅시다. file path를 상대경로로 지정하다보면 유지보수면에서도 복잡하고, path를 지정할 때마다 경로가 헷갈려서 발생하는 오류는 덤입니다. 이럴 때 path에 대한 alias를 설정하면 코드는 확 깔끔해질 것입니다.  아래 예제를 통해서 따라해봅시다.

홈페이지를 구성할 때, 우리는 대체로 네비게이션과 푸터, 플로팅 버튼 등을 포함합니다. 개발단계에서 이들 컴포넌트를 페이지마다 일일이 import하는 것은 매우 비효율적인 일입니다. 만약 이들처럼 대부분의 페이지에서 보여줘야될 내용이 있다면, 레이아웃 컴포넌트를 통해 손쉽게 유지보수할 수 있을 것입니다.

서비스를 배포하실 때 환경별로 포트번호 등이 달라서 소스코드를 직접 수정하셨던 경험이 있으신가요 ? 포트번호와 같이 환경별로 다른 값이나 DB 접속 정보 등 소스코드에 포함되면 안될 중요한 값을 dotenv 패키지를 통해서 환경변수로 관리한다면, 별도의 추가 작업을 할 일이 없으실 겁니다.