시연영상 : https://www.youtube.com/watch?v=tlWO8ZRHJQw

기획

끝난지 1주일도 안지났는데 벌써 기억이 잘 안난다. 얼른 정리를 해둬야 될 것 같다. 좋은 프로젝트라는 평을 받아서 기억에 남는 프로젝트기도 했고, 중간에 꽤 내 개발자생에 영향을 미칠 만한 말도 들었던 프로젝트라 꼭 정리를 해야된다.

팀원이 여성 둘이었어서 자두 캘린더라는 말이 나왔을 때, 농담이겠지? 했는데 찐이었다. 팀명이 중요한건 아니니까 대충 넘기고, 문제 정의부터 시작했다. 난 최대한 프로젝트를 문제 정의를 하고 시작하거나, 아니면 반드시 이 프로젝트가 필요한 이유를 찾고 시작하려고 한다. 프로젝트를 하다보면 시도 때도 없이 내가 이걸 왜 시작했더라? 라는 고민이 찾아온다. 그 때 마다 방향을 잡아준다.

문제 확인

문제는 팀원이 사용하고 있는 노션에 불편함이 있는 것이었다. 노션의 캘린더 양식은 하나의 형식밖에 지정할 수 없어, 새롭게 양식을 만들어서 사용하는데, 매주 템플릿을 복사 붙여넣기 해야 되서 번거로움이 있고, 카테고리를 통해 구분하지 못해서 모든 내용이 한 화면에 나오는 불편함이 있었다.

또한 문제는 아니지만 해당 프로젝트는 라이브러리나 프레임워크 없이 순수 자바스크립트와 web api 로만 구성해야하는 제한이 있었다.

역할 확인 및 분배

기획한 캘린더는 주요하게 구현해야 헀던 기능들이 있었다.
1. 무한스크롤 & 현재 active 한 월 감지
2. 요소 드래그 앤 드롭으로 이동
3. 요소 추가 제거 및 DOM 조작

그래서 나는 무한스크롤과 현재 액티브 월 감지 기능을 맡아서 구현했다. 또한 겸사겸사 달력의 DOM 을 만들어내는 부분도 같이 맡았다.
부차적인 기능으로 생각해서 금방 끝날 줄 알았는데 달력을 만들 때 멘탈이 더 터졌다.

무한스크롤

무한스크롤을 구현하면서 처음으로 한 고민은 과연 이 매월 매월을 상태로 관리하여, 새로운 월이 생성될 때마다 재렌더링을 해줄 것인가, 아니면 DOM 트리를 유지하고 새로운 월을 이어 붙일 것인가였다. 리액트를 사용할 수 있었다면 고민도 하지 않고, 전자를 선택했을 것이다. 프로그램의 복잡도를 대폭 낮출 수 있다. 하지만 바닐라 자바스크립트만을 사용해야 되기 때문에 고민이 되었다.

상태를 유지하고 이 상태를 통해 상태 변경이 있을 때마다 재렌더링을 해주면 코드를 간략하게 짤 수 있다. 또한 프로그램의 복잡도 또한 낮출 수 있다.

하지만, 재렌더링이라는 것은 화면의 모든 DOM 트리를 다시 그린다는 뜻이고, 이 과정은 프로그램에 부하를 많이 주는 작업이다. 때문에, 이 상태를 사용해 프로그램을 작성할 때는 신중하게 해야한다.

확실히 DOM 요소에 이어 붙이는 방식은 코드의 복잡도를 엄청나게 높히고, 이해를 힘들게 만들었다. 또한 유지보수에도 불리해 보였다.

하지만 사용자가 얼마나 많은 DOM 을 만들어낼지 모르는 상태에서 무작정 모든 만들어지는 DOM트리를 재렌더링 한다는 것은 사용성을 저하시킬 수 있다고 생각했다.

상태를 통한 리렌더링

// theudo code
renderedCalendar.map(month => render(month));

DOM 트리 유지 코드

// theudo code
const $calendar = document.querySelector('.calendar');
const todayMonth = () => {
  $calendar.innerHTML = `이번 월 DOM 트리`
}
  
const prevMonth = () =>{
  $calendar.insertAdjacentHTML('afterbegin', `이전 달 DOM 트리`)
}

const nextMonth = () => {
  $calendar.insertAdjacentHTML('beforeend', `다음 달 DOM 트리`)
}

간단하게만 봐도 DOM 트리에 위 아래로 이어 붙이는 코드는 수도 코드인데도 불구하고 복잡해 보인다.

결론

