[6/6 ~ 6/12] 코드스쿼드 마스터즈 22주차 회고

💦  에어비엔비 프로젝트 마지막 주차!

 

어쩌다 보니 한주씩 밀려서 쓰고 있는 것 같은데 일주일 지나서 쓰려고 하니까 잘 기억이 안 난다 ( ･ᴗ･̥̥̥ )

다음 회고부턴 밀리지 말고 써야지 ㅠㅠ

 

 

🎉  고차 컴포넌트 적용

const SearchBar = ({ size = SEARCH_BAR_SIZE.LARGE }: SearchBarPropsTypes) => {
  ...
  return (
    <S.Container {...{ size }} onClick={toggleIsActive}>
      <PeriodProvider>
      	<PeriodArea {...{ size }} />
      </PeriodProvider>
      <PriceProvider>
      	<PriceArea {...{ size }} />
      </PriceProvider>
      <PersonnelProvider>
      	<PersonnelArea {...{ size }} />
      </PersonnelProvider>
    </S.Container>
  );
};

검색바의 요금 영역 부분을 구현하면서 상태를 관리하기 위해 Context API를 사용했다. 컨텍스트를 사용하기 위해서는 검색바 컴포넌트에서 해당 영역을 Provider로 감싸야하는데, 만약에 각 영역마다 Provider가 하나씩 있다고 하면 저렇게 들어가야 하는 건가 싶어서 이 부분이 좀 맘에 들지 않았다.. 이 부분을 숨길 수 있는 방법이 없을까 하다가 고차 컴포넌트가 생각나서 적용해보았다.

 

interface WithProviderPropsType<T> {
  Component: FC<T>;
  Provider: FC<ProviderTypes>;
}

interface ProviderType {
  children: JSX.Element;
}

const WithProvider = <T,>({ Component, Provider }: WithProviderPropsTypes<T>) => {
  return (props: T) => {
    return (
      <Provider>
        <Component {...props} />
      </Provider>
    );
  };
};

결론적으로 위와 같은 컴포넌트를 작성해서 사용했다. 컴포넌트와 Provider를 받아서 Provider로 감싼 컴포넌트를 내보낸다는 것까지 생각하는 건 어렵지 않았는데, 타입스크립트를 적용하는 부분이 좀 어려웠다. 이 부분을 구현할 때는 제네릭에 대해서 제대로 공부하지 않은 상태였어서 타입을 어떻게 지정해줘야 할지 감이 잘 안 왔던 것 같다. Provider는 고정적으로 children을 받는 컴포넌트니 그렇게 타입을 지정해줬는데 컴포넌트는 컴포넌트마다 받게 되는 props가 천차만별이라 재사용 가능하게 만들려면 타입을 직접 지정해줄 수가 없었다. 그래서 처음에는 Provider를 사용하는 컴포넌트들의 Props타입을 가져와 유니언 타입으로 만들어서 컴포넌트에 넣어줘 봤는데, 생각했던 대로 잘 작동하지 않았다. 그래서 제네릭에 대해 좀 찾아보고 적용함으로써 해결할 수 있었다. 이전에 고차 컴포넌트를 사용하려다가 잘 작동하지 않아서 실패했던 전적도 있고, 거기다가 타입스크립트까지 적용한 상태로 하려니 처음엔 제대로 만들 수 있을까 싶었는데 이번엔 잘 적용할 수 있어서 다행이었다!

 

 

🖋  useContext 커스텀 훅

// 1.
export const PriceContext = createContext<PriceContextType>({} as PriceContextType);

// 2.
export const PriceContext = createContext<PriceContextType | null>(null);

기존에는 createContext를 하면서 기본값으로 아무것도 넣어주지 않은 상태로 사용했는데, 타입스크립트를 적용하니 컨텍스트의 타입을 지정해주고 값을 넣어주지 않으면 타입 에러가 발생했다. 찾아보니 크게 두 가지 방법이 있었던 것 같은데, 첫 번째는 위처럼 빈 객체를 넣고 해당 컨텍스트의 타입으로 형변환시켜주는 방법이었다. 두 번째는 null도 받을 수 있도록 지정해주고, 기본값으로 null을 넣어준 뒤 사용할 때 null인지 여부를 체크한 후 사용하는 방식이었다.

지난주에 타입스크립트 스터디에서 형변환에 대해 공부하지 않았으면 첫 번째 방식이 더 간편하다고 생각해서 사용했을 것 같은데, 형변환은 타입을 변환하는 용도라기보다는 해당 타입을 타입스크립트가 정확히 알지 못할 때 알려주기 위해서 사용하는 거라고 했던 것 같아서 빈 값을 넣어주고 형변환하는 게 좀 찝찝하게 느껴졌다.

 

