[홍지윤] Sprint8

[h-zhirun]

요구사항

기본

• 스프린트 미션 5 ~ 7에 대해 typescript를 적용해주세요

심화

• any타입을 최소한으로 써주세요

주요 변경사항

• typescript 마이그레이션

멘토에게

• 마이그레이션 도중 여러 곳에서 오류가 나는 것을 보고 코드 작성자인 제가 기대하는 데이터 타입이 정확히 표현될 수 있도록 할 수 있다는 점과 이를 벗어나는 경우 컴파일 때 오류를 발견할 수 있다는 점에서 타입 스크립트의 필요성을 느꼈습니다.
• 찾아보니 any로 할당되거나 추론되는 경우 오류를 발생시키는 옵션은 strict: true에 포함되어있다고 해서 오류가 나는 부분만 타입을 지정 했습니다. 오류 수정 후 코드가 정상 작동하기만 하면 되는 걸까요?
• productId 같은 경우에는 number 타입으로 지정해야 하는데 useParams()로 사용하면 string으로 추론이 되어 오류가 나더라구요. 이런 경우에는 매번 Number()로 값을 바꾼 변수를 만들고 따로 선언 해야하는 걸까요?
• type과 interface이 확실히 구분되지 않아서 type만 썼고, 자주 사용하는 타입은 typeName.d.ts 파일로 따로 빼두었는데 이렇게 사용해도 되나요? 타입에서의 옵셔널 프로퍼티의 사용 여부도 아직 모호한 감이 있어서 오류가 날 때만 옵셔널로 지정해두었습니다..

[baeggmin]

ts 로의 마이그레이션은 너무 잘 해주신 것 같아요! 코드 상으로는 특별히 코멘트 남길게 없어서 질문 주신 사항들 하나씩 답변 남겨보겠습니다~

[baeggmin]

마이그레이션 도중 여러 곳에서 오류가 나는 것을 보고 코드 작성자인 제가 기대하는 데이터 타입이 정확히 표현될 수 있도록 할 수 있다는 점과 이를 벗어나는 경우 컴파일 때 오류를 발견할 수 있다는 점에서 타입 스크립트의 필요성을 느꼈습니다.
-> 앗 정확히 ts 의 핵심을 깨달으셨군요! 이미 ts 의 절반 이상을 이해하셨다고 봐도 무방합니당 ㅎㅎ

[baeggmin]

찾아보니 any로 할당되거나 추론되는 경우 오류를 발생시키는 옵션은 strict: true에 포함되어있다고 해서 오류가 나는 부분만 타입을 지정 했습니다. 오류 수정 후 코드가 정상 작동하기만 하면 되는 걸까요?
-> strict:true 옵션이 거의 모든 any 오류는 다 잡아주기 때문에 오류가 나는 부분에 타입을 지정하고, 그 후 코드가 정상 작동한다면 잘 수정해주신거긴 합니다. 그렇지만 ts 는 정적 타입 검사 도구이기 때문에, 오류를 수정했다고 해서 항상 런타임에서 문제가 없다는 보장은 없습니다. ts 의 목표는 타입 안정성을 제공해서 런타임 오류를 방지하는 데에 있어요.
따라서 조금 더 이상적인 접근 방식을 말씀드리자면, 단순히 ts 오류를 없애는것이 아니라, 타입의 정확성을 유지해서 '개발자의 의도대로' 코드가 동작하도록 작성해주시는게 좋습니다!

[baeggmin]

productId 같은 경우에는 number 타입으로 지정해야 하는데 useParams()로 사용하면 string으로 추론이 되어 오류가 나더라구요. 이런 경우에는 매번 Number()로 값을 바꾼 변수를 만들고 따로 선언 해야하는 걸까요?
-> 음 사실 productId가 number 타입이어야만 하는 이유는 없을 것 같아요. ProductAPI.ts 의 api 요청 함수들의 params 타입을 string 으로 수정하는건 어떨까요? 그러면 굳이 Number() 를 사용할 이유도 없을 것 같습니다!

[baeggmin]

type과 interface이 확실히 구분되지 않아서 type만 썼고, 자주 사용하는 타입은 typeName.d.ts 파일로 따로 빼두었는데 이렇게 사용해도 되나요? 타입에서의 옵셔널 프로퍼티의 사용 여부도 아직 모호한 감이 있어서 오류가 날 때만 옵셔널로 지정해두었습니다..

1. type 과 Interface 는 몇가지 문법적인 차이만 있을 뿐 거의 동일한 역할을 합니다. 따라서 type 만 사용하셔도 무방합니다. 주요한 차이점을 정리해드리자면, type은 유니언을 선언할 수 있다, interface 는 선언병합이 가능하다 정도입니다. 선언 병합은 동일한 인터페이스 이름으로 선언했을 때 하나의 인터페이스로 합쳐주는 걸 의미하는데요, 외부 라이브러리의 인터페이스에 나만의 타입을 추가하고 싶을 때 사용하면 유용한 기능입니다. 결론적으로는, 평소에는 둘 중 하나의 방식을 채택해 통일해서 사용하되, 특수한 상황이 생기면 더 유용한 방식을 선택해서 타입을 지정하면 됩니다.
2. 자주 사용하는 타입은 typeName.d.ts 로 따로 빼서 관리하시면 좋습니다!
3. 옵셔널 프로퍼티는 말 그대로 해당 프로퍼티가 반드시 필요하지 않은 경우에 사용해야 합니다. 오류가 날 때 지정한다기보다는 개발자의 의도상 옵셔널로 받아도 되는 값인지를 고려해주시면 좋을 것 같아요~