230929(금) 성장

🚤 성장일지 7.0

책 행복한 이기주의자(웨인 다이어)의 내용에 자극받아 시작하는 소박한 성장기록

살아있는 꽃과 죽은 꽃은 어떻게 구별하는가?
성장하고 있는 것이 살아 있는 것이다.
생명의 유일한 증거는 성장이다!

⚛ (7.0)<완전 개편> 파인만 학습법을 알게 된만큼, 성장일지는 정말 그 날의 키워드 중심으로 간단하게 정리하도록 한다.

⚛️ 키워드: 직관적이고 쉽고 간단하게 작성

Next.js

Serverless

서버리스는 서버가 없다기보다는 개발자가 따로 서버를 구축하고 관리할 필요가 없다는 정도의 의미이다. Next.js에서는 api 폴더만 만들어서 그 안에 정해진 함수를 작성하면 서버리스로 api를 만들 수 있다. 이렇게 만든 api는 https://domain/api/와 같은 형태로 접근할 수 있다. Next.js의 정확한 서버 구축 방식이 어떻게 되는지는 모르겠지만 vercel과 aws의 파트너십을 보면 aws의 람다를 통해서 서버리스를 구현하는 것 같다.

Loading UI

Next는 리액트의 Suspense Boundary를 사용하여 로딩 UI를 편하게 구현할 수 있게 해준다. 로딩을 주고 싶은 라우트에서 loading.tsx를 만들면 된다. 이 때, 우리가 개발하는 개발 환경(dev mode)에서는 언제나 SSR이므로 전부 다 로딩이 적용된다.(요청마다 렌더링되니까) 그러나 실제 배포 환경(prod mode)에서 SSG로 렌더링하는 컴포넌트같은 경우, 이미 서버에서 html을 만들어서 보내기 때문에 로딩이 적용되지 않는다. 이를 인지하도록 하자!

Error UI

Next는 Loading과 비슷하게 리액트의 Error Boundary를 사용하여 에러 UI를 편하게 구현할 수 있게 해준다. 에러를 주고 싶은 라우트에서 error.tsx를 만들면 된다. 이 때, 중요한 점은 Error 컴포넌트는 언제나 클라이언트 컴포넌트로 구현해야된다는 점이다! 왜 그럴까? 구글링해봐도 명확한 이유는 나오지 않지만, 생각해보면 브라우저 즉, 클라이언트 단에서 어떤 로직이 처리되다가 에러가 발생해야지 에러 페이지라는 게 존재하기 때문일 것이다. 애초에 서버 컴포넌트에서 발생하는 에러라면 빌드 자체가 안되어야하는 게 맞을테니까. 그리고 보통 에러가 발생한 이후 해당 에러에 대한 로그를 남기는 등의 작업을 처리해야하는데, 이를 위해서는 useEffect를 통해 처리하기 때문에 클라이언트 컴포넌트가 될 수밖에 없는 게 아닐까 싶다. 또 하나 주의할 점은 해당 라우트에서 layout의 children이 아닌 그 바깥 부분에서 발생하는 에러는 현재 라우트의 error 컴포넌트가 잡아낼 수 없다는 점이다. 해당 라우트에서의 Error Boundary는 children을 wrapping하기 때문이다. 즉, 그 바깥에 대한 에러는 상위 컴포넌트의 Error Boundary가 잡아낼 수 있다.

Image 컴포넌트

와… Next.js의 여러 api 중 Image 컴포넌트가 가장 신기했다. 어떻게 Image 컴포넌트 하나만으로 이미지 리소스에 대한 최적화를 이렇게까지 이뤄냈지… 일단 기본적으로 여기를 참고하면 좋을 것 같다. 일반적으로 이미지는 웹 페이지에서 큰 비중을 차지하고 특히나 LCP(Largest Contentful Paint) 성능에 상당한 영향을 준다고 한다. 그만큼 이미지 최적화를 잘하면 전체 렌더링 시간을 많이 줄일 수 있다는 것이다. Next는 이미지에 대해 크기 최적화, 외관 안정성(layout shift가 안일어난다. => 이미지가 렌더링되지 않아도 미리 사이즈를 잡아둬서 리플로우가 일어나지 않게 한다.), 빠른 페이지 로드(유저가 특정 이미지를 뷰포트에 보이게 되었을 때, lazy loading으로 불러온다) 등을 제공한다.(진짜 감동임…🥹)

📝 회고

Next에 대한 개념을 배우면 배울수록 라이브러리가 아닌 프레임워크의 힘을 느낀다. 솔직히 처음에는 내가 아는 리액트와는 다르게 너무 굳어있는 느낌..? 정해진 규칙대로 딱딱 체스말을 놔야하는 체스 게임같았다. 뭔가 견고하고 튼튼하고 체계적이긴 한데, 조금은 억압되는 느낌. 그런데 배우면 배울수록 왜 리액트 공식문서에서도 가급적 리액트를 사용할 때 Next를 권장하는지 알 것 같다. 아직 많은 것들이 바뀌는 중이기도 하지만, 정말 정말 체계적으로 최적화도 잘 되어있고 좋은 개발자 경험을 제공해주는 거 같다. 또, 솔직히 리액트는 다른 사람이 짠 코드를 보면 폴더 구조부터 사용하는 라이브러리까지 너무 천차만별이라 코드를 이해하는 데 힘들기도 하고 협업도 좀 힘든 느낌이었는데, Next는 그런 부분들이 훨씬 쉬워지지 않을까 싶다. 얼른 Next로도 프로젝트를 시작해보고 싶다!!!!!! (두근두근하다잉)

참고

• Next.js 공식문서