export const usePersonnelState = (
  type?: string,
): PersonnelStateWithType | PersonnelContextTypes => {
  const personnelState = useContext<PersonnelContextTypes | null>(PersonnelContext);
  if (!personnelState) throw new Error('PersonnelProvider is not found');

  const {
    numberOfAdults,
    setNumberOfAdults,
    numberOfChildren,
    setNumberOfChildren,
    numberOfBabies,
    setNumberOfBabies,
  } = personnelState;

  switch (type) {
    case PERSONNEL_TYPE.ADULT:
      return [numberOfAdults, setNumberOfAdults];
    case PERSONNEL_TYPE.CHILD:
      return [numberOfChildren, setNumberOfChildren];
    case PERSONNEL_TYPE.BABY:
      return [numberOfBabies, setNumberOfBabies];
    default:
      return personnelState;
  }
};

그래서 두번째 방식을 사용하기로 하고, null을 체크하는 부분을 커스텀 훅으로 만들어서 분리해주었다. 이렇게 하니 컨텍스트를 사용할 때 useContext를 컴포넌트에서 바로 사용하는 것처럼 쓸 수 있어서 좋았고, 또 props로 타입을 받아 해당 타입에 해당하는 상태만 반환해서 쓸 수 있도록 한다던지 하는 로직도 훅 안에서 작성하니 컴포넌트에서 필요한 상태만 가져다 쓸 수 있어서 편리하다고 느껴졌다.

 

 

🖥  모달창 구조 변경하기

지난주에 모달 구현 관련해서 리뷰어님께 질문을 드렸었는데, 이렇게 답변을 주셨다. 생각해보면 동일하게 쓰이는 모달의 구조는 재사용하더라도 createPortal을 사용해서 렌더링하는 부분까지 모두 통일할 필요는 없는 건데 반드시 createPortal을 사용해야겠다고 생각하고 있었던 것 같다. 그래서 createPortal을 사용하는 Portal 컴포넌트는 필요할 때만 쓰는 것으로 하고, DOM을 상태로 다루는 것 또한 렌더링에 영향을 주니 그러지 않는 게 좋을 것 같다는 피드백을 주셔서 해당 로직을 useModal 훅에서 삭제했다. 그리고 모달의 열림/닫힘 여부를 상태로 두고 모달 영역 밖을 클릭했을 때 모달창을 닫는 로직을 훅에 추가했다.

 

const handleModalClick = (event: MouseEvent) => {
  for (const element of event.composedPath()) {
    if (element === modalRef.current) return;
  }
  setIsModalOpen(false);
};

useEffect(() => {
  window.addEventListener('click', handleModalClick, true);

  return () => {
    window.removeEventListener('click', handleModalClick, true);
  };
}, [modalRef]);

이전에 모달을 구현할 때는 백그라운드에 화면 전체 크기와 동일한 div를 두어서 해당 div가 클릭되었을 때 모달이 닫히도록 구현했었다. 하지만 이번에는 검색바의 다른 영역을 클릭했을 때 열려있던 모달창이 닫히며 바로 다른 영역의 모달창을 띄워주어야 했는데, 이전처럼 구현하면 이 부분을 구현할 수가 없었다. 그래서 클릭한 영역이 모달 영역 안에 있는지 여부를 어떻게 확인할 수 있을까 하다가 이벤트 객체에서 path라는 속성을 발견했다.

path에는 해당 요소에서부터 최상위 요소인 window 객체까지가 배열로 담겨있었다. 이 속성을 자바스크립트에서 composedPath()로 가져다 쓸 수 있었는데, 이 배열을 돌면서 모달 영역의 ref 객체와 일치하는 요소가 있는지를 확인하여 모달 밖에서 클릭이 발생한 경우에 창을 닫아주도록 했다. 

그런데 이렇게 하니 검색바 영역을 아무리 클릭해도 모달창이 열리지 않았다. 모달을 열기 위해 각 영역에 등록해둔 클릭 이벤트와 useModal 훅에서 등록해둔 모달을 닫기 위한 클릭 이벤트가 같이 발생해서 그런 게 아닐까 싶었다. 그래서 window에 건 이벤트 리스너의 useCapture 옵션을 true로 지정해주니 모달이 잘 작동하는 것을 확인할 수 있었다. 

 

 

📑  그 외 자잘한 고민들

