구현하기 전 생각

1. 컴포넌트 vs 커스텀 훅

• 드래그 슬라이더를 구현할 때의 목표는 일반 컴포넌트를 드래그 슬라이드하고 싶을 때 쉽게 기능을 추가할 수 있는 형태로 만드는 것이었습니다.
• 컴포넌트로 드래그 슬라이더를 구현하면, 컴포넌트로 감싼 children을 제어하는 형태가 될 것이고, 커스텀 훅으로 만든다면 기능을 추가하기 원하는 컴포넌트에 훅을 적용해 움직일 수 있게 하는 형태일 것입니다.
• 커스텀 훅의 경우 어찌됐든 해당 컴포넌트 안에서 커스텀 훅을 호출하고, 커스텀 훅이 반환하는 함수 또는 상태를 관리해야하므로 컴포넌트 형태가 목적에 더 부합하다고 생각했습니다.

2. 추상화 정도

• 다음으로 고민했던 것은 얼마나 추상화를 할 것인가였는데, 제대로 만든 드래그 슬라이더라하면, 드래그 방향에 대한 제약이 없어야한다고 생각했습니다.
• 파라미터로서 드래그 방향을 ‘좌우’, ‘상하’, 또는 ‘사방’과 같은 식으로 특정하고 사용할 수 있게 해야했습니다.
• 그러나 현재 앱에서 필요한 것은 좌우 드래그 뿐이고, 위와 같이 하려면 컴포넌트 안에서 각 경우에 따라 좌표 계산시 분기처리가 필요했습니다.
• 당장 사용하지 않을 기능을 위해 로직을 복잡하게 만들 필요는 없다고 생각하여 우선은 좌우 드래그를 기준으로 만들었습니다.

구현하며 한 생각

1. 드래그와 클릭의 기준

• 간단히 생각했을 때 드래그는 mouseDown 후 mouseUp 하기 이전에 mouseMove를 일으키는 동작이고 클릭은 mouseMove없이 곧바로 두 동작이 이어지는 것입니다.

• 그러나 실제로 사용자가 느끼기엔 미묘한 부분이 있었습니다.

• 사용자는 클릭을 의도했지만, 마우스가 약간 밀리거나 하는 이유로 drag로 판단되는 경우가 있었습니다.

• 따라서, mouseMove에도 일정량의 threshold를 두어야한다고 생각했습니다.

  const isIntendedDrag = (event: CMouseEvent) => {
      if (!originalPos) return false;
      return Math.abs(event.clientX - originalPos) > policy.DRAG_THRESHOLD;
    };
  
    const handleMouseMove = (event: CMouseEvent) => {
      if (!originalPos) return;
      if (!isIntendedDrag(event)) return;
      setIsDragging(true);
      setSliderPos(handlePos(event.clientX - originalPos));
    };
  

  • handleMouseMove 는 기본적으로는 mouseDown 상태에서 mouseMove가 일어나면 드래그 중이라고 상태를 변경하는 역할을 하지만, 그 이전에 의도한 드래그인지 판단하는 로직을 추가했습니다.
  • isIntendedDrag 함수에서는 미리 정해둔 DRAG_THRESHOLD 를 넘는지 판단합니다.

• 위와 같은 로직을 추가하자 좀 더 사용자의 의도에 부합하는 동작이 이뤄져 ux가 향상된 것 같습니다.