Skip to content

Commit aab84b0

Browse files
reyoucatreyoucat
authored
Merge pull request #3 from dev-bookchat/reyoucat/ items 01 - 18
📝 리유: 01 - 18 장 PR
2 parents 57a5b06 + 3ecfc9a commit aab84b0

2 files changed

Lines changed: 192 additions & 0 deletions

File tree

‎chapter2/reyou/item01-14.md‎

Lines changed: 155 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,155 @@
1+
## 아이템 01. TS 와 JS 관계 이해하기
2+
3+
- JS 슈우퍼셋임
4+
- TS 라서 무서워하지말 것. JS에서 마이그레이션 할 수 있음.
5+
- 컴파일과정이 필요함 번거롭지만 뭐 어쩌겠으.
6+
- 타입을 추론한다는 `정적` 방식은 장점이 있음.
7+
- 그것은 빌드나 컴파일전에 미리 오류나 문제점들을 알 수 있다는 것.
8+
- 그래도 만능은 아님
9+
- 인생은 엄격하게 살자
10+
11+
## 아이템 02. TS 설정 이해하기
12+
13+
- TS 컴파일러 설정 개 많음....
14+
- 근데 나중에 찾음 됌 tsconfig.json
15+
- noImplicitAny : 이거 꼭 설정. 애니있는 타입스크립트는 타입스크립트가 아이다
16+
- srtictNullCheck : 널과 언디파인드를 막 할당하지말라 `-_-` 요거 설정해서 의도적 명시할 것.
17+
- 아무튼 이들 설정은 짜기 힘들지만 고급진 품질코드를 위해 미리하는게 좋음.
18+
19+
## 아이템 03. 코드생성과 타입이 관계없음
20+
- TS 컴파일러는
21+
1. 컴파일(트랜스파일 TS->JS)함
22+
2. 코드 타입 오류 체크해줌ㅋ
23+
- 하지만 대충.. 컴파일하면 JS 튀어나오긴함
24+
- 런.타.임.엔 타.입.체.크. 불가 ㅠ(흠?)
25+
- 아 뭐 대충 알 것같다...
26+
- 인스턴스오브 체크는 런타임에...
27+
- 아무쪼록 태그된 유니온이란 기법이 있어서 요런건 좀 특이하구나... 하고 봄
28+
- https://twitter.com/RE_U_CAT/status/1517866788394258432
29+
- 타입을 클래스로 만들면, 타입(런타임 접근불가)와 값(런타임 접근가능)을 둘다 쓰기도한다....
30+
- 클래스로 만들래... 아 클래스 싫은뎅 -ㅅ-
31+
- 인스턴스 오브 어쩌구는 아이탬8에서.
32+
- 타입연산은 런타임에 영향을 주지 않은다는 말은 타입체커를 우회할 수 있군아....
33+
- https://twitter.com/RE_U_CAT/status/1517868440048238593
34+
- 이거 보면 변환된 코드까지 보면 됨.
35+
- 그럼 뭐.... 대충 다통과해서 곤란쓰
36+
- 런타임 타입은 선언된 타입과 다를 수 있데...?
37+
- 이유는 뭘까.
38+
- 흠... 런타임중에(API결과)가 확실히 맞을 수 않을 수 있구나. 불린으로 해서 불린이 온다는 보장이 없단소리군.
39+
- TS Type 함수를 오버로드 할 쑤 없슴댜
40+
- 일반적인 오버로딩 기능은 지원함
41+
- 근데 구현체만 남아 안될 수 있음.
42+
- 하여튼 아이템 50에서 알아보자.
43+
- https://twitter.com/RE_U_CAT/status/1517879363160920065
44+
45+
- TS Type는 런타임 성능에 영향 없음.
46+
- 대신 빌드타임 ^^ (심볼같은걸 다 뗀다.)
47+
48+
## 아이템 04. 구조적 타이핑 익숙ㅋ
49+
- 덕타이핑이란~ 객체가 어떤 타입에 부합하는 변수와 메서드를 가질 경우, 객체를 해당 타입에 속하는 것으로 간주한다. (오리처럼 걷고, 헤엄치고, 짹짹이면? => 오리다)
50+
- 일단 타입을 정하고, 구조적으로 만드는데에 익숙해 져야겠네? 음... JS는 걍 짜면 되는데...
51+
- 그치만 구조적 타이핑에 문제도 있다.
52+
- JS의 고질적인 0.1 + 0.2 = 0.30000000000000004 요런 문제들 것들! 이런건 체크 못한다.
53+
- 포함관계에 (?이렇게 써도되나) 3D는 2D 개념을 포함하고 있으니까, 타입체크에서도 회피가능.... 문제가있다. 이런걸 오픈(*타입 확장에 열려있다.)되어있다고 하는구나 `-_-;;;`
54+
- 어.. 그래서 클래스 방식으로 (슈가 신덱싱) 짜도... 인스턴스가 예상과 다를 수 있다.
55+
- 구조적으로 짰지만, 사용자가 생성자를 안타는 형태로 해서 타입을 회피하고 선언을 해버리면 원하지않은 결괄를 가져옴.
56+
- [샘플을 만들었다-링크는 트이터로](https://twitter.com/RE_U_CAT/status/1517894759960150016)
57+
- 그치만 구조적 타이핑하면 유닛테스팅 쉽게 가능
58+
- 이유는 디비에대한 추상화(SQL쿼리가 스트링이고 리턴이 애니라는걸 명시)가 되기에... 아무튼 이건 아이템 51에서 다시보자.
59+
60+
## 아이템 05. Any 타입 쓰지마
61+
- 왜? 애니? ㅇㅇ... 근데 디비...리턴되는건 ^^
62+
- 아무튼 점진적이고 옵셔널한 타입이있다.
63+
- 그치만 애니는 쓰지말라...
64+
- 타입스크립트의 언어가 물러터지기 때문.
65+
- 타입 왜씀?
66+
67+
68+
## 아이템 06. 편집기로 TS 써보기
69+
- TSC, TSSERVER 친구가 있다.
70+
- VSCODE쓰면 짱이다.
71+
- 아무튼 편집기 짱이니까, 그거 TS접목해서 돌아가도록 설정해서 써라...
72+
- 쓰면, node 같은걸 Fetch 해 왔을 때, 편집기로 탐색이 가능하다. (==> 타입추론이 라이브러리도 가능하다는 의미. ==근데 d.ts파일이 있어야함ㅋㅋㅋㅋㅋㅋㅋ)
73+
- https://joshua1988.github.io/ts/usage/declaration.html
74+
75+
## 아이템 07. 타입값들이 집합이라고?
76+
- 이잉!? 집합이었구나. 나도 첨 알았다. 이런거다..
77+
- 엄격한 상속관계가 아니라, 겹치지는 집합으로 표현 된다. 서브타입이 아니면서도 겹쳐질 수 있음
78+
- 타입 선언 안해도 타입이 결정될 수 있음
79+
- 합집합이나 교집합에 대한 내용도 있으니 집합이라고 생각하면 편하다. 타입은 그래서 집합이다.
80+
- 네버(never)는 공집합 (얘는 루프문 탈때나 씀)
81+
- keyof 는 나중에 다시 볼 것
82+
83+
## 아이템 08. 타입공간과 vs 값공간 씸벌 구분
84+
- 타입스크립트를 읽을 때, 타입인지, 값인지 플레이그라운드를 통해서 개념을 익혀라 ㅠㅠㅠㅠ
85+
- 타입은 값을 안가짐. 그래서 찍어도 안나오고 에러남
86+
- interface {} 나, type{} 에만 존재함
87+
- 클래쓰나 이넘 같은 키워드는 헐..... 타입, 값 두가지 로 쓸 수 있다. 콘솔로 찍어보니 그릏다.
88+
- "ㅇㅅㅇ" -> 리터럴이나 타입일 수 있음. 구분은? 알아서 해야지뭐...
89+
- typeof, this 등등등... 이것들은 타입일 수도 있고 공간 값일 수 있다.
90+
- 결론은 타입과 값을 구분 잘하라는거고
91+
- 매개변수에서도 잘 추론되니까 나눠 쓰라는건데 아이템 20에서 다시볼 내용.
92+
93+
## 아이템 09. 타입 단언ㄴㄴ 타입선언ㅇㅋ
94+
- 타입 선언과 타입 단언은 둘 다 이건 이 타입이야! 한다지만, 타입 단언은 ㄴㄴ 선언 ㅇㅋ
95+
- 단언은 오류를 못잡아냄 그러니까 (: Type) 쓰라고
96+
- 화살표 함수의 반환타입도 명시하자
97+
- 내부에서 아니면 직관적으로 선언하거나
98+
- 타입에 확 정의할 것.
99+
- 내가 TS보다 타입을 더 잘알 때만 단언하거나 null 쓸 것
100+
- dom 타입은 55 아이템에서
101+
- 접미사 ! 는 타입단언
102+
- unknown은 모든 타입의 서브타입. 하지만 뭔가 위험한짓을 하고 있겠지?
103+
104+
## 아이템 10. 객체 래퍼타입 피하자
105+
- 래퍼타입 이해하기
106+
- 직접사용, 인스턴스 작성 피하기
107+
- 객체 래퍼타입은 잘 쓰지말고, 기본형 타입을 쓸 것.
108+
- String 보다 string
109+
- Number 보다는 number 같은걸로!!!!!
110+
111+
- 기본형 말고 기본형을 잘 쓰도록 말아둔 래퍼타입이란 전설적인 객체 타입 친구들이 있다.
112+
- 몽키패치란? 원숭이 장난처럼 중간에 도는 코드에 슉샥 코드로 수정을 가하는 것
113+
- 이런식으로 수정을 하면 원래 동작하는
114+
"문자문자".charAt 를
115+
String.prototype.charAt 로 재 선언해서 해당 위치의 this를 강제바인딩, 결과를 다르게 만들 수 있다.
116+
- TS는 기본형과 객체타입레퍼를 따로 구분해 모델링
117+
118+
## 아이템 11. 잉여속성체크한계인지
119+
- 와 ... 잉여속성 체크 한계가 뭐야??????
120+
- 남는 속성이나 추가한 속성 같은걸 말한거구나.
121+
- 객체리터럴을 변수에 할당, 함수에 매개변수로 전달할 때, 잉여속성 체크 수행.
122+
- 오류찾는 효과적인 방법
123+
- TS체커가 수행하는 일반적 구조적 할당과, 가능성 체크는 역할이 다름.
124+
- 잉여속성 체크엔 한계가 있음. 임시변수를 도입하면 건너뛸 순 있는데...
125+
- https://twitter.com/RE_U_CAT/status/1518135139993530368
126+
127+
128+
## 아이템 12. 함수 표현식에 타입 적용
129+
- 아 당연히 선언식과 표현식은 다르지
130+
- TS에선 표현식 쓰는게 좋음. 매개변수부터 반환값까지 전체를 함수타입으로 선언하여 재사용 가능한 장점.
131+
- 매개변수나 반환값에 타입을 명시보다, 함수표현식 전체에 타입구조를 매핑하는게 좋다.
132+
- 이왕이면 하나로 통합하는것도 좋아.
133+
- 같은타입 타입 시그니처를 반복적으로 작성된다면 타입을 분리하거나 이미 존재하는 타입이 없나볼 것. 라이브러리를 직접 만들면 공통 콜백을 만들면 좋음.
134+
- 다른함수나 시그니처를 참고하려면 typeof fn을 쓴다.
135+
136+
## 아이템 13. 타입 vs 인터페이스
137+
- 타입과 인터페이스의 차이점과 비슷한점을 이해해야지
138+
- 인터페이스 - 타입확장 가능
139+
- 타입 - 인터페이스를 확장 가능
140+
- 유니온 타입은 있지만
141+
- 유니온 인터페이스는 없음.
142+
- 한타입을 타입과 인터페이스로 작성할 줄 알아야지
143+
- 프로젝트에서 어떤걸 할지 결정하고 일관되게 짜야지. 리액트에서 컴포넌트는 타입으로 선언하고 메서드는 인터페이스로 만든다던가
144+
- 오.. 선언병합이란게 인터페이스에 있구나. 나중에 많이 씀.
145+
146+
## 아이템 14. 타입 연산과 제너릭 사용으로 반복줄이기
147+
- 제너릭 친구를 써서 반복 줄이기다. (DRY)
148+
- 타입에 이름을 붙여 반복 피하기, Extends 사용해서 인터페이스 반복 피하기.
149+
- 열심히 반복 줄이기 ...
150+
151+
- 타입간 매핑을 공부하면 좋음... keyof, typeof, 인덱싱, 매핑된 타입 등...
152+
- 매핑된 타입은 (k in keyof Options) 같은건 순회하면서 Options 내에 k 속성이 있는지 찾는다. (Partial 참조)
153+
- `80쪽좀 나중에 다시 보자.`
154+
- 제너릭은 타입을 위한 함수 타입을 반복하는 대신, 제너릭으로 타입간에 매핑가능
155+
- 표준라이브러리에 정의된 Pick, Partial, ReturnType 같은 제너릭타입에 익숙하져야.....

‎chapter2/reyou/item15-18.md‎

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1 +1,38 @@
11
## 아이템 15. 동적 데이터에 인덱스 시그니처 사용하기
2+
3+
- 런타임 때 까지 객체속성을 알 수 없는 경우에만 인덱스 시그니처 쓰기.
4+
- 인덱스 시그니쳐가 뭐야
5+
https://developer-talk.tistory.com/297
6+
- 인덱스 형태로 쿠쿠루삥뽕하게 만들어 주는 것
7+
- 인덱스 시그니처타입엔 undefined 를 써서 안전함을 고려 할 것.
8+
- 가능하면 인터페이스, Record, 매핑된 타입 같은걸로 인덱스 시그니쳐 쓰지말고 명확하게 ㅠㅠ
9+
- 자동완성도 안되니 고심할 것.
10+
- 데이터를 동적으로 표현할 때 사용.
11+
12+
13+
## 아이템 16. Number 인덱스 시그니처보다 Array, 튜플, ArrayLike를 사용하기
14+
15+
- 배열은 객체이므로 키는 숫자가 아니라 문자열, 인덱스 시그니쳐로 사용 된 number 타입은 버그잡을 순수 타입 스크립트
16+
- (제목과 동일)
17+
-
18+
19+
## 아이템 17. 변경 관련된 오류 인지를 위해 readonly 쓰기
20+
- 아이고 당연히 한번 딱 박으려고 했는데, 바뀌면 안되죠 readonly로 선언하자.
21+
- JS는 배열 변경이 가능하기 때문에, TS에서도 오류없이 넘어가기도 하는데, 이 때 오류를 좁힐 readonly가 필요하다.
22+
- 딱 보면 읽기전용. 한번 만들면 변경불가
23+
- readonly의 경우 호출하는 함수에도 넣을 수 있다.
24+
- ```function arrSum(arr: readonly number[]){}``` 이런식으로.
25+
-
26+
27+
- 변경하면서 발생하는 오류도 잡고, 변경이 발생하는 코드도 쉽게 찾을 수 있다.
28+
- const 와 readonly는 다른 것.
29+
- 얕게 동작한다. 잘 알아둘 것.
30+
31+
## 아이템 18. 매핑된 타입 사용. 값동기화
32+
- 매핑된 타입을 사용해서 관련된 값과 타입 맞출 것.
33+
- 데이터가 변하면, 리렌더링 할 수 있지.
34+
- 핸들러가 변하면, 리렌더링 필 요 없지.
35+
- 104page 부터 보면 된다.
36+
- https://t.co/USm0A7KcXy
37+
- 인터페이스에 속성을 추가할 때, 선택을 강제하도록 매핑된 타입을 고려할 것....
38+
- 실패에 대한 방법을 고민해서 예외처리를 하는것도 중요하다... 어떤 식으로 판단을 할지.

0 commit comments

Comments
 (0)