[Feature] 인증에 따른 UI 변경사항 적용 및 공통 컴포넌트 구현

[cobocho]

PR Type

• 기능 추가

Overview

• 변경사항에 따른 공통 컴포넌트 구현 (SearchBox, Dropbox, Accordion 등등)
• 테스트코드 및 스토리북 환경 통일을 위한 MSW 일부 적용
• API 인증 로직 추가
• 공용 모달 컴포넌트 구현
• API 빌더 생성

Additional Comment

현재 인증의 경우 서버 사이드와 클라이언트 사이드에서 동시에 인증을 지원하기 위해서 액세스 토큰, 리프레쉬 토큰을 쿠키에 저장하고 2차적으로 리액트 쿼리의 클라이언트에 저장하고 있습니다. 실제 인증이 필요한 API를 사용하실 때는 커스텀 훅에 현재 환경에 맞는 리액트 쿼리의 클라이언드를 인자로 담아서 사용하시면 됩니다. ex) 클라이언트 사이드의 경우 useQueryClient, 서버 사이드의 경우 utils 폴더의 getQueryClient

여쭤보실거나 피드백 있으시면 리뷰에 달아주세요!!

Issue

Check List

• 관련된 이슈를 연결하였나요?
• 올바른 PR 컨벤션을 작성했나요?
• 적절한 라벨을 선택했나요?
• Assignee와 Reviewer를 설정했나요?

References

[hin6150]

저번 commit도 그렇고 dvw, dvh 단위는 처음봐서 조금 신기하네요
주소표시줄에 따른 동적인 vh값이라는데 하나 배워갑니다 😄

[hin6150]

수고하셨습니다~!
모달 부분이 되게 깔끔하게 잘 구현되어 있는 것 같아요!!

궁금한 부분이 있는데 modalType은 useState로 로컬로 관리하는 이유가 따로 있을까요? 이전에 globalModal을 작업할때는 modalType 또한 useModal 내부에서 관리하는 방식으로 구현했던 기억이 있어 여쭤봅니다 !! 🧐

크게 다르지는 않는데, 그때는 아래와 같이 컴포넌트가 아닌 Modal을 관리하는 부분에서 반환했던 것 같아용

const MODAL_COMPONENTS = [
  {
    type: MODAL_TYPES.CreateClubModal,
    component: <CreateClubModal />,
  },
  {
    type: MODAL_TYPES.RegisterModal,
    component: <RegisterModal />,
  },
 . . .
 
   const findModal = MODAL_COMPONENTS.find((modal) => {
    return modal.type === modalType;
  });

  const renderModal = () => {
    return findModal?.component;
  };

[cobocho]

@hin6150

개인 취향의 영역이라고는 생각하는데 저는 모달 컴포넌트 자체에 대한 컨텍스트를 모달이 필요한 위치에서 주입할 수 있도록 작업하는 편이에요.

예를 들어서 블로그 포스트 수정 모달이 존재한다고 했을때 포스트의 identifier를 포스트 페이지 => 전역 상태관리 => 포스트 수정 모달 같은 방식으로 컨텍스트의 필요한 값을 넘겨주어야 하지만 (물론 타입 시스템을 통해 어느정도 해결 가능하긴 합니다) 현재의 경우는 호출하는 컴포넌트에서 컨텍스트에 필요한 prop이나 데이터를 바로 주입할 수 있어서 비교적 모달 생성을 쉽게 할수 있어가지구요.

반대로 중첩 모달같은 경우에는 id를 사용하는 방식이 더 편할 수 있다고 생각합니다!