[FEAT-8] 헤더 세부 기능 구현

[qwer0114]

📝 PR 내용

헤더 컴포넌트의 세부 적인 기능들을 구현했습니다.

✅ 작업 내용

• 사용자가 선택한 질문 전형에 따라 Chip 컴포넌트를 보여주는 기능
• 헤더 햄버거 버튼 클릭 시 바텀 시트 메뉴 오픈 기능
• 새로고침 버튼

📸 스크린 샷 / 영상 (선택)

참고

• 사용자가 아무것도 선택한 상태가 아니라면 기본적으로 수시를 먼저 보여줍니다
• html a 태그의 tel 속성을 이용하여 모바일에서 전화번호 클릭 시 바로 전화 연결로 넘어갈 수 있게 해봤는데 처음 적용해보는 거여서 동작 확인은 배포 후 직접 테스트 해봐야 할듯 합니다 ㅎ...

🤔 고민 했던 부분 (선택)

• 문제: 현재 헤더 컴포넌트가 바텀 시트의 영향으로 비대해짐에 따라 헤더 폴더 내에 바텀 시트와 관련된 컴포넌트들이 포함되어 있습니다. 바텀 시트의 메뉴들이 헤더에 종속 되어 있어 어쩔 수 없이 같은 폴더 안에 두게 되었는데 어색하다는 느낌을 지울 수 없네요
• 리뷰어의 의견이 필요한 부분: 혹시 적절한 폴더 구조 생각나시면 말씀해주세용

🔗 연관 이슈

• Closes [FEAT] - 헤더 세부 기능 구현 #10

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
maru-egg-fe-v2-client	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 5, 2025 5:53am

[github-actions]

🚀 Storybook 링크: https://6789e91d8356b60e6b422469-bglpqosnde.chromatic.com/

[swgvenghy]

고생하셨습니다...!!!

컴포넌트 폴더 구조와 관련해서는 어쩔 수 없는 느낌이 강하게 들기는 합니다,,, 다른 대안이라면 admissionQuickLinkTabs와 concat 컴포넌트를 바텀시트 폴더 내부에 저장하는 방법이 있긴 하겠네요. 헤더에서 이를 사용하긴 하지만 결국 바텀시트 내부에서 동작하는 컴포넌트니까요..! 저라면 해당 방향으로 진행했을 것 같긴합니다...! 참고해주시면 좋을 것 같아요..!

[swgvenghy]

진짜 사소한거긴한데 저는 해당 경우에 아래 방법처럼 기본값을 주는 방법을 선호하거든요...! 혹시 해당 방법에 대해서는 어떻게 생각하시나요?

