전체 글 (157) 썸네일형 리스트형 Effective Typescript - 40 - 함수 안으로 타입 단언문 감추기 함수를 작성하다 보면, 외부로 드러난 타입 정의는 간단하지만 내부 로직이 복잡해서 안전한 타입으로 구현하기 어려운 경우가 많습니다. 함수의 모든 부분을 안전한 타입으로 구현하는 것이 이상적이지만, 불필요한 예외 상황까지 고려해 가며 타입 정보를 힘들게 구성할 필요는 없습니다. 함수 내부에는 타입 단언을 사용하고 함수 외부로 드러나는 타입 정의를 정확히 명시하는 정도로 타협하는 것이 좋습니다. 프로젝트 전반에 위험한 타입 단언문이 드러나 있는 것 보다는 제대로 타입이 정의된 함수 안으로 타입 단언문을 감추는 것이 더 좋은 설계입니다. declare function shallowEqual(a: any, b: any): boolean; function cacheList(fn: T): T{ let lastArg.. Effective Typescript - 39 - any를 구체적으로 변형해서 사용하기 일반적인 상황에서는 any 보다 더 구체적으로 타입을 표현할 수 있는 상황이 높다. 따라서 더 구체적인 타입을 찾아 타입 안정성을 높이도록 해야한다. 예를 들어, any 타입의 값을 그대로 정규식이나 함수에 넣는 것은 권장되지 않는다. function getLenBad(array: any) { // 비추 return array.length; } function getLen(array: any[]) { // 좀더 안전 return array.length; } 알수 없는 구조의 객체를 파라메터로 받는 함수의 구현시에도 any보다 좀더 구체적인 타입을 명시할 수 있다. function getSomeObjKeysBad(obj: any) { // 비추 return Object.keys(obj); } functio.. Effective Typescript - 38 - any 타입은 가능한 좁은 범위에서만 사용하기 아래 예제는 함수 호출 시 any로 강제로 변환해야 하는 경우, any를 가능한 좁은 범위 내에서 사용하기 위한 방법을 설명한다. interface Foo { _brand: 'foo' } interface Bar { _brand: 'bar' } function processBar(b: Bar){ console.log(b); } function expressionReturningFoo(): Foo { /** */ return {_brand: 'foo'}; } function f1(){ const x: any = expressionReturningFoo(); // 비추 processBar(x) } function f2(){ const x = expressionReturningFoo(); processBar(.. Effective Typescript - 37 - 공식 명칭(nominal typing)에는 상표를 붙이기 구조적 타이핑의 특성 때문에 가끔 코드가 의도하지 않은 결과를 낼 수 있습니다. 아래의 예제가 바로 그러한 상황을 표현하고 있습니다. interface Vector2D { x: number; y: number; }; function clacNorm(p: Vector2D){ return Math.sqrt(p.x * p.x + p.y * p.y); } clacNorm({x: 3, y: 4}); // 정상 결과 5 const vec3D = {x : 3, y: 4, z: 1}; clacNorm(vec3D); // 정상 결과 5 // 구조적 타이핑 관점에서는 이상이 없는 것이지만 수학적 결과를 기대했다면 오류이다. clacNorm 함수가 3차원 벡터를 허용하지 않게 하려면 공식 명칭(nominal typing)을.. Effective Typescript - 36 - 해당 분야의 용어로 타입 이름 짓기 * 가독성을 높이고, 추상화 수준을 높히기 위해서 해당 분야의 용어를 사용해서 타입 이름을 지정해야한다. * 같은 의미에 다른 이름을 붙이면 안된다. 특별한 의미가 있을 때만 용어를 구분해야 한다. Effective Typescript - 35 - 데이터가 아닌, API와 명세를 보고 타입 만들기 * 코드의 세밀한 부분 까지 타입 안정성을 얻기 위해 API 또는 데이터 형식에 대한 타입 생성을 고려해야한다. * 데이터에 드러나지 않는 예외적인 경우들이 문제가 될 수 있으니 데이터를 보고 타입 생성하기 보다는 명세나 API를 참고하여 타입 설계를 하는 것이 좋다. Effective Typescript - 34 - 부정확한 타입보다는 미완성 타입을 사용하기 타입 선언을 작성하다 보면 코드의 동작을 좀 더 구체적으로 또는 덜 구체적으로 모델링하게 되는 상황을 맞닥뜨리게 됩니다. 일반적으로 타입이 구체적일수록 버그를 더 많이 잡아내고 타입스크립드 언어 지원을 더욱 많이 받습니다. 하지만, 타입을 정말하게 하는 과정은 신중해야 합니다. 타입을 정밀하게 하는 작업 자체가 올바르지 않으면 타입이 없는 것 보다 못한 결과를 불러오기 때문입니다. * 타입을 정확하게 모델링 하지 못하면, 부정확하게 모델링 하지 말아야함. * any와 unknown을 구별할 줄 알아야함. Effective Typescript - 33 - string 타입보다 더 구체적인 타입 사용하기 string 타입은 매우 넓은 범위를 가집니다. 따라서 string 타입으로 변수를 선언하려 한다면, 좀 더 구체적이고 좁은 타입이 더 적절하지 않은지 고민이 필요합니다. // 비추 interface Album { artist: string; title: string; release: string; //YYYY-MM-DD recordingType: string; // 예를 들어 "live" "studio" } // 추천 type RecordingType = "studio" | "live" // interface AlbumFix { artist: string; title: string; release: Date; recordingType : RecordingType } 위와 같이 추천 방식을 이용해 타입의.. 이전 1 2 3 4 5 6 7 8 ··· 20 다음