Bugtype

현재 팀에서는 typescript를 사용하지 않아 매우 불편하다. typescript 도입하고 싶다고 하였지만, 여러번 반려당했다. 이유를 들어보면 어느정도 이해는 되긴한다. 그래서 나는 처음으로 typescript 없이 오직 javacsript 만으로 코딩을 하기 시작하였다. 여러 불편함을 너무 발견하였고, tight하게 타입을 정의하기보다는 loose하게 작업하자고 생각하였다. 그래서 혼자서 작업을 하고 있다. 현재 내가하는 목표는 prmitive type을 넣기보다는 property(object key etc.)를 추론할 수 있도록 타입을 넣고 있다. redux를 사용하게 되면 아래처럼 RootState를 import해서 많이 사용할 것이다. 이 코드의 문제점은 useSelector를 사용하는 곳은..

4.5 Beta type GetChars = S extends `${infer Char}${infer Rest}` ? Char | GetChars : never; 참고 https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/

1. 먼저 tsconfig에 path 셋팅을 한다. // tsconfig.json { "compilerOptions": { "baseUrl": "./src", "paths": { "@components/*": ["components/*"], } } } 2. storybook 셋팅에서 TsconfigPathsPlugin를 추가해준다. // .storybook/main.js const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin') module.exports = { webpackFinal: async (config) => { config.resolve.plugins.push(new TsconfigPathsPlugin({})); r..

Optional chaining 은 prettier 1.19.0 이상부터 지원하므로 prettier 버전을 확인하도록 하자.

interface Test { a: string; b: number; c: boolean; } type OmitA = Omit; // Equivalent to: {b: number, c: boolean} type OmitAB = Omit; // Equivalent to: {c: boolean} const a: OmitA = { a: 'aa', b: 1, c: true } const b: OmitAB = { a: 'aa', b: 1, c: true } Omit 은 optional으로 된 prop이 사라지는 버그가 있었는데 3.5에서 패치가 되었다. interface Test { a?: string; b?: number; c?: boolean; } type OmitA = Omit; // Equivalent ..

1. object key 받아오기 interface People { sex: 'M' | 'W'; age: Number; } function add(obj: T, key: U) { console.log(obj); } const p: People = { sex: 'M', age: 10 }; add(p,'age')

[1,2,3] + [4,5,6] // 1,2,34,5,6 JS에서는 + 연산자가 되는 것은 Number, String 뿐이다. []는 둘다 아니고 Array이므로 js에서 string으로 바꾼다. [1,2,3].toString() + [4,5,6].toString() // 1,2,34,5,6

// case 1 true == []; // -> false true == ![]; // -> false // case 2 false == []; // -> true false == ![]; // -> true 왜 위처럼 나올까??? 어째서 같지??? 여기서는 저번 설명에서 말한 것 처럼 JS에서는 빈배열은 숫자로 강제 변환하는 것을 이용해서 이해해야 한다. 2019/10/20 - [Javascript/WTF] - [WTF JS] 1. [] == ![] 는 true 그럼 이제 case 1을 먼저 보자 // case 1 1. true == []; // -> false 2. true == ![]; // -> false ==> 1 true == []; // Boolean, Array true == 0; // ..

const a = '32' // '32' const b = +a // 32 parseInt 보다 좋은 장점은 null일 경우에 safe하게 할 수 있습니다. 위 처럼 null에 대해서 0이 나오기에 우리가 어떠한 연산시 안전하게 할 수 있습니다. 예) hab = 100 + +b ( b가 null일 경우 0으로 처리, parseInt시 에러발생 ) parseInt만 쓰지 말고 +도 써보는 것은 어떤가요? - 협업에서는 가독성이 중요하기에 parseInt, parseFloat가 더 좋을수도 있습니다. 하지만 실무에서는 const result = a || 0 위와 같은 형태를 많이 사용합니다.

1. WTF [] == ![] // true 왓더퍽!!! 왜 true가 나와 2. 이유 이 현상을 이해하기 위해서는 The abstract equality operator 에 대해서 알아야 한다. == 는 추상적인 비교를 하고 ===는 엄격한 비교를 한다고 보며 된다. == 를 통해서 비교를 할때, JS에서는 서로 타입을 같게해서 비교한다. 예) 1 == '1' / 왼쪽은 숫자형, 오른쪽은 문자형이다. 서로 타입이 다르기에 JS는 서로 타입을 같게 만든다. 어디 결과를 볼까? 1 == '1' // 왼쪽 타입: Number, 오른쪽 타입: string 1 == 1 // 왼쪽 타입: Number, 오른쪽 타입: Number true // 비교 위에 같은 원리로 인해서 [] == ![] 는 true가 나오는 ..