Project : Compare Library with my Calendar

lunaxislu·2024년 2월 7일

목록 보기

15/17

마지막 팀 프로젝트를 시작하기에 앞서 프로젝트 목표는 배포 및 라이브러리 설치 과정을 최적화하고 로딩 속도를 개선하는 데에 초점을 맞추었다.

이에 따라 기존에 사용했던 yarn 1.22 버전 대신 -> yarn berry 를 도입하였으며,

이미지 최적화를 위한 라이브러리인 sharp를 설치하는 등

프로젝트의 방향성에 알맞게 최적화를 해나아가면서 웹페이지 구현을 해나갔다.

Problem

기술 스택과 맞지 않는 라이브러리

내가 프로젝트 내에서 "sales" 페이지를 담당했다.

처음에는 React Calendar 를 사용하여 매출 현황을 달력과 차트로 시각화하는 비즈니스 로직을 구현하려 시도했었다.

그러나 React Calendar에 커스텀 CSS를 적용하기 위해서는 일반적으로 styled-components 를 사용하여 중첩하여 커스텀해야 했다.

우리의 CSS 기술 스택과는 호환되지 않아 다른 캘린더 라이브러리를 조사하게 되었다.

라이브러리의 용량 차이

그 중에서도 조건부 데이터 맵핑과 커스터마이징이 가능한 react-big-calendar 를 고려하였다. 그러나

react-big-calendar 는 용량이 크고, 기존의 React Calendar 보다 3배 이상이었다.

데이터 맵핑이 어려운 캘린더 라이브러리 && 시간적 제한

다시금 라이브러리를 찾아보다가

대안으로 찾아본 react-datepicker 의 예시 코드를 확인했을 때, 우리가 기대하는 캘린더와 데이터가 매핑되는지 확인 할수 없었다.
react-datepicker

프로젝트의 중간점검 전 까지 해야만 하는 기능구현과 전반적으로 관리자 Page의 기획을 맡아 자료를 수집하고, 다른 팀원들의 POS기 로직에 관련된 세세한 기능들을 점검 해야하는 시간적 여유와 제한이 있기에 차라리 react-calendar를 사용할 수 있도록

"Styled-component를 사용하자고" 의견을 팀원들에게 어필을 하였다.

그러나

팀원들은 먼저 CSS Module로 CSS를 진행하는 상황이였으며, 부팀장의 CSS MODULE을 사용하고 싶다는 의견 중 "CSS와 JS를 명확히 분리하고 싶다"라는 의견에 CSS Module로 계속 진행하게 되었다.

세상에 쓸모없는 경험은 없다

CSS Module로 계속해서 기술 스택을 채택 하였을 때,
불만이 있었다.

프로젝트가 아직 초기 단계였다.
전반적 기능 구현에 styled-component를 사용해도 되었었다.

계속해서 프로젝트를 진행하고 시간이 흘러가면서 위의 내용이 머릿속에 맴돌았지만,

여태 해왔던 경험들이 필요없지는 않았으며, 이러한 불편함 속에서 새롭고, 뜻밖의 기회를 맞이 할수도 있겠다 라는 생각으로 다시금 마음을 잡았다.

캘린더를 구현하기 위해 우선 블로그글들을 찾아 보았고 그 중에서 한 가지를 선택해 캘린더 구현을 하였다.

참고했던 블로그

// 캘린더 메인 로직
//... 생략 

// monthStart가 속한 주의 시작 주
const startDay = currentDate.startOf('month').startOf('week');
// monthStart가 속한 마지막 주
const endDay = currentDate.endOf('month').endOf('week');
const row = [];
  let days = [];
  let day = startDay;
  while (day <= endDay) {
    for (let i = 0; i < 7; i++) {
      const itemKey = day.format(FORMAT_CELL_DATE_TYPE);
      days.push(
        <CellItem 
          id={itemKey}
          page={page} // page별 이벤트 조건 props
          mode={mode} // big Calendar || mini Calendar 일 때 조건 props
          day={day} // 날짜가 들어갑니다.
        />,
      );
      day = day.add(1, 'day');
    }
    row.push(
      <div key={days[0].key} className={styles.calendarRow}>
        {days}
      </div>,
    );
    days = [];
  }
  return (
    <div>
      {row}
    </div>
  );

블로그를 참고해서 필요없는 코드와 프로젝트에 필요한 기능을 추가한 로직으로 캘린더 컴포넌트를 만들 수가있었다.

만들고 나니

Sales Page에서만 사용되는 것이 아닌, 주문 내역확인 Page 에서도 사용 될수 있게끔 조건을 더해 어떤 Page, 어떤 Component에서도 사용 될수있는 모듈화 된 캘린더를 만들 수 있는 경험 을 할 수가 있었다.

그리고....

최종적으로 빌드 및 배포할 때,
react-calendar , react-big-calendar , 그리고 제작한 데이터 맵핑용 캘린더의 용량 차이를 확인해보니 최소 2배에서 10배 이상의 차이가 있었다.

참고로
내가 만든 캘린더에는 우리 프로젝트에 맞게 커스텀된 CSS와 조건부 기능들이 포함되어 있었다.
반면에 비교 대상인 다른 외부 라이브러리 캘린더는 기본적으로 import된 상태에서 빌드되었다.

이로써 우리가 선택한 접근 방식이 용량 최적화와 성능 향상에 어떤 영향을 미쳤는지 명확히 파악할 수 있었다.

내가 만든 캘린더

대표적 캘린더 라이브러리 ( react-calendar, react-big-calendar )

npm library 도전

" 캘린더에 데이터 맵핑이 가능하고, 각 페이지별로 mini , big size의 캘린더가 되는 라이브러리가 없어서 "불편함"을 겪었다.
그러다 보니, 내가 라이브러리를 배포해서 다른 개발자들이 편의성과 효율성을 가질 수 있게 도움을 줄순 없을까 라는 생각이 든다.