요금 슬라이더 같은 경우 컨텍스트 내에서 쓰이는 데이터를 서버에서 받아와서 쓰고 있었는데, 이때 데이터를 가져오는 로직을 Provider 안에 둘 것인지 컴포넌트 내에서 한 후 set 함수를 통해 상태에 넣어줄 것인지 고민이 되었다. 생각해봤을 때는 어디에 두냐만 다를 뿐 큰 차이점은 없지 않을까 싶었고 둘 중 더 많이 쓰이는 방식이 있는지 궁금했는데, 칸이 보통 사이드 이펙트여서 컴포넌트에서 데이터를 가져온 후 상태를 업데이트시켜주는 게 좋을 것 같다고 말씀해주신 리뷰를 공유해줬다. 그런가 싶기도 했는데 데이터를 가져와 넣어주는 것도 어떻게 보면 해당 상태와 관련된 로직 중 하나니까 같이 둬도 괜찮지 않나 싶은 생각이 들기도 했다. 근데 마스터 피드백 시간에 크롱도 해당 컴포넌트에서 데이터 fetch를 하는 게 맞다고 말씀하시는 것 같아서 앞으로는 그렇게 해봐야겠다고 생각했다.

const useCanvas = ({ canvasWidth, canvasHeight, animate }: useCanvasTypes) => {
  const canvasRef = useRef<HTMLCanvasElement>(null);

  useEffect(() => {
    const canvas = canvasRef.current;
    const ctx = canvas?.getContext('2d');

    const setCanvas = () => {
      const devicePixelRatio = window.devicePixelRatio ?? 1;
      if (canvas && ctx) {
        canvas.style.width = `${canvasWidth}px`;
        canvas.style.height = `${canvasHeight}px`;

        canvas.width = canvasWidth * devicePixelRatio;
        canvas.height = canvasHeight * devicePixelRatio;

        ctx.scale(devicePixelRatio, devicePixelRatio);
      }
    };
    setCanvas();
    ctx && animate(ctx);
  });

  return canvasRef;
};

또 캔버스를 사용할 때 캔버스와 컨텍스트를 생성하고, 캔버스를 그리는 함수를 받아 실행시켜주는 useCanvas 훅을 사용했다. 그런데 슬라이더에서 지정한 값의 범위에 따라 차트에서 해당 영역을 강조해서 그려주는 부분을 구현하기 위해서는 캔버스를 그리는 animate 함수를 슬라이더 값이 변경될 때마다 실행시켜주어야 하는데, useEffect 내에서 캔버스를 세팅하고 ref 객체만 반환하고 있는 훅의 구조상 animate 부분만 호출할 수가 없었다. 그래서 찝찝하지만 일단은 useEffect의 의존성 배열을 삭제했는데, 리뷰에서 '매번 리렌더링 되는 것을 예상하고 만드신거죠?' 라고 딱 이 부분을 언급해주셨다..ㅎㅎ 이렇게 하면 캔버스를 가져와서 컨텍스트를 만들고 크기를 세팅해주는 부분까지 불필요하게 매번 실행되는데, 어떻게 구조를 변경해야 할지 잘 생각이 나지 않아서 아직 개선하지 못했다. 좀 더 고민이 필요할 것 같다. 🥲

 

 

💨  에어비엔비 프로젝트 끝!

3주가 정말 호로록 지나가버렸다..ㅠ 이번 프로젝트도 아쉬움이 많이 남는 것 같다. 같이 팀이 되었던 지니랑 헤이호와도 너무 좋았고 슬라이더나 지도 API 사용 등 새롭게 도전할 수 있는 거리도 많았지만 기능 구현 여부를 떠나 내가 그만큼 열심히 임하지 못한 것 같아서 죄송한 마음이다.. 멘탈 관리 컨디션 관리 잘해서 마지막 프로젝트는 알차게 보낼 수 있도록 노력해야겠다.

그래도 이번 프로젝트는 리뷰 받은 내용이 알차서 좋았다! 빰빰이 질문한 부분뿐만 아니라 코드까지 꼼꼼하게 보고 피드백주셔서 잘한 부분은 어딘지, 개선해야 할 부분은 또 어딘지 알 수 있어서 좋았고 넘넘 감사했다. ㅎㅎ 덕분에 프로젝트를 하는 동안 왜 이런 코드를 작성했는지에 대해 좀 더 생각해볼 수 있었고, 앞으로 프로젝트를 할 때도 좀 더 의식적으로 코드를 작성하려고 노력하게 될 것 같다.  또 (좀 밀리긴 했지만) 3주 동안 주간 회고 안 빼먹고 작성한 건 잘한 것 같다. 평일 동안 고민했던 부분이나 어려웠던 부분을 간략하게나마 정리해두고 글로 풀어서 정리하니까 기억하기도 훨씬 좋을 것 같다. 좀 구구절절 적은 감이 없지 않아 있는데 그래도 이렇게 적어둬야 나중에 봤을 때도 이해할 수 있을 것 같아서 그냥 편하게 적었다..ㅎㅎ 앞으로도 꾸준히 작성할 수 있도록 해야겠다!