React Query에서 Non-null Assertion Operator 사용하기 좋은 방법일까?

2024. 2. 18. 16:38·Frontend/Dev Practice
728x90
SMALL

Non-null Assertion Operator란 무엇인가?

TypeScript에서 Non-null assertion operator (!)는 컴파일러에게 어떤 값이 null이나 undefined가 아님을 단언하는 방식입니다. 이 연산자는 변수 뒤에 !를 붙여 사용하며, 이를 통해 TypeScript의 엄격한 null 검사(strict null checks)를 우회할 수 있습니다. 이는 개발자가 해당 변수가 절대 null이나 undefined가 아닐 것이라는 확신이 있을 때 유용합니다.

 

간단한 사용예시

let myVar: string | null = "Hello, TypeScript!";

// myVar이 null이 아님을 단언하고 사용
console.log(myVar!.toUpperCase());

 

위 예제에서 변수 myVar는 string 타입 또는 null 타입을 가질 수 있습니다. toUpperCase() 메서드를 안전하게 사용하기 위해 myVar 뒤에 !를 붙여 null이 아님을 단언합니다.

 

React Query에서 Non-null Assertion Operator 사용하기 좋은 방법일까?

문제 상황:

다음과 같은 상황에서 어떤 식으로 optional 에러를 처리할 수 있을까요?

const Books: React.FC<BooksProps> = ({ bookId }) => {
  const { data } = useQuery({
    queryKey: ['books', bookId],
    queryFn: async () => {
      const response = await fetch(`https://example.com/books/${bookId}`); // Error: Invalid type "string | undefined" of template literal expression.
      const data = await response.json();
      return data;
    },
    enabled: Boolean(bookId),
  });

  return <div>{JSON.stringify(data)}</div>;
};

 

상황설명:

Books 컴포넌트에서, bookId는 optional prop으로 받습니다. 이 때문에 TypeScript는 bookId가 undefined일 수 있다고 판단합니다. 그러나, useQuery의 enabled 옵션으로 인해 bookId가 실제로는 항상 존재할 때만 쿼리가 실행되는 구조입니다.

 

어떤 식으로 해결이 가능할까?

1. bookId!는 bookId가 null이나 undefined가 아님을 단언합니다. 이 방식은 간결하고 직관적이지만, 개발자가 실수로 null이나 undefined가 될 수 있는 값에 대해 이 연산자를 사용하면 런타임 에러가 발생할 위험이 있습니다.

2. bookId ?? ''사용이 있습니다. 이는 bookId가 undefined나 null일 경우, 빈 문자열을 대신 사용하라는 의미입니다. 이 방식은 타입 안정성을 높이며, 실수로 인한 에러를 줄일 수 있는 장점이 있습니다.

 

 

글쓴이가 생각하기에 좋은 방법은..

개발자 경험과 사용성을 고려할 때, Non-null Assertion Operator의 사용은 가능한 한 피하는 것이 좋을 것 같습니다. 이는 코드의 안정성을 위해 타입 시스템의 이점을 최대한 활용하는 것이 중요하기 때문입니다. 대신, optional chaining (?.)과 nullish coalescing operator (??)를 조합하여 사용하는 것을 추천합니다. 이 방식은 코드의 안전성을 보장하면서도, 의도치 않은 null이나 undefined 처리로 인한 오류를 방지할 수 있습니다.

예를 들어, bookId가 undefined일 가능성이 있을 때, fetch 호출을 수행하기 전에 이를 확인하고 대체 값을 제공하는 방식이 있습니다. 이렇게 하면, 강제적으로 값의 존재를 단언하기보다는, 안전하게 값의 존재를 확인하고 처리할 수 있습니다.

const response = await fetch(`https://example.com/books/${bookId ?? ''}`);

 

결론적으로, 타입 안전성과 개발자 경험 모두를 고려할 때, Non-null Assertion Operator (!) 대신 안전한 타입 처리 방법을 선택하는 것이 좋은 것 같습니다. 이는 코드의 신뢰성을 높이고, 잠재적인 에러를 줄이며, 전반적인 개발 경험을 향상시킬 것입니다.

React Query와 같은 현대적인 라이브러리를 사용할 때 이러한 접근 방식이 특히 중요합니다. 왜냐하면 이를 통해 애플리케이션의 데이터 관리 로직을 더욱 견고하고 안전하게 만들 수 있기 때문입니다.

 

사용하지 말아야 한다는 의견

Non-null assertion operator의 사용은 주의를 요합니다. 이 연산자를 사용하면 TypeScript의 타입 체크를 우회할 수 있으므로, 런타임에 예상치 못한 에러가 발생할 가능성이 있습니다. 특히, 개발자의 판단이 틀렸을 경우 null이나 undefined에 접근하려 하면서 오류가 발생할 수 있습니다.

따라서, 가능한 한 !의 사용을 피하고, 대신 조건부 렌더링이나 optional chaining(?.), nullish coalescing operator(??) 등을 사용하여 null과 undefined를 처리하는 것이 좋습니다. 예를 들어, bookId ?? ''는 bookId가 undefined일 때 빈 문자열을 사용하라는 의미이며, 이는 타입 안정성을 유지하면서도 예외적인 상황을 명확하게 처리할 수 있는 방법입니다.

결론적으로, Non-null assertion operator는 그 사용이 필요한 상황에서 매우 유용할 수 있으나, 이를 사용할 때는 해당 값이 정말로 null이나 undefined가 아닐 것이라는 확신이 있을 때만 사용해야 합니다. 그리고 가능하다면, 보다 안전한 TypeScript의 기능을 사용하여 예외 상황을 처리하는 것이 좋습니다.

저작자표시 (새창열림)

'Frontend > Dev Practice' 카테고리의 다른 글

주석을 언제 작성해야 할까?  (3) 2024.10.27
빈 태그 사용을 피해야 하는 이유  (0) 2024.03.16
똑똑한 컴포넌트, 어디까지가 좋을까?  (0) 2024.01.26
왜 컴포넌트 안에서 new QueryClient 사용을 지양해야 할까?  (0) 2023.11.24
협업하기 위한 CSS 컨벤션  (0) 2023.09.18
'Frontend/Dev Practice' 카테고리의 다른 글
  • 주석을 언제 작성해야 할까?
  • 빈 태그 사용을 피해야 하는 이유
  • 똑똑한 컴포넌트, 어디까지가 좋을까?
  • 왜 컴포넌트 안에서 new QueryClient 사용을 지양해야 할까?
끄적끄적 개발자
끄적끄적 개발자
생각나는 대로 끄적끄적, 코드 노트
  • 끄적끄적 개발자
    코딩을 끄적끄적
    끄적끄적 개발자
  • 전체
    오늘
    어제
    • 분류 전체보기 (47)
      • Frontend (43)
        • Tech Insight (24)
        • Dev Practice (7)
        • React Hook Form (4)
        • Module Federation (3)
        • Clone coding (5)
      • UIUX (2)
      • ETC (2)
  • 인기 글

  • 태그

    개발/정보
    개발/기술
    개발/코드품질
    회고
    UI/UX
    개발/언어
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
끄적끄적 개발자
React Query에서 Non-null Assertion Operator 사용하기 좋은 방법일까?
상단으로

티스토리툴바