[Feature]: useResizeObserver dimension 추가

[Sangminnn]

Package Scope

• 기존 패키지에 기능 추가
• 새로운 패키지
• Package name: @modern-kit/react/hooks

Overview

타겟 엘리먼트의 dimension 정보에 대해 접근이 가능한 훅입니다.

const { ref, dimensions } = useResizeObserver()

/*
  반환받은 dimensions
  offsetWidth: 0,
  offsetHeight: 0,
  offsetTop: 0
  offsetLeft: 0,
  clientWidth: 0,
  clientHeight: 0,
  clientTop: 0,
  clientLeft: 0,
  scrollWidth: 0,
  scrollHeight: 0,
  scrollTop: 0,
  scrollLeft: 0,
*/

[ssi02014]

좋은 훅이라고 생각합니다!! 👍

[ssi02014]

@Sangminnn 해당 훅에 대해 고민을 조금 해봤습니다! 개인적으로 훅을 신규로 추가하기보다 useResizeObserver에 내에서 dimension 상태를 추가하면 좋을 것 같은데 어떻게 생각하실까요!?

useResizeObserver 훅이 ResizeObserver를 사용하기 때문에 현재의 범용적인 네이밍을 갖고 있는데, 현재도 타겟 요소의 contentRect를 관리 하고 있고, 여기에 타겟 요소의 dimension 상태가 추가로 관리되어도 크게 어색함이 없을 것으로 판단했습니다!! 👍

return { ref, contentRect, dimension }

[ssi02014]

@Sangminnn

추가적으로 dimension은 특정 요소의 크기를 포함한 좀 더 넓은 범주에 네이밍이라고 하네요! 특정 좌표에 조금 더 적합한 값은 coordinates가 될 것 같은데 coordinates 네이밍을 가진 상태를 추가하는게 어떨까요!? 아니면 position 이라는 네이밍도 좋은 것 같습니다 👍 (+ 좌표로 포커스를 맞췄으면 했던 이유는 타겟 요소의 크기는 contentRect에 포함되어 있기 때문입니다!)

아래 모던 자바스크립트 문서의 경우에는 좌표를 coordinates로 사용하네요!

https://ko.javascript.info/coordinates

[Sangminnn]

@ssi02014 좋은 방향으로 같이 고민해주셔서 감사합니다!

사실 기존에 진행하려던 방식 역시 useResizeObserver로부터 파생된 훅을 만들려고 했었고, 그러다보니 이미 기존의 방향에서도contentRect도 반환해주고있다보니 현 ResizeObserver의 입장에서 해당 값(dimensions)을 제공해주는 방향으로도 괜찮다면 저는 좋은 방향이라고 생각합니다! ( 최초 ResizeObserver를 제가 만들지 않았기때문에 혹시 기존 의도를 해치는건 아닐까 생각이 들었었네요! )

추가적으로 제안해주신 네이밍 변경건 역시 저도 최초에는 어떤 단어로 표현하는 것이 좋을지 고민하던 중 클로드와 이야기하며 받은 의견을 채택했었는데요! 아래에서 실제 단어에 대한 의미와 제안해주신 것을 종합해보았을때 클로드가 제안해준 dimensions 역시도 좋은 표현이나, 비교적 영어적 관점으로 느껴지기도해서 한글로 해석한 상태에서의 의미를 본다면 저도 제안해주신 두 단어가 더 좋아보입니다! 👍

제안해주신 두 단어 중에서는 coordinates 도 좋은 단어이나 position 이 coordinates 보다는 난이도가 낮은 친화적인 단어로 보여 사용하는 유저로 하여금 더 익숙한 단어일것같아서 position 으로 가는 방향은 어떨까 의견드려봅니다! 🙇

[ssi02014]

@Sangminnn 아! 정정하겠습니다. 현재 contentRect는 실제로 getBoudingClientRect와 동일한 데이터를 다루는 것으로 확인됐습니다.

• getBoudingClientRect: Viewport와 관련된 데이터

https://developer.mozilla.org/ko/docs/Web/API/Element/getBoundingClientRect#%EA%B0%92

x: 요소의 왼쪽 경계의 X 좌표 (뷰포트 기준)
y: 요소의 위쪽 경계의 Y 좌표 (뷰포트 기준)
top: 요소의 위쪽 경계의 Y 좌표
right: 요소의 오른쪽 경계의 X 좌표
bottom: 요소의 아래쪽 경계의 Y 좌표
left: 요소의 왼쪽 경계의 X 좌표
width: 요소의 너비
height: 요소의 높이

사실상 ContentRect는 요소의 크기를 포함한 viewport와 관련된 좌표 데이터를 이미 다루고 있기 때문에 해당 좌표에서 다루지 않는 값들을 추가 상태로 관리되면 좋을 것 같은데요! .예를 들어 다음과 같습니다 .

1. scrollTop, scrollLeft,scrollHeight,scrollWidth

scrollTop: 요소의 콘텐츠가 수직으로 얼마나 스크롤 되었는지 나타냅니다.
scrollLeft: 요소의 콘텐츠가 수평으로 얼마나 스크롤 되었는지 나타냅니다.
scrollWidth: 스크롤 가능한 콘텐츠의 전체 너비
scrollHeight: 스크롤 가능한 콘텐츠의 전체 높이

2. offsetTop, offsetLeft, offsetWidth, offsetHeigth

offsetTop: 요소의 위쪽 경계가 부모 컨테이너로부터 얼마나 떨어져 있는지 나타냅니다.
offsetLeft: 요소의 왼쪽 경계가 부모 컨테이너로부터 얼마나 떨어져 있는지 나타냅니다.
offsetWidth: 요소의 테두리를 포함한 너비 (스크롤 바 포함)
offsetHeight: 요소의 테두리를 포함한 높이 (스크롤 바 포함)

3. clientTop, clientLeft, clientWidth, clientHeight

clientTop: 요소의 테두리 상단 두께
clientLeft: 요소의 테두리 왼쪽 두께
clientWidth: 요소의 패딩을 포함한 너비 (스크롤 바, border 제외)  -> offset과의 차이
clientHeight: 요소의 패딩을 포함한 높이 (스크롤 바, border 제외)

추가적으로, offsetHeigth/Width, clientHeight/Width가 getBoudingClientRect에서 다루는 width/height와 동일한 경우도 있지만, 100% 동일하지 않기 때문에 따로 관리되는게 적절하다고 생각합니다.

• offsetWidth vs getBoundingClientRect

결론

결론적으로 위 12가지 데이터를 다루는 것은 크기가 포함되어 있기 때문에 position은 어색한 것 같고 dimension이 더 나은 것 같습니다!

[Sangminnn]

@ssi02014 좋은 레퍼런스와 함께 다각도로 고민해주셔서 감사합니다! 🙇 위의 내용을 확인해보니 dimension도 충분히 좋은 표현으로 보이네요! 👍

괜찮으시다면 기존의 resizeObserver에 dimension을 추가하여 반환할 수 있도록 제가 작업해도 될까요 ?? 😄

[ssi02014]

@Sangminnn 좋습니다!!! 감사합니다👍👍