feat: add device type detect utilities

[prgmr99]

Description

• device 타입을 감지하는 유틸함수를 추가합니다.
• 총 5개의 값(isMobile, isTablet, isDesktop, isIOS, isAndroid)을 제공합니다.

[klmhyeonwoo]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	78.1%	214 / 274
🔵	Statements	78.1%	214 / 274
🔵	Functions	95.45%	21 / 22
🔵	Branches	91.39%	85 / 93

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
package/deviceUtil/getDevice/index.ts	100%	100%	100%	100%

Generated in workflow #69 for commit a427cfb by the Vitest Coverage Report Action

[prgmr99]

사실 이 부분을 고려를 할지 말지 고민을 많이 했었습니다.

레이어를 생각했을 때는 고려를 하지 않아도 된다고 생각했지만, 범용성을 고려했을 때 필요하다고 생각했습니다.

구현 후에 조금 더 고민을 해보니, 약간의 문제가 있습니다.
모바일 사용자가 SSR 환경에 접근한 경우, hydration 과정이 끝난 후에,
useEffect로 마운트된 후에 getDevice를 호출하지 않는다면, isMobile은 계속 false로 남아있습니다.

// 예시
export const useDevice = (): DeviceInfo => {
  // 예시로 useState을 사용했습니다. 
  // const { isMobile } = deviceUtil.getDevice(); 원래는 이런 방식으로 사용하는 것을 생각했습니다.  
  const [deviceInfo, setDeviceInfo] = useState<DeviceInfo>(getDevice());

  // 클라이언트에서 마운트된 후에만 실제 디바이스 정보로 업데이트
  // 이 과정이 없다면, SSR 환경에서는 isMobile이 계속 false인 상태로 남아있을 듯 합니다. 
  useEffect(() => {
    setDeviceInfo(getDevice());
  }, []);

  return deviceInfo;
};

그래서 다시 생각을 해보니, SSR 상황을 배제하고 클라이언트 상황만을 적용하는게 좋을 것 같다고 생각하는데
어떻게 생각하시나요..??

어려운데,, 재밌네요ㅎㅎ

@klmhyeonwoo

[klmhyeonwoo]

음 저도 동의합니다! 저희는 유틸 함수 라이브러리를 만들기에 window 객체를 파악하지 못하는 SSR 상황까지 커버하기에는 조금 힘들 수 있을 것 같다는 생각이 들어요!

[prgmr99]

넵!! 그러면 해당 예외처리는 제거하겠습니다..!!

[klmhyeonwoo]

굿입니다! 너무 잘쓸 것 같아요!!

[klmhyeonwoo]

음 저도 동의합니다! 저희는 유틸 함수 라이브러리를 만들기에 window 객체를 파악하지 못하는 SSR 상황까지 커버하기에는 조금 힘들 수 있을 것 같다는 생각이 들어요!