104%

Unknown과 any 두 타입 모두 타입을 지정하기 애매할때 사용한다. 두 타입의 차이점은 뭔지 궁금해서 찾아보았다. 아래 예시를 보자. function prettyPrint(x: unknown): string { if (Array.isArray(x)) { return "[" + x.map(prettyPrint).join(", ") + "]" } if (typeof x === "string") { return `"${x}"` } if (typeof x === "number") { return String(x) } return "etc." } x라는 parameter는 unknown타입이다. 따라서 x에는 모든 타입이 올 수 있다. 그리고 나서 함수 내부에서 x의 타입을 좁혀서 사용하면 된다. 물론 x가..

위 그림에서 never는 아주 작은 점, unknown은 전체를 포함하고 있다는것을 잘 기억하자. unknown 다른 모든 타입들의 슈퍼셋이다. 모든 타입들은 unknown타입이다. never 다른 모든 타입들의 서브셋이다. 가장 최하위 개념의 타입이다. 따라서, 그 어떤 다른 타입들도 never타입일 수 없다. never는 never그 자체다. T | never ⇒ T never는 그 어떤 타입도 아니기 때문에 union을 하더라도 그대로다. T & unknown ⇒ T unknown은 모든 타입들의 superset이기 때문에 unknown과 어떤 타입 T를 교집합하면 그대로 T가 나온다. never로 타입 추론 예외를 제거하자. type Arguments = T extends (...args: inf..

// 에러를 던지기 때문에 함수가 절대 어떤값도 리턴하지 않는다. function error(message: string): never { throw new Error(message); } // 위 error함수의 리턴값으로 추론된 타입은 never이다. function fail() { return error("Something failed"); } // never는 함수에서 그 어떤값도 리턴되지 않을것임을 명시한다. function infiniteLoop(): never { while (true) { } } never 타입 변수에는 그 어떤값도 할당이 불가능하다. // never형 변수 neverVar에는 null도 할당할 수 없다. let neverVar: never = null;

Typography에 유니온 타입을 지정했는데 prettier에 의해서 자동으로 개행되면서 파일이 너무 길어지는 현상이 생겨서 타입을 분리하려고 했다. 근데 외부에서 import된 타입을 에디터상에서는 잘 인식을 하는데 문제는 스토리북 docs 애드온에서 props가 잘 표시 되지 않는 문제가 있었다. 여기에 저 위에 유니온 타입 전부 표시되어야 하는데, any로 표시해버린다. 원인 현재 스토리북 5.3 버전을 사용하고 있고 react-docgen-typescript-loader를 통해 타입스크립트로 작성된 리액트 컴포넌트의 interface에 정의된 props를 스토리북의 props table로 만들어주고 있다. 문제는 외부에서 import된 타입은 이 친구가 제대로 해석을 못하는 버그가 있는것같다. ..

스토리북 관련 작업을 하던 도중 The base Typescript configuration uses babel-loader for Typescript transpilation, and optionally fork-ts-checker-webpack-plugin for checking. 라는 문장을 만났는데 fork-ts-checker-webpack-plugin이라는게 무슨 역할을 하는건지 궁금해서 정리합니다. Fork TS Checker Webpack Plugin typescript의 타입을 분리된 프로세스에서 체크해주는 웹팩 플러그인입니다. 만들어진 이유 웹팩이 타입스크립트 파일을 만나면 그 파일을 해석하기 위해서 첫번째로 로더가 필요합니다. awesome-typescript-loader와 Checke..

.eslintrc.js const path = require('path'); module.exports = { /** eslint는 자바스크립트만 해석할 수 있다. eslint가 타입스크립트를 해석 할수 있게끔 parser를 지정해주자. */ parser: '@typescript-eslint/parser', plugins: [ '@typescript-eslint', // 타입스크립트 문법이 들어있다. 'react' // 리액트 문법이 들어있다. ], env: { browser: true, // 브라우저 환경에서 eslint를 사용하겠다. }, extends: [ // @typescript-eslint/eslint-plugin에서 추천하는 규칙들로 타입스크립트 파일을 검사하겠다. 'plugin:@types..

interface 타입과 객체 자체에 대한 type 별칭은 많은 점이 비슷하지만, type 별칭보다 더 많은 것을 할 수 있기에 interface를 사용하는 것을 일반적으로 권장합니다. interface는 같은 이름으로 여러 번 선언을 해도 컴파일 시점에서 합쳐지기 때문에 확장성이 좋다. 따라서 일반적으로는 interface를 사용하고 union, tuple 등이 필요한 경우에만 type 별칭을 사용하라는 TypeScript Handbook의 내용은 현재에도 유효하다. -> 예를들어, A.tsx 파일에서 interface test { str1: '1' } B.tsx 파일에서 interface test { str2: '2' } 똑같은 이름의 인터페이스를 중복으로 선언하면 프로젝트가 컴파일 될때 아래와 같이..