본문 바로가기

Web.d

[Typescript][React] Typescript 기본 개념 (Nomad Coders' course) / 10 Bad TS Habits

반응형

https://github.com/joohaem/prt-typescript-react

 

joohaem/prt-typescript-react

Contribute to joohaem/prt-typescript-react development by creating an account on GitHub.

github.com


Typing

- typing

 

let hello:string = "hello";
hello = 4;  //ERROR, not string

 

- return types

 

const returnStr = (name:string, age:number):string => {
  return age  //ERROR, not string return
}


- interface

 

interface IHuman {
  name:string;
  age?:number;  //optional value
  hungry:boolean;
  walking?: () => void;
}

const snupi = {
  name: "SNUPI",
  hungry: 3
}

const helloHuman = (human:IHuman) => {
  console.log(`Hello ${human.name} you are ${human.age} old`);
}

helloToHuman(snupi);
//ERROR, hungry is not boolean
//(no age is ok)

 


Set up

 npx create-react-app {파일명} --template typescript

초기 변수에 typing을 안 하면 TS7006 rule의 에러가 발생한다.
-> tsconfig.json 파일에 그에 맞는 속성인 ```"noImplicitAny": false,``` 값을 주면 에러가 해결된다.

라이브러리를 사용할 때는 @types(definitely typed; npmjs에 속한 라이브러리들이 있는 directory)를 설치한다.
-> ```npm install styled-components```하면 TS가 styled-components 라이브러리를 모른다.
-> ```npm install @types/styled-components```하면 TS가 keyframes의 모든 type을 가지게 된다
-> 사용하는 라이브러리가 @types이 없다면, tsconfig.json에 ```noImplicitAny": true```



State & Props & Event in Typescript

- state

 

//class component --> Component<props, state> typing
class App extends Component<{}, IState> {

}


- props

 

//functional component --> React.FunctionComponent<props> typing
const Number: React.FunctionComponent<IProps> = () => (

);

 


- event

 

interface IInputProps {
  value: string;
  onChange: (event: React.SyntheticEvent<HTMLInputElement>) => void;
}

export const Input: React.FunctionComponent<IInputProps> = ({
  value,
  onChange
}) => (
  <input type="text" placeholder="Name" value={value} onChange={onChange} />
);

 

render() {
  const { name } = this.state;
  return (
    <div>
      <Input value={name} onChange={this.onChange}/>
    </div>
  );
}
onChange = (event: React.SyntheticEvent<HTMLInputElement>) => {
  const {
    currentTarget: { value }
  } = event;
  this.setState({ name: value });
};

 


[퍼온글] 10 Bad TS Habits

원문은 https://startup-cto.net/10-bad-typescript-habits-to-break-this-year/ 인데

 

토스트 ui 팀에서도 똑같은걸 햇슴 어차피 머 공유 목적이긴 한데 그랫다구

 

암튼 ts 사용하며 반드시 고쳐야 할 나쁜 습관 10개가 잇다구 함

 

소개할건데 참고로 여기서 언급하는 것들은 논의된 이슈에 대해서만 하는거니가

 

머 다른 종류의 code smells가 잇을 수 잇으니 알아두삼 물론 얘네는 논외

 

 

## bad habits 1 :: not using `strict` mode

 

`tsconfig.json` 보면 다음과 같이 `strict` 모드를 사용하지 않는 경우가 잇는데

 

 

 

 

어지간해서는 이렇게 하지 말구 아래와 같이 strict mode를 설정하도록 하자

 

 

 

 

물론 strict mode에서 간혹 불편한 상황이 발생될 수 잇으나...

 

타입 체킹을 하지 않을 것이라면 왜 ts를 사용하는지 자신에게 되물어보자

 

아님 적어도 type safety를 위해 ts를 도입햇다면 반드시 strict mode를 사용하자

 

물론 첨에는 이것댐에 조오금 더 시간이 오래 걸릴 수 잇는데

 

나중에 실제로 코드를 파악하고 수정할 때 사용하지 않은 것보다 비용이 낮음

 

 

## Bad habits 2 :: Defining default values with `||`

 

기존에는 `||`를 이용해 default value를 설정했을 수 있는데

 

 

 

 

이거 말고 앞으로는 `??`를 사용하자

 

 

 

 

물론 다음과 같이 params level에서 default value를 정의해줘두 댐

 

 

 

 

근데 굳이 왜?라고 물어보면

 

`??`는 `||`와는 달리 falsy한 값이 아니라 `null`과 `undefined` 값에 대해서만 보정이 들어감

 

따라서 더욱 명확한 의미를 갖기에 실수 업이 default value operator 설정이 가능하게 된다리

 

참고로 `??`는 ts뿐만 아니라 js에서도 사용이 가능

(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing_operator)

 

 

## Bad habits 3 :: Using `any` as type

 

종종 사용하는 데이터 구조를 파악하기 힘들거나 귀찮을 때 `any` 쓸 수도 잇는데?

 

 

 

 

이거 말고 `unknown`을 사용하자 물론 파악 가능하면 되도록 그 타입을 명시하도록 하구

 

 

 

 

이유를 말해주자면, 일단 `any`는 기본적으로 모든 type checking을 무력화시키기에

 

컴파일 타입체킹 안되어서 런타임 시 오류 발생되면 찾기 힘들기 때문이삼

 

당장에야 업다 해도 뭐 하루이틀 볼 코드도 아니고 나중에 어케될지 모르니가

 

그럭다

 

 

## Bad habits 4 :: `val as SomeType`

 

바로 위에서 보면 `as`를 이용해 타입을 강제로 추론하게끔 햇는데

 

 

 

 

이 대신 type guard를 사용하자

 

 

 

 

보통 ts로 마이그레이션 하는 과정 중 `as` 사용하는 경우가 많은데 (아님말구)

 

당장에야 괜찮을지 몰라도 항상 나중이 문제니까... 개귀찮은 유지보수 비용을 최대한 낮춰야 좋겟지

 

따라서 위와 같이 type guard를 이용해 '명시적으로' 검증하도록 하자 ㅇㅅㅇ

 

 

## Bad habits 5 :: `as any` in Tests

 

Test 작성 시 인스턴스 일부 프로퍼티만 이용하는 경우 `as any` 이용하면 되는데

 

 

 

 

알겟지만 이건 별로 좋지 못한 습관이삼

 

나중에 `id`가 `user_id`로 바뀐다거나

 

`createEmailText()`가 `id` 뿐만 아니라 `email`까지 요구하도록 요구사항이 변경되면?

 

일일이 위에처럼 작성한 애들을 찾아 변경해줘야 하겟다

 

따라서 다음과 같이 재사용이 가능하게끔 해주자

 

 

 

 

이유는 머 계속 말햇듯이 비용 절감과 개피곤해지는 휴먼에러 줄이기 위함이구...

 

 

## Bad habits 6 :: Optional properties

 

프로퍼티가 잇을 수도 업을 수도 잇다면 optional로 만들곤 할텐데

 

 

 

 

물론 편하고 쉬운 방법이긴 하지만...

 

나중에 다른 사람이 `Product` 사용하기 위해서는 `Product`에 대한 이해가 선행되어야 하구

 

또 `Product` 구조가 변경되는 경우에는 optional properties를 쉽사리 건들 수 업게 될 가능성이 잇기에

 

담과 같이 '명시적으로' 구성하도록 하자

 

 

 

 

조오금 코드가 길어질 수는 잇겟지만... 이럭게 하면 컴파일 타임에서 타입체킹도 가능하구...

 

 

## Bad habits 7 :: One letter generics

 

자바에서도 종종 그러햇듯이 generic을 문자 하나로 네이밍하곤 햇을텐데?

 

 

 

 

이러지 말자구 함 ㅇㅅㅇ 왜냐면 generic type variables도 결국 변수이기 때문

 

뭐 한두개야 어렵지 않게 의미를 파악할 수 잇겟지 근데 세개네개다섯개 많아진다면?

 

애초에 그렇게 하지 않는것도 하나의 방ㅂ버이겟지만 머

 

제정신박혓다면 의미가 잇는 변수를 선언할 때 이름을 그냥 `a`나 `t` 이럭게 하는 경우는 드므니까

 

generic 역시 의미를 쉽게 파악할 수 잇도록 하자는거이삼

 

 

 

 

그럭다리

 

 

## Bad habits 8 :: Non-boolean boolean checks

 

`number`와 같이 non-boolean 값을 `boolean`처럼 사용하지 말자

 

 

 

 

`countOfNewMsg`는 `number` 타입인데 위처럼 해버리면 `0`을 구별 못하구 그냥 지나치겟지

 

 

 

 

따라서 위에처럼 실제로 `undefined`인지 검사하도록 하자는거임

 

즉 정말로 무엇을 확인할 것인지 '명확하게' 검사하자구 ㅇㅅㅇ

 

 

## Bad habits 9 :: The Bang Bang operator

 

가끔 보면 non-boolean을 `boolean`으로 변환하기 위해 `!!` 사용하곤 하는데 이러지 말자구 함 ㅇㅅㅇ

 

 

 

 

편한 것은 맞는데, `countOfNewMsg := 0` 이런 경우같이 의도치 않은 결과가 발생도리 수 잇으니가....

 

 

 

 

참고로 `!!null`, `!!''`, `!!undefined`, `!!false` 모두 `false` 반환임 ㅇㅅㅇ

 

 

## Bad habits 10 :: `!= null`

 

마지막으로... `!= null` 사용하지 말자

 

 

 

 

`!= null`은 `null`과 `undefined` 동시에 ㄱ머사하기에 편할 수는 잇어도

 

`null`은 '아직 값이 할당되지 않은 것'이구 `undefined`는 '선언되지 않은 것'이니가

 

이 둘 역시 명확하게 구분하도록 하자 ㅇㅅㅇ

 

 

 

 

암튼머 이럭게까지 귀찮게 할 필요가 잇느냐? 근데 안그럴거면 ts왜씀?

 

프로젝트가 작구, 모든 side-effects를 완벽하게 파악하고 잇으며, 혼자 개발한다면야 상관업는데

 

현업은 지속적으로 피쳐가 추가되고 유지보수되구 여럿이서 개발하는 경우가 대부분이니가

 

우리는 최대한 비용을 낮추는 방향으로 개발해야 하니가 ㅇㅅㅇ

 

당장에 귀찮고 시간업다구 이런 것들을 하나 둘 씩 무시해가다보면 자신도 모르게 어느순간 스파게티가 되어버릴것이삼

 

결과야 뻔하지머 TypeError 막생기거나, side-effects 무서워서 건들지도 못하거나, 아예 리팩터링도 불가능할 정도로 섞여버려서

 

프로젝트를 갈아엎어야 한다거나... 조금 극단적이긴 하지만 ㅇㅅㅇ...

 

암튼 ts를 쓰고자 햇으면.... 최대한 명확하게 하자는 그런 아티클이엇슴.... 좃바스크립트 자유분방해서 ts 쓰는거일테니가...

반응형