캘린더는 DOM 트리를 이어붙이는 방식으로 유지하고, 아이템들은 상태로 가지고, 변화가 일어날 때, 재렌더링을 하거나, DOM 트리에 이어붙이는 방식을 유지했다.
특히 프로젝트 구조 상, 카테고리가 변경 될 경우 아이템 렌더링이 전체 변경 되어야 하므로, 아이템을 추가할 경우 모든 아이템을 해당 카테고리로 재렌더링해주는 방식을 사용했다. 하지만 아이템 요소를 이동시키거나, 내용 변경, 삭제의 경우 DOM 트리 조작으로도 화면 변환이 가능하므로, 상태값과 DOM 트리를 함께 변경시켜주는 방식을 사용했다.

이를 통해 재렌더링이 일어날 경우에도 이전 상태를 기억해, 화면을 유지할 수 있게 만들었다.

시안점

캘린더를 DOM 트리로 구성하니 코드가 어마어마하게 커지고 복잡해졌다. 중복을 줄인다고 줄였지만, 내가 작성하는 코드가 for문을 사용해야만 하고, 또한 이 for문 마다 조금 조금씩 차이가 있어, 중복을 줄이기가 쉽지 않았다. DOM 트리로만 화면 조작을 하려고 하니 쉬운 일이 아니었다.

또한 캘린더가 상태를 유지하지 않기 때문에, 많은 스크롤을 올리거나 내린 후 현재 작업중인 월을 기억해서 재렌더링이 일어나도 그 자리에서 작업하는 것이 불가능했다. 이는 사용성을 떨어뜨리는 문제였다.

우리 팀은 사용자가 작업하던 월을 기억해, 특정 월을 기점으로 재렌더링을 해주는 방식으로 이 문제를 해결했다. 하지만 화면 크기마다 다른 스크롤 크기 때문에, 작업하던 위치를 정확히 지정해주는 것이 힘들었다. 때문에 화면이 살짝 튕기는 현상이 발생했다. 이런 부분도 상태를 기억하지 못해 발생하는 문제라고 할 수 있을 것이다.

실제 구현

예제 코드 (무한 스크롤)

특정 월의 마지막일 경우 다음 월을 추가해주는 코드

document.addEventListener('scroll', () =>{
    if ((window.innerHeight + window.scrollY) >= document.body.offsetHeight) {
	// 특정 작업
      } 
})

문제점

1. 스크롤 이벤트가 엄청나게 발생
2. 예제는 전체 화면을 기준으로 하지만, 나의 경우는 특정 DOM 요소 안에서만 작동해야 함.

해결

1. 스크롤 이벤트가 너무 많이 발생하는 것은 스로틀을 이용해서 해결했다.

  const throttling = (() => {
    let throttleCheck;
    return {
      throttle(callback, milliseconds) {
        if (!throttleCheck) {
          throttleCheck = setTimeout(() => {
            callback();
            throttleCheck = false;
          }, milliseconds);
        }
      }
    };
  })();

2. 캘린더 안에서만 사용해야 되는 문제는 DOM 에서 사용할 수 있는 다른 기준을 이용해서 해결

scroll 이벤트를 안에서 사용해야되서 window.innerHeight, scrollY 를 사용하지 못함

$calendarGrid.onscroll = () =>{
    if($calendarGrid.scrollTop < 1){
        changePrevMonth();
    if ($calendarGrid.scrollHeight - Math.ceil($calendarGrid.scrollTop) 
        === $calendarGrid.clientHeight) {
        changeNextMonth();
    }
}

위와 같이 변형해서 사용했다.

아래로는 무한스크롤이 되는데, 위로 안되는 문제 발생
-> 스크롤Top을 1미만으로 바꾸고, 위에 부딪힐때마다 top=1 로 바꿔주어서 리프레시가 가능하도록 변경
-> top 이 1일 경우 연속으로 스크롤링 하면 적용안되는 문제 발생
-> top을 300 으로 변경

$calendar.onscroll = () =>{
    throttling.throttle(()=>{
        if($calendar.scrollTop < 200){
            changePrevMonth();
            $calendar.scrollTop = 500;
            const $standards = document.querySelectorAll('.standard');
            [...$standards].forEach($standard => {
                io.observe($standard);
            })
        }
        if ($calendar.scrollHeight - Math.ceil($calendar.scrollTop) <= $calendar.clientHeight) {
            changeNextMonth();
            const $standards = document.querySelectorAll('.standard');
            [...$standards].forEach($standard => {
                io.observe($standard);
            })
        }
    }, 500);
};

인터섹션 옵저버

특정 일자가 화면에 나타나는지 감지해서, 다른 돔요소의 텍스트 값을 바꿔주어야 했다.

이 부분을 해결하기 위해 인터섹션 옵저버를 사용했다.

const io = new IntersectionObserver(entries =>{
    entries.forEach(entry => {
        if(entry.isIntersecting){
            $calendarYear.textContent = entry.target.children[0].children[0].textContent + ".";
            $calendarMonth.textContent = entry.target.children[0].children[1].textContent + ".";
        }
    } );
}, {
    root:$calendar,
    rootMargin: '0px 0px -50% 0px'
});

$calendar.onscroll = () =>{
        if($calendar.scrollTop < 1){
            changePrevMonth();
            $calendar.scrollTop = 640;
            const $standards = document.querySelectorAll('.standard');
            [...$standards].forEach($standard => {
                io.observe($standard);
            })
        }
        if ($calendar.scrollHeight - Math.ceil($calendar.scrollTop) <= $calendar.clientHeight) {
            changeNextMonth();
            const $standards = document.querySelectorAll('.standard');
            [...$standards].forEach($standard => {
                io.observe($standard);
            })
        }
    }, 500);
};

