Portfolio

아이템 38

[동호] @ts-expect-error라는 것이 또 있더라구요.

@ts-ignore는 코드에 에러가 있든 없든 그 다음 코드의 에러를 무시합니다.

@ts-expect-error는 코드에 에러가 있으면 무시하고, 없으면 주석에 에러를 표시합니다.

아이템 40

[동호] noImplicitAny 관련 설명도 있었지 않나요?

[효리] noImplicitAny 가 true일 때, 타입 진화가 된다고 합니다.

아이템 42


interface Foo {
  foo: string
}
interface Bar {
  bar: string
}
declare const foo: Foo
let barAny = foo as any as Bar
let barUnk = foo as unknown as Bar

[효리] 두 개의 단언문을 분리할 때 unknown은 오류를 발생시키므로 unknown을 사용하자는데, 두 개의 단언문을 분리한다는 게 무슨 뜻일까요?

[태호] 제가 생각하기에, Bar 인터페이스의 bar가 string 타입이잖아요. 이중 단언문으로 as가 중첩이 되어 있어서 (as를 하나 떼는게) 분리한다는 말인 것 같고, unknown은 unknown과 any타입에만 할당이 가능하니까 Bar에 할당할 수 없다는 뜻 아닐까요?

[재희] 책에 보니까 “기능적으로는 동일하지만, 추후에 두 단언문을 분리해야할 때 unknown이 더 안전하다”고 되어 있는데, 나중에 저 as 체인(이중 단언문)이 베스트는 아니니까 as Bar를 뗀다고 쳤을 때 any보다 unknown이 더 좋다는 것 같아요.

[동호] 제네릭 나오는 부분 한번 더 설명해주실 수 있나요? 책에서는 unknown 대신에 제네릭 매개변수를 사용하는 경우가 있다고 하는 부분이요.

[재희] 제네릭으로 any처럼 쓸 거면 unknown을 반환하는 게 낫다는 소리 같습니다.

[동호] 한 번만 더 말씀해주실래요?

[재희] 제네릭을 단언하듯이 쓰느니, unknown을 반환해서 쓰는 게 더 낫다는 소리인 것 같습니다.

[진욱] 저도 그렇게 이해했습니다.

[효리] 책에 보면 아래와 같은 코드인데 제네릭으로 바꾼 거네요.


function safeParseYAML(yaml: string): unknown {
  return parseYAML(yaml)
}


function safeParseYAML<T>(yaml:string): T {
	return parseYAML(yaml)
}

[동호] 음… 아래처럼 쓰지 말고 위처럼 사용하라?

[효리] 개발자가 직접 좁히게 해서 사용하라는 의미인 것 같아요.

아이템 43

[효리] 전역적으로 데이터를 사용할 때의 대책으로 인터페이스의 보강을 쓰는 부분의 문제점으로 꼽힌 “웹 페이지 내의 HTML 엘리먼트를 조작할 때, 어떤 엘리먼트는 속성이 있고 어떤 엘리먼트는 없다면 문제가 된다.” 이 부분에 대해서 설명해주실 분?

[진욱] 저는 저 문장이 와닿진 않았고, HTML 엘리먼트가 아니라 “어떤 타입이 있는데 이 타입을 전역적으로 확장해서 사용하면 그렇게밖에 사용을 못하니까 문제가 될 수 있다.”라고 이해했어요.

[효리] 원래 나누어서 코드를 작성했는데, 한쪽에서만 사용하려고 전역적으로 바꾸게 되면 다른 코드에서도 문제가 생겨서 다 고쳐야 되니 그게 곤란한 상황이 된다? 이런 얘기일까요?

[진욱] 그런 식으로 이해했던 것 같아요.

아이템 44

[효리] 이중 단언문에 대해서 제가 따로 찾아봤는데, 혼란스러운 점이 있어요.

interface A { propA: number }

interface B { propB: string }

const value: A = { propA: 42 }

// 이중 단언문을 사용하지 않을 때 에러 발생 const valueAsB: B = value as unknown as B


interface A {
  propA: number
}

interface B {
  propB: string
}

const value: A = { propA: 42 }

// 이중 단언문을 사용하지 않을 때 에러 발생
const valueAsB: B = value as unknown as B

여기서 as unknown이 없다고 생각했을 때 왜 에러가 날까요?

[진욱] 이거 저번에 말씀드리려고 했는데 깜빡했습니다. A as B 이렇게 있으면, A가 B의 부분 집합이거나 B가 A의 부분 집합일 때만 단언문을 쓸 수 있는 것 같아요. 저는 그렇게 이해했습니다.

[효리] 아 그런데 any는 그걸 다 상쇄시키니까?

[진욱] 맞는지는 모르겠습니다.

[동호] 알아보기.

💡

이중 단언문, 단언문에 대해서 조금 더 알아보자.

오늘 아이템들에 대해서 궁금한 점이나 하고 싶은 얘기

[동호] 저 unknown을 쓴다는 것이 결국 나중에 타입 단언을 하던 좁혀서 쓰던 나중에 해야 하는 숙제를 검사해준다는 걸까요?

[진욱] 적절한 비유 같아요.

[동호] 숙제를 나중으로 좀 미루는 용도로 unknown을 쓰는 걸까요?

[재희] any보다 unknown을 쓸 수 있으면 써야 하는 이유는 unknown이 어떤 타입으로 할당을 해야 쓸 수 있는… 그렇죠 숙제를 남기는 거라서, 어떤 부분에서 타입 가드를 두어야 하는지 나타내준다? 그런 목적이 있는 것 같아요. any를 쓰면 그냥 돼버리고, 오염될 수 있는데 unknown은 사용하는 곳에서 처리를 해주어야 하니까.

[효리] 그렇습니다.

[동호] 음.. 그러니 비슷한거죠? 숙제 미루기와?

[재희] 그렇습니다. 근데 이제 any로 미루는 거냐 unknown으로 미루는 거냐의 차이가 뭔지 알아야…

[동호] any는 숙제를 미루는 게 아니죠.

[재희] 어 그러면 어떤 건가요?

[진욱] 답지 베끼는 거죠 ㅋㅋ

[동호] 네 ㅋㅋ 답지 베끼는 거죠. 숙제를 좀 미룰 수 밖에 없는 상황일 때는 좀 미루고, 중요한 것 부터 먼저 하고 나중에 정말 필요할 때 숙제를 하겠다고 약속을 하는 것 같습니다.

동호 기록