[11일차] <객체 리터럴>, <타입 좁히기 - 식별할 수 있는 유니온>, <Exhaustiveness Checking으로 정확한 타입 분기 유지하기>

[xeunnie]

[11일차] 키워드 및 질문

[모던 자바스크립트 Deep Dive]

<10장 객체 리터럴>

1. 객체란?
2. 객체 리터럴에 의한 객체 생성
3. 프로퍼티
4. 메서드
5. 프로퍼티 접근
6. 프로퍼티 값 갱신
7. 프로퍼티 동적 생성
8. 프로퍼티 삭제
9. ES6에서 추가된 객체 리터럴의 확장 기능

[우아한 타입스크립트 with 리액트]

<4.3 타입 좁히기 - 식별할 수 있는 유니온>

1. 에러 정의하기
2. 식별할 수 있는 유니온
3. 식별할 수 있는 유니온의 판별자 선정

<4.4 Exhaustiveness Checking으로 정확한 타입 분기 유지하기>

1. 상품권

[Stella-516]

<모던 자바스크립트 딥다이브>
-키워드
원시값
객체
프로퍼티
메서드

Q. 프로퍼티와 메서드의 차이가 무엇인가요?

<우아한 타입스크립트>
-키워드
에러 정의하기
유니온 타입
Exhaustiveness Checking

Q. 식별할 수 있는 유니온을 사용할 때 주의할 점?

[xeunnie]

Q1. 프로퍼티와 메서드의 차이가 무엇인가요?

A1.

• 프로퍼티는 객체의 **속성(데이터)**을 저장하는 키-값 쌍입니다.
• 메서드는 **객체의 동작(함수)**을 저장하는 프로퍼티입니다.
• 즉, 프로퍼티는 값을 담고 있으며, 메서드는 객체가 수행할 수 있는 동작을 정의합니다.

Q2. 식별할 수 있는 유니온을 사용할 때 주의할 점?

A2.

• 식별할 수 있는 유니온의 판별자는 반드시 “유닛 타입”(리터럴 값)이어야 합니다.
• 판별자로 string, number, boolean 같은 기본 타입을 사용해야 하며, 인스턴스 타입은 사용할 수 없습니다.
• 판별자가 모든 유니온 멤버에서 공통적으로 존재해야 올바르게 작동합니다.

[202110861]

Q. 프로퍼티와 메서드의 차이가 무엇인가요?

• 프로퍼티: 키와 값으로 구성되며 프로퍼티의 집합이 객체이다. 프로퍼티를 나열 할때는 쉼표로 구분
• 메서드: 프로퍼티 값이 함수일 경우 일반 함수와 구분하기 위해 메서드라 부른다.

Q. 식별할 수 있는 유니온을 사용할 때 주의할 점?

• 판별자는 유닛 타입으로 선언되어야 정상적으로 동작한다.
• 유닛 타입이 아니거나 인스턴스화 할 수 있는 타입일 경우 타입이 좁혀지지 않기 때문이다.

[202110861]

<모던 자바스크립트 Deep Dive>

1. 키워드

   • 객체
   • 객체 리터럴
   • 클래스 기반 객체지향 언어
   • 프로토타입 기반 객체지향 언어
   • 프로퍼티
   • 메서드

2. 질문
   Q1. var person = { ’last-name’ : ’lee’ }; 일 때 person.last-name의 실행결과가 Node.js와 브러우저환경에서 어떻게 다르고 그 이유를 설명하세요.

<우아한 타입스크립트>

1. 키워드

   • 식별할 수 있는 유니온
   • 유닛 타입
   • Exhaustiveness Checking

2. 질문
   Q2. 식별할 수 있는 유니온이란 무엇이며 어떤 상황에 사용할 수 있나요?

[xeunnie]

Q1. var person = { ’last-name’ : ’lee’ }; 일 때 person.last-name의 실행결과가 Node.js와 브러우저환경에서 어떻게 다르고 그 이유를 설명하세요.

A1.

• Node.js 환경: "last-name"이 유효한 식별자가 아니므로 ReferenceError가 발생합니다.
• 브라우저 환경: window.name이 빈 문자열("")로 암묵적 존재하므로, undefined - "" = NaN이 됩니다.
• 해결 방법은 대괄호 표기법([])을 사용하여 정확한 키를 참조하는 것입니다

Q2. 식별할 수 있는 유니온이란 무엇이며 어떤 상황에 사용할 수 있나요?

A2.

• 식별할 수 있는 유니온은 유니온 타입을 식별할 수 있도록 판별자(태그)를 추가하는 패턴입니다.
• 이를 사용하면 타입을 좁혀 특정 분기에서 올바른 타입을 추론할 수 있습니다.
• 다양한 객체 타입을 유니온으로 처리할 때, 각 타입을 명확히 구분하고 타입 안전성을 높이는 데 유용합니다.

[202110861]

Q1. var person = { ’last-name’ : ’lee’ }; 일 때 person.last-name의 실행결과가 Node.js와 브러우저환경에서 어떻게 다르고 그 이유를 설명하세요.

