문제의 발생

지난번에 이어 스로틀링 작업을 진행하는 중 requestAnimationFrame에 관한 글을 봤다.

https://inpa.tistory.com/entry/🌐-requestAnimationFrame-가이드

사실은 스크롤 위치를 기반으로 세밀하게 애니메이션을 컨트롤 해야 되는 요소는 없어서, 현재 적용된 스로틀링으로도 문제가 없어 보이지만 새롭게 적용해 보도록하자

문제에 접근 하기

우리가 사용하는 모니터는 초당 60 프레임을 출력시에 애니메이션이 부드럽게 보인다고 한다. 물론 setTimeout을 이에 맞게 이용해 60프레임을 적용해 줄 수 있지만, setTimeout은 프레임을 신경쓰지 못 하고 작동하고 실행시간이 보장되지도 않는다는 문제가 있다. requestAnimationFrame 즉 raf는 이러한 점들을 해결해 줄 수 있다 자세한 내용은 위에 첨부한 포스팅에 잘 정리가 되어있다.

requestAnimationFrame을 사용하면 과한 스크롤 이벤트를 제어하고 setTimeout 보다는 적은 함수 호출이 있을 것으로 기대가 되긴 하는데 일단 적용해보도록 하자.

문제 해결

우선 raf는 mdn에 나와 있는 것 처럼 callback을 인자로 받는다.

그리고 아래에서 처럼 변수 ticking을 통해 raf가 이미 실행중이면 실행되지 않도록 설정한다.

function rAFScroll(callback) {
  let ticking = false;

  return function handler() {
    if (ticking) return;
    ticking = true;

    requestAnimationFrame(() => {
      ticking = false;
      callback();
    });
  };
}

눈에 보이는 점은 네비게이션 바가 스크롤 위치에 따라 투명도가 설정 되는데 이 부분이 더 자연스럽게 적용이 되었다는 점 그리고 눈에 띄는 변화는 아니지만 코드가 가독성이 좋아진 정도가 있을 것 같다.

글을 마치며

꼬리에 꼬리를 물듣 계속해서 문제를 해결할 수 있는 새로운 방법들이 나온다. 그동안 ‘기능이 작동하면 되는거지’ 라고 생각하고 더 나은 방향을 쫓아 가는 것에 대해 너무 무심했음을 느끼게 된다. 그러한 무심함이 지금의 결핍을 느끼게 하는데 가장 큰 요인이 아닌가 생각이 들었다.

계속 찾다보니 requestAnimationFrame 보니 IntersectionObserver를 적용하는게 더 맞는 방법일 수도 있겠다