Github 블로그 작업기 2일차

블로그 작업 중 몇 가지 이슈를 발견하였고 이를 해결 했던 방법에 대해 정리해보았습니다.

이슈1 : 설계 미스

List Layout에서 Post Page(or Layout)에 전달되는 params 정보를 알 수 없다는 점을 작업 도중 깨닫게 되었습니다.

따라서, 기존에 고려했던 List Layout에서 Keyword, List 컴포넌트 재활용은 어렵게 되었습니다.

이슈1 해결

코드 중복을 고려하여 List Layout에 있는 컴포넌트를 재활용할 생각이였으나 해당 방법이 불가능하다는 판단하에 해당 부분을 별도 컴포넌트로 분리했습니다.

분리된 컴포넌트를 Post Layout, List Page에서 각각 호출하여 props에 따라 분기처리하는 방법을 채택했습니다.

이슈2 : Client Side Rendering

이슈1이 해결되면서 Post Layout의 keyword와 달리 List Page의 keyword는 선택 이벤트가 필요했습니다.

keyword를 담당하는 컴포넌트에서 "use client" 처리를 하면 마무리될 이슈로 판단했습니다.

하지만 Post Layout에서는 post마다 고정된 값을 가지고 있을 예정으로 서비사이드 랜더링이 가능한 상황에서 코드 중복 최소화를 위해 불필요한 클라이언트사이드 랜더링을 가제할 필요는 없다는 판단이 들었습니다.

이슈2 해결

client용 wrapper 컴포넌트를 만들어 해결했습니다.

정적페이지에서도 배포가 가능하도록 props에 따라 화면만 구성하는 컴포넌트를 만들고 Post에서는 해당 컴포넌트를, List에서는 Wrapper 컴포넌트를 바라보도록 했습니다.

이슈3 : Image Optimization

정적 배포일 경우 Image 최적화를 위한 별도 API를 사용하거나 unoptimized 옵션을 사용해야한다는 문구가 발생했습니다.

- error Error: Image Optimization using the default loader is not compatible with `{ output: 'export' }`.
  Possible solutions:
    - Remove `{ output: 'export' }` and run "next start" to run server mode including the Image Optimization API.
    - Configure `{ images: { unoptimized: true } }` in `next.config.js` to disable the Image Optimization API.
  Read more: https://nextjs.org/docs/messages/export-image-api

이슈3 해결

Github Pages를 사용할 예정이므로 별도 API를 사용할 예정이 아니라 unoptimized 옵션을 활성화 했습니다.

이슈4 : 타입 에러

app 폴더 내에 있는 interface에 import하여 상속받는 경우 빌드시 아래 처럼 에러가 발생했습니다.

> next build

- info Creating an optimized production build  
- info Compiled successfully
- info Linting and checking validity of types .Failed to compile.

app/posts/[post]/page.tsx
Type error: Page "app/posts/[post]/page.tsx" has an invalid "default" export:
  Type "PostPageProps" is not valid.

이슈4 해결

재현이 불가한 상태로, 추후 다시 발생 가능성이 있으므로 히스토리만 남겼습니다.