• 자바스크립트 엔진은 person.last를 먼저 평가하며, person객체에 프로퍼티 키가 last인 프로퍼티가 없기 떄문에 undefined로 평가.
• Node.js 에서는 ReferenceError (이유: name이라는 식별자 선언이 없기 때문에 에러 발생)
• 브라우저 환경: NaN
  (이유: name이라는 전역변수(전역 객체 window의 프로퍼티)가 암묵적으로 존재. (전역변수 name은 window의 이름을 가리키며 기본값은 빈 문자열) (undefined - ''이므로 NaN) )

Q2. 식별할 수 있는 유니온이란 무엇이며 어떤 상황에 사용할 수 있나요?

• 타입 간의 구조 호환을 막기 위해 타입 마다 구분할 수 있는 판별자를 달아주어 포함관계를 제거하는 것
• 각 타입이 비슷한 구조를 가지지만 서로 호환되지 않도록 만들어주기 위해서 사용할 수 있다.

[xeunnie]

[모던 자바스크립트 Deep Dive]

키워드

1. 객체 리터럴 ({})
2. 프로퍼티 축약 표현
3. 계산된 프로퍼티 ([key])

질문

Q. 객체 리터럴에서 프로퍼티를 정의하는 방식과 접근하는 방법에는 어떤 것이 있나요?

[우아한 타입스크립트 with 리액트]

키워드

1. Exhaustiveness Checking (철저한 타입 검사)
2. never 타입 & 타입 좁히기
3. Discriminated Unions (식별할 수 있는 유니온)
4. Unit Type (유닛 타입) & Type Safety (타입 안정성)

질문

Q1. 식별할 수 있는 유니온(Discriminated Unions)이란 무엇이며, 어떤 장점이 있나요?
Q2. Exhaustiveness Checking이란 무엇이며, 어떤 경우에 유용하게 사용할 수 있나요?

[xeunnie]

Q1. 객체 리터럴에서 프로퍼티를 정의하는 방식과 접근하는 방법에는 어떤 것이 있나요?

A1.

• 정의 방식: 키: 값 형태로 선언하며, 동적 키 생성([] 표기법)도 가능합니다.
• 접근 방법: .(마침표 표기법)과 [](대괄호 표기법) 두 가지가 있습니다.
• . 표기법은 일반적인 키에서, [] 표기법은 동적 키나 특수 문자 포함 키에서 사용됩니다.

Q2. 식별할 수 있는 유니온을 사용할 때 주의할 점?

A2.

• 식별할 수 있는 유니온의 판별자는 반드시 “유닛 타입”(리터럴 값)이어야 합니다.
• 판별자로 string, number, boolean 같은 기본 타입을 사용해야 하며, 인스턴스 타입은 사용할 수 없습니다.
• 판별자가 모든 유니온 멤버에서 공통적으로 존재해야 올바르게 작동합니다.

Q2. Exhaustiveness Checking이란 무엇이며, 어떤 경우에 유용하게 사용할 수 있나요?

A2.

• Exhaustiveness Checking은 모든 유니온 멤버에 대해 타입 분기를 강제하는 방법입니다.
• 타입이 추가되거나 변경될 때 빠진 케이스가 있다면 에러를 발생시켜 안전성을 보장합니다.
• 유니온 타입을 다룰 때 실수 없이 모든 케이스를 처리하도록 강제하는 데 유용합니다.

[202110861]

Q1. 객체 리터럴에서 프로퍼티를 정의하는 방식과 접근하는 방법에는 어떤 것이 있나요?

• 정의 방식: 키와 값 형태로 선언
• 접근 방식: 마침표 표기법( . ), 대괄호 표기법( [ ] )

Q2. 식별할 수 있는 유니온(Discriminated Unions)이란 무엇이며, 어떤 장점이 있나요?

• 정의: 타입 간의 구조 호환을 막기 위해 타입 마다 구분할 수 있는 판별자를 달아주어 포함관계를 제거하는 것
• 장점: 존재하지 않는 속성 접근 가능성 방지 -> 타입 안전성 보장

Q3. Exhaustiveness Checking이란 무엇이며, 어떤 경우에 유용하게 사용할 수 있나요?

• 정의: 모든 케이스에 대해 철저하게 타입을 검사하는 것. 모든 케이스에 대한 분기 처리를 하지 않았을 때, 컴파일 타임 에러가 발생하게 하는 것.
• 모든 케이스에 대한 타입 검사를 강제할 때 유용하게 사용할 수 있다.

[wlgusqkr]

Exhaustiveness Checking는 never의 어떤 특성을 이용한 것인가요?

[xeunnie]

Q1. Exhaustiveness Checking는 never의 어떤 특성을 이용한 것인가요?

A1.

• never 타입은 절대 도달할 수 없는 타입이며, 어떤 값도 할당될 수 없습니다.
• 따라서 유니온 타입에서 빠진 케이스가 있다면 never 타입으로 할당되지 않아 오류를 발생시킵니다.
• 이를 활용하면 새로운 타입이 추가될 때 빠진 분기 처리를 강제할 수 있습니다.

[202110861]

Q1. Exhaustiveness Checking는 never의 어떤 특성을 이용한 것인가요?

• never: 어떤 값도 가질 수 없는 타입, 절대 발생해서는 안되는 상황 감지
• never을 통해 모든 가능한 케이스를 처리했는지 확인 할 수 있다. (누락된 경우 감지)