구글과 스택 오버플로우는 개발자와 뗄레야 뗄 수가 없는 관계인 것을 모두가 알 것이다.
그 동안은 문제가 발생하면 구글링을 열심히 하면서 제발 나와 같은 케이스의 오류를 질문하거나 해결한 사람의 포스팅이 걸리길 골백번 기도하며 넘쳐나는 정보의 바다 속에서 무사히 내가 원하는 글이 나오기를 기도했었는데 작업을 하다가 궁금한 게 생겨 검색을 했는데 너무 특정한 케이스인지라 내가 원하는 정보는 나오지 않고, 꽤나 오랫동안 간간히 보였던 컴파일 에러가 갑자기 눈엣가시처럼 거슬려서 고민을 하다가 용기를 내 스택 오버플로우의 회원가입 버튼을 누르고...
첫 글을 작성했다.
질문의 예시로는 lodash 라이브러리의 isNull 함수와 React-native의 ScrollView 컴포넌트의 타입이 사용되었다.
react 컴포넌트 내부에서 useMemo, useCallback 함수 또는 변수 상수로 특정 조건을 통과하는 지를 미리 체크해서 중복된 불필요한 코드를 지우고자 할 때가 있는데, 간혹 타입스크립트에서는 boolean 타입을 리턴하는 특정 함수나 상수를 호출하는 값으로 그 조건이 이미 해당하는 경우에 렌더링 할 수 있는 코드를 작성했지만 컴파일 에러가 발생하는 경우가 더러 있었다.
실제 근접한 라인에 컴파일 에러를 해결할 수 있는 조건을 써야만 원하는 컴파일 에러가 수정되는 것을 종종 겪었던 경험이 있었고, 마침 useRef를 통해 작업을 하던 도중 isNull 함수를 사용하는 과정에서 해당 문제가 재발생해 질문을 게시했던 것이었다.
답변이 곧 달렸는데,
예시로 들었던 코드 속에서 내 조건은 isNull(scrollViewRef) 의 값만 체크한 뒤 다음 수행문에서 scrollViewRef.current를 쓰고 있는 라인에 컴파일 에러가 발생했던 것인데, 이것은 ScrollViewRef 객체 타입의 정의 자체가 current 키(필드)가 null 인 경우가 union타입으로 포함되어 있기 때문에 isNull 함수를 이용해 컴파일을 잡으려면 scrollViewRef.current 까지를 체크했어야 했다.
정말 타입스크립트의 근본적인 타입 컴파일 에러 중 하나에 불과했고, 이것은
const scrollViewRef = useRef<ScrollView | null>(null)
scrollViewRef 가 null일 조건은 useRef가 선언된 직후, scrollView 컴포넌트의 주소값이 저장되기 직전에만 존재할 것이라는 안일함으로부터 파생된 질문이었던 것이다.
react-native의 ScrollView 타입의 라이브러리 레퍼런스 코드를 찾아 가 current의 타입을 한 번 파악해보았으면 불필요했던 질문이었다는 생각이 들어 반성아닌 반성을 했다.
그동안 그렇게 어려워했고 또 해결했던 다른 문제들은 몇날 며칠 고생하면서도 질문글 올릴 생각 하나를 못했는데 그래도 이 질문 글 덕에 조금 더 적극적으로 궁금증과 문제 해결을 시도했던 것 같아, 문제 해결을 위한 새로운 발돋움을 한 게 아닐까 하고 작게나마 내 자신을 위로하며 생각해본다.
'Today I Learned' 카테고리의 다른 글
[TIL] 2021.05.16 - 부제 : LRU 알고리즘, 버그의 늪, TDD의 필요성 (0) | 2021.05.16 |
---|---|
TIL 2021.03.29 ~ 04.02 (0) | 2021.04.03 |
TIL 2021.03.22 ~ 03.26 (0) | 2021.03.26 |
TIL 겸 일기 / 2021.03.13 (0) | 2021.03.14 |
[프로젝트 리팩토링] 2020.02.10 리덕스에 투자한 핫식스 700ml (0) | 2021.02.10 |