Suggested change

	function AdmissionQuickLinkTabs({ initialAdmissionType }: { initialAdmissionType: AdmissionType | null }) {
	const [selectedAdmissionType, setSelectedAdmissionType] = useState(initialAdmissionType ?? 'SUSI');
	function AdmissionQuickLinkTabs({ initialAdmissionType='SUSI' }: { initialAdmissionType: AdmissionType}) {
	const [selectedAdmissionType, setSelectedAdmissionType] = useState(initialAdmissionType);

[qwer0114]

좋은 의견 감사합니다! 다만 제안해주신 개선 방안이 기존 코드를 완벽히 대체 하지 못할 거 같아요 ㅠㅠ..
이유는 다음과 같습니다!

initialAdmissionType 은 null값을 허용해야만 하는 상황입니다(사용자가 선택하기 전 admissionType 전역상태에서 null 값으로 초기화),
이 상황에서 매개변수 기본값 (="SUSI")는 예상대로 작동하지 않습니다.

• 매개변수 기본 값은 undefined 일 때만 작동하고, null이 전달되면 null이 useState에 전달되기 때문입니다

만약 제안해주신 방법을 사용하기 위해서는 부모 컴포넌트에서 AdmissionQuickLinkTabs 컴포넌트에서 props를 전달할 때 null값일 시 props를 전달하지 않는 방법으로 수정할 수 있을거 같지만 개인적으로 해당 방법보다 기존 방법이 괜찮을거 같은데 어떻게 생각하시나용??

아니면 혹시 제가 제안 주신 부분을 잘못 이해하고 있다면 다시 한번 설명해주시면 감사하겠습니다 😢

[swgvenghy]

그러네요...! 너무 단순히 보이는 부분만 생각해서 말씀드린 것 같습니다! 기존 방법이 괜찮을 것 같네요!

[qwer0114]

고생하셨습니다...!!!

컴포넌트 폴더 구조와 관련해서는 어쩔 수 없는 느낌이 강하게 들기는 합니다,,, 다른 대안이라면 admissionQuickLinkTabs와 concat 컴포넌트를 바텀시트 폴더 내부에 저장하는 방법이 있긴 하겠네요. 헤더에서 이를 사용하긴 하지만 결국 바텀시트 내부에서 동작하는 컴포넌트니까요..! 저라면 해당 방향으로 진행했을 것 같긴합니다...! 참고해주시면 좋을 것 같아요..!

현재 components/bottom-sheet는 공통 바텀시트 레이아웃으로 여러 곳에서 재사용될 수 있는 컴포넌트입니다. 헤더 메뉴용 바텀시트는 헤더에 종속된 컴포넌트이므로, 해당 폴더 내부보다는 components/header/bottom-sheet 폴더를 새로 만들어 관리하면 추후 유지보수 시 관련 코드를 찾고 수정하기 더 쉬울 것 같습니다. 혹시 해당 방법은 어떻게 생각하시나용??
또한 추후 학과 선택 등에서 바텀 시트의 내부 컴포넌트가 추가될 예정인데, 이런 컴포넌트들까지 공통 바텀시트 폴더에 두게 되면 폴더 구조가 복잡해질것 같은 우려도 있습니다 😢

[swgvenghy]

t는 공통 바텀시트 레이아웃으로 여러 곳에서 재사용될 수 있는 컴포넌트입니다. 헤더 메뉴용 바텀시트는 헤더에 종속된 컴포넌트이므로, 해당 폴더 내부보다는 components/header/bottom-sheet 폴더를 새로 만들어 관리하면 추후 유지보수 시 관련 코드를 찾고 수정하기 더 쉬울 것 같습니다. 혹시 해당 방법은 어떻게 생각하시나용??
또한 추후 학과 선택 등에서 바텀 시트의 내부 컴포넌트가 추가될 예정인데, 이런 컴포넌트들까지 공통 바텀시트 폴더에 두게 되면 폴더 구조가 복잡해질것 같은 우려도 있습니다 😢

말씀하신 것 처럼 header/bottom-sheet 폴더를 구성하는게 제일 좋아보여요!
해당 내용 반영 하신 후 바로 머지하시면 될 것 같습니다!

[github-actions]

🚀 Storybook 링크: https://6789e91d8356b60e6b422469-zpdudrlnev.chromatic.com/

[qwer0114]

t는 공통 바텀시트 레이아웃으로 여러 곳에서 재사용될 수 있는 컴포넌트입니다. 헤더 메뉴용 바텀시트는 헤더에 종속된 컴포넌트이므로, 해당 폴더 내부보다는 components/header/bottom-sheet 폴더를 새로 만들어 관리하면 추후 유지보수 시 관련 코드를 찾고 수정하기 더 쉬울 것 같습니다. 혹시 해당 방법은 어떻게 생각하시나용??
또한 추후 학과 선택 등에서 바텀 시트의 내부 컴포넌트가 추가될 예정인데, 이런 컴포넌트들까지 공통 바텀시트 폴더에 두게 되면 폴더 구조가 복잡해질것 같은 우려도 있습니다 😢

말씀하신 것 처럼 header/bottom-sheet 폴더를 구성하는게 제일 좋아보여요! 해당 내용 반영 하신 후 바로 머지하시면 될 것 같습니다!

t는 공통 바텀시트 레이아웃으로 여러 곳에서 재사용될 수 있는 컴포넌트입니다. 헤더 메뉴용 바텀시트는 헤더에 종속된 컴포넌트이므로, 해당 폴더 내부보다는 components/header/bottom-sheet 폴더를 새로 만들어 관리하면 추후 유지보수 시 관련 코드를 찾고 수정하기 더 쉬울 것 같습니다. 혹시 해당 방법은 어떻게 생각하시나용??
또한 추후 학과 선택 등에서 바텀 시트의 내부 컴포넌트가 추가될 예정인데, 이런 컴포넌트들까지 공통 바텀시트 폴더에 두게 되면 폴더 구조가 복잡해질것 같은 우려도 있습니다 😢

말씀하신 것 처럼 header/bottom-sheet 폴더를 구성하는게 제일 좋아보여요! 해당 내용 반영 하신 후 바로 머지하시면 될 것 같습니다!

064c0a2 반영했습니다!