generated from muhandojeon/study-template
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* docs: 챕터 10 정리 추가 * docs: 챕터 11 정리 추가
- Loading branch information
Showing
2 changed files
with
68 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
상조 | ||
|
||
- 어디서든 지원하고 싶을 때 쓰는 모듈 방식이 UMD라고 알고 있었음 | ||
- 웹 컴포넌트 개발에 UMD 사용했던 경험 있음 | ||
- 웹 컴포넌트는 어떤 환경에서든 사용할 수 있게 만들어야 한다. (ex. 서버에서 구동되는 환경도 고려) | ||
어느 환경에서 실행될지 모르니까 일단 많이 지원되는 방향으로 선택 | ||
|
||
혜성 | ||
|
||
- AMD는 브라우저 우선, CJS는 서버 우선으로 이해했음 | ||
- CJS 특징 중 '언래핑된 모듈을 지원한다'가 있는데, 언래핑된 모듈이 뭔지 궁금해서 찾아봄 | ||
- 파일 top level에서 require하고 export하는 것 = 언래핑된 모듈 | ||
- 웬만하면 ES 모듈을 사용하는 게 좋지 않을까 생각 | ||
|
||
승훈 | ||
|
||
- 모듈형 정의 짚고 넘어감 | ||
- 스크립트 로더를 처음 알게 되었음 | ||
- AMD : define, require | ||
- CJS : AMD와 차이점을 중심으로 파악 | ||
|
||
수미 | ||
|
||
- 스크립트 로더, AMD, CJS, UMD 정의와 장단점을 주로 봤음 | ||
|
||
지연 | ||
|
||
- 책 내용에 AMD는 장단점이 다 있는데, CJS는 장점만 있길래 단점도 찾아봄 | ||
- CJS 처음 봤던 건 lodash 때문이었고, 트리쉐이킹 문제로 번들 사이즈 커진다는 정도로 알고 있었음 | ||
|
||
창완 | ||
|
||
- node 23부터 require(esm) 가능하다. | ||
- 언제 유용하게 쓸 수 있을까? deno, bun |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
상조 | ||
|
||
- 타입스크립트 네임스페이스랑 개념 자체는 거의 비슷하다 | ||
- 서버에서 가져오는 모델 타입에 네임스페이스 사용하고 있음 (ex. `UserReponse`가 아니라 `User.Reponse`) | ||
|
||
혜성 | ||
|
||
- 의존성 선언 패턴은 꺼내서 쓰는 거라고 이해했음 | ||
- 맥락을 봐야 하는 경우에는 포함하는 형태도 나쁘지 않았음 | ||
|
||
승훈 | ||
|
||
- 즉시 실행 함수를 사용해서 정의하는 이점이 와닿진 않았음 | ||
- 접두사 네임스페이스 패턴은 그냥 당연한 개념으로 생각하고 있었어서 이런 것도 패턴인가 싶었음 | ||
- 책 내용에 확신을 못 느낌 (정답이 없는 내용) | ||
|
||
수미 | ||
|
||
- 객체 리터럴 표기법 패턴에 장점이 없는 걸로 봐서는 저자가 좋아하는 패턴이 아닐까 싶음 | ||
- 즉시 실행 함수 표현식 패턴은 가끔 사용하긴 하는데 굳이 추천할 정도는 아님 | ||
|
||
지연 | ||
|
||
- 네임스페이스는 구분이 가능하도록 정해놓은 범위, 객체나 변수가 겹치지 않는 안전한 소스코드 만드는 개념 | ||
- 리액트 네임스페이스 패턴 | ||
- `forwardRef`로 반환된 컴포넌트는 `ForwardRefExoticComponent` 타입이라 `Object.assign`으로 하위 속성을 병합해야 함 | ||
|
||
창완 | ||
|
||
- 번들러, ESM 사용하면 네임스페이스를 딱히 신경 쓰지 않고 개발할 수 있음 | ||
- 네임스페이스를 쓴다는 건 외부로부터 격리시킨다는 의미인데, 외부에서 수정/삭제 가능하면 네임스페이스 쓰는 의미가 없지 않나 싶음 | ||
- es-toolkit도 여러 빌드 결과물을 지원하는데, 스크립트 형식으로 쓸 수 있음 | ||
- 빌드하면 global.js 파일이 나오기 때문에 브라우저에서 직접 `<script>` 태그로 사용 가능 | ||
- `pick`, `omit`처럼 흔히 쓰는 이름도 네임스페이스 오염시키지 않고 사용할 수 있음 |