☄️ layout에 있는 Header와 Footer를 적용시키지 않을 페이지 분리 방법
1. 문제점
헤더와 푸터가 필요하지 않은 페이지에도 공통으로 적용되는 문제
2. 원인 추론
(모바일페이지) 공통레이아웃에 헤더와 푸터가 공통으로 주어진 상태이기 때문
3. 해결 방안
조건부렌더링 방법으로, 헤더와 푸터를 숨기는 hideHeaderFooter라는 변수를 만들어 '/loginInfo'로 시작하는 페이지는 헤더와 푸더를 숨기는 것으로 했다.
Next.js의 usePathname 훅(Hook)을 사용하면 현재 페이지 경로에 따라 특정 UI 요소를 렌더링할 수 있기 때문이다.
4. 결과
const pathname = usePathname();
// 디버깅을 위해 pathname 값 확인
// console.log("Current pathname:", pathname);
// pathname이 null이 아니면 특정 경로에서 헤더와 푸터 숨기기
// const hideHeaderFooter = pathname !== null && ["/loginInfo/*"].includes(pathname);
const hideHeaderFooter = pathname !== null && pathname.startsWith("/loginInfo");
return (
<div>
<div className="w-full min-w-[320px] max-w-[600px] mx-auto my-0 min-h-full">
{!hideHeaderFooter && <Header />}
{children}
{!hideHeaderFooter && <Navibar />}
</div>
</div>
);☄️ 팀 프로젝트 내 헤더/푸터 관리방법
팀 프로젝트 페이지들 내에서
헤더의 종류는 3개(홈페이지/뒤로가기 버튼이 있는 헤더/제목만 있는 헤더),
푸터는 하단 탭이 있는 페이지와 없는 페이지로 2개로 나뉜다.
분명 공통레이아웃의 장점이 있을텐데 어떻게 관리하는게 가장 좋은 방법일지 의논하는 시간을 가졌다.
📌 공통 레이아웃의 장점
1. 일관성 유지
: 모든 페이지에 동일한 헤더와 푸터를 사용하면, 사용자는 어디에서든 익숙한 UI를 볼 수 있어 웹사이트의 사용자 경험이 일관성 있게 유지된다.
2. 유지 보수 용이성
: 공통 레이아웃을 설정해두면 헤더나 푸터에 변경사항이 생겼을 때 한 곳에서만 수정하면 되기 때문에 유지 보수가 훨씬 간편하다.
3. 코드 중복 최소화
: 레이아웃에 공통 요소를 포함하면 각 페이지마다 헤더와 푸터 코드를 반복해서 작성할 필요가 없다. 컴포넌트 재사용성도 높아져 코드가 더 깔끔해진다.
4. 페이지 로딩 속도 최적화
: 일부 프레임워크에서는 레이아웃을 캐싱하거나 효율적으로 관리하여 성능을 개선할 수 있다. Next.js 같은 경우 공통 레이아웃을 설정하면 페이지 이동 시 공통 요소는 그대로 유지되어 페이지 전환 속도가 빨라진다.
1. 문제점
위에 '/loginInfo' 로 시작하는(startsWith) 페이지별로 분리해서 조건부 렌더링을 하기에는 너무 헤더와 푸터의 조건이 너무 많아 복잡하다고 느꼈다.
2. 원인추론
공통레이아웃 만의 장점이 있다고 생각했고, 조건부 렌더링도 한계가 있다고 느꼈기 때문이다.
3. 해결방안
헤더와 푸터의 해결방안을 다르게 했다.
헤더는 컴포넌트를 분리하여 각 페이지에서 직접 임포트했으며,
푸터는 공통레이아웃에 넣고 조건부 렌더링 방법을 선택했다.
4. 결과
1) 헤더 : 컴포넌트 분리
헤더는 종류가 3가지로 컴포넌트를 분리했다.
Header(홈페이지: 로고+알림+출석) / WithIconHeader(뒤로가기 버튼+페이지이름) / 제목만 있는 페이지는 컴포넌트를 따로 만들지 않았다.
2) 푸터 : 조건부 렌더링(공통 레이아웃)
export default function MobileLayout({
children
}: Readonly<{
children: React.ReactNode;
}>) {
const pathname = usePathname();
const showNavbar =
pathname === "/" ||
pathname === "/challenge" ||
pathname === "/myPage" ||
pathname === "/chat" ||
pathname === "/lesson" ||
pathname === "/myPage/editProfile";
return (
<div>
<div className="w-[375px] flex flex-col mx-auto my-0 min-h-full">
<div className={`${!pathname?.startsWith("/lesson") && "px-4"}`}>
<main>{children}</main>
</div>
{showNavbar && <NavbarGnb />}
</div>
</div>
);
}☄️ CSS 이미지경로 결정
기존에 Next.js에서 사용하는 이미지는 <Image> 태그를 사용하고 그 이미지 파일은 'public>images 폴더'에 넣어 보관했었는데,
팀원 한 분이 이미지를 'src>assets 폴더'에 넣으신 것을 코드리뷰하면서 알게되어 왜 여기에 넣으신 건지 여쭤보았고, 다른 팀원들과도 통일해야할 필요를 느꼈다.
파비콘과 같은 이미지는 기존과 같이 'public>images 폴더'에 넣기로 했으며,
개발 중에 사용하는 이미지는 'src>assets 폴더'에 넣기로 결정했다.
이렇게 분리하는게 일반적이고 합리적인 방법이라고 한다.
두 가지 폴더의 장점 및 특징은 아래와 같다.
📌 public/images 폴더
1) 고정된 이미지 파일
파비콘, 로고, SEO 관련 이미지 등 프로젝트 내에서 URL 경로를 통해 접근해야 하거나 직접적으로 링크할 필요가 있는 파일을 넣는 것이 좋다.
2) 정적 자산
public 폴더에 있는 파일들은 Next.js의 루트 경로(/)와 직접 연결된다. 예를 들어, public/images/favicon.ico에 있는 파일은
<Image src="/images/favicon.ico" />처럼 바로 접근할 수 있다.3) 장점
public 폴더의 자산은 빌드 시 별도의 변환 없이 그대로 제공되기 때문에 성능 최적화에 유리하다.
📌 src/assets 폴더
1) 개발 중 또는 동적으로 사용할 이미지
배너, 버튼 아이콘, 배경 이미지 등 개발 단계에서 주로 임포트(import)로 불러와 사용하는 이미지를 두는 것이 좋다.
2) 장점
이 방식은 코드에서 import를 통해 사용하는 이미지와 함께 빌드에 포함된다.
사용하지 않는 이미지는 빌드에 포함되지 않기 때문에, 최종 번들 크기를 줄일 수 있는 장점이 있다.3) 유연성
src/assets 폴더는 프로젝트가 커질수록 컴포넌트별 또는 기능별로 이미지 파일을 나눠 관리할 수 있어, 팀 프로젝트에서 폴더 구조를 일관성 있게 유지하기 쉽다.
이렇게 폴더를 구분해 관리하면,
- 프로젝트 구조가 명확해지고 파일 접근 경로도 일관성을 유지할 수 있다.
- 팀원 간 역할 분담이 용이해지고, 파일 경로가 직관적이어서 유지 보수 시에도 효율적이기에
=> 이미지 폴더를 나누는 결정은 좋은 선택이며, 프로젝트 확장성과 유지 보수성 측면에서도 유리하다고 한다.
