드래그한 요소가 위치할 곳을 확인하기 위해 사용할 메서드 선택

Element.getBoundingClientRect() VS Element.closest()

두 메서드 중 Element.closest() 선택

Element.getBoundingClientRect()

What forces layout / reflow 문서를 보면 Element APIs > Getting box metrics > elem.getBoundingClientRect() 가 있음을 볼 수 있다.
즉, 이 메서드를 호출할 때마다 브라우저는 요소의 크기와 위치값을 최신 정보로 가져오기 위해 문서의 일부 혹은 전체를 다시 그리는 리플로우(reflow) 현상이 발생한다.
이 메서드를 일정을 드래그할 때마다 호출하게 되면 성능에 문제를 줄 수 있다.
요소의 크기와 위치값이 캐시될 수 있지만, JADOO 프로젝트의 경우, 일정이 새로 생성, 삭제, 이동되면서 getBoundingClientRect() 메서드로 계산할 요소의 크기와 위치값이 계속 변동되어 새로 계산될 확률이 높으므로 사용하지 않았다.
//(MutationObserver를 사용해 호출 수를 줄이는 방법도 있긴 하다.)

Element.closest()

레이아웃 계산이 필요없이 HTML의 부모자식관계를 이용하는 메서드를 사용했다.
해당 요소부터 시작해서 document까지 비교하게 되는데 조금이라도 덜 비교하기 위해 아래와 같은 커스텀 함수를 만들어 사용했다.

1
2
3
4
5
6
7
8
9
10
11
// closest 커스텀 함수
const closest = ($startElem, targetClass, endClass) => {
let elem = $startElem;
while (!elem.classList.contains(targetClass)) {
if (elem.classList.contains(endClass)) {
return null;
}
elem = elem.parentNode;
}
return elem;
};

closest()를 사용해서 발생하는 문제점

  • translatd3d동작원리