인터섹션 옵저버는 특정 요소가 기준점으로 잡는 요소의 외곽을 교차함으로 화면에 나타날 때를 감지해주는 객체이다.

이 기능을 이용해 구현해야 하는 것은 메인의 년월을 렌더링해주는 것과, 현재 보여지는 월만 active하게 처리해주는 것이다.

달력에서 구현해야 하는 요구사항 중 하나가 현재 년월에 해당 하는 달만 ACTIVE 하게 처리하고 나머지는 색깔을 다르게 해서 구분해주어야 하는 것이었다.

이 부분을 간단하게, standard 클래스를 매월 1일에 주고 인터섹션 옵저버의 감지 부분을 지나갈 때 마다 년월을 바꾸는 동시에 해당 월 부분만 active 하게 만들려고 했다. 하지만 매월 1일을 기준으로 해서 인터섹션 옵저버를 구현하면, 교차하는 시점에서 월이 바뀌기 때문에, 화면에서 보이고 있는 실질적인 월과 렌더링되는 월이 다른 경우가 발생했다.

이 문제를 해결하기 위해서 15일에 주고 앞 뒤로 unactive를 주었는데, 이 때는 todo나 요소가 과하게 들어가서 화면에 한 주만 표시될 경우에 문제가 발생했다.

이 문제를 해결 하기 위해서는 모든 주에 standard 클래스를 주고 반드시 한 주는 intersection observer에 감지되도록 만들어야 했다. 하지만 이렇게 하면 intersection observer에 감지되는 타겟이 월에 1회가 아니기 때문에, 계산이 매우 복잡해진다. 매주 감지되는 일자의 1일까지 남은 수와, 말일 까지 남은 일자의 숫자를 계산해 액티브로 만들어주었다.

이를 통해 문제를 해결했다.

찐 후기

나는 거의 항상 코드를 혼자서만 짰었고, 팀플을 해도 프론트, 백 이렇게 나눠서 작업을 했었기 때문에, 내 코드를 누군가 쓴다는 건 생각도 해본 적이 없었다.

수요일 오후에 팀원 한 명이 내 코드가 필요하다고 했다. 내가 달력을 구현한 부분에서 달력 전체를 렌더링 하는 코드가 있었는데, 이 부분이 필요했던 것이다. 당연히 예측할 수 있는 범위였고, 나도 다른 사람이 쓸 수도 있다고 막연하게만 생각했다. 하지만 그 말을 듣고, 그 사람이 내 코드를 가져다 쓰는 것이 현실이 되었을 땐 그 무게가 달랐다.

내 코드는 1000줄이 넘어갔고, 변수명에 대한 의미도 제대로 설정해놓지 못한 상태였다. 아니, 기억이 정확하게 안 났다는 게 정확하겠다. 막말로 코드를 싸질러놓은 상태였다.

내가 쓴다면 위에서부터 쭉 읽어가면서 예측가능했겠지만, 남이 내 코드를 갖다 쓴다면? 남이 자기 코드도 아닌데, 모든 코드를 처음부터 읽어가면서 해석해서 가져다 쓴다는 건 너무 부끄러운 일이었다. 무슨 생각을 하겠는가! 나라도 개빡칠거같다. 그 날 밤에 바로 집에 가서 리팩토링을 하기 시작했다. 변수명을 구분하고 정말 못 고치겠는 부분엔 주석을 달았다. 하지만 가장 신경 쓴 것은, 딱 함수명만 가져다가도 쓸 수 있도록 코드를 만들어놓는 것이었다. 이를 위해서 모든 코드를 클로저 안으로 응집시키고, 해당 변수나 함수를 리턴해주는 객체를 반환했다.

최대한 의미적으로 함수를 분리해서 함수를 연쇄호출하기만 하면 원하는 결과가 나오도록 했다. 인수를 전달하는 것은 최대한 자제했다. 나도 이 인수가 뭔지 나중에 모를 것 같았다.

처음으로 책임감있게 코드를 짜야한다는 것을 실감했다.