Skip to content

Commit 48283d0

Browse files
authored
챕터 10,11 추가 (#98)
1 parent 6691429 commit 48283d0

File tree

2 files changed

+136
-0
lines changed

2 files changed

+136
-0
lines changed

챕터_10/변수미.md

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
확장 가능한 자바스크립트 환경에서 모듈형이란, 서로 의존성이 낮은 기능들이 모듈로써 저장된 형태를 뜻한다.
2+
<- 느슨한 결합은 의존성을 제거하여 서비스의 유지보수를 용이하게 만들어준다.
3+
4+
es2015이전에 사용된 다양한 모듈 형식에 대해 알아보자.
5+
6+
## 10.1 스크립트 로더에 대한 참고사항
7+
8+
스크립트 로더 : 모듈형 자바스크립트를 구현하기 위한 핵심적인 도구, 호환되는 스크립트 로더를 사용해야만 모듈형 자바스크립트를 구현할 수 있다.
9+
ex) RequireJs, curl.js
10+
11+
## 10.2 AMD
12+
13+
> 모듈과 의존성 모두를 비동기적으로 로드할 수 있도록 설계된 모듈 정의 방식
14+
15+
장점
16+
17+
- 비동기적이면서도 높은 유연성을 가지고 있다.
18+
- `define()`이 네임스페이스의 역할을 하여 모듈에서 사용하는 변수와 전역변수를 분리
19+
20+
단점
21+
22+
- AMD는 여러 파일을 로딩해야 하고, 순서를 맞춰주어야 하여 널리 사용하지는 않게 되었다.
23+
-> 이후 ESM의 표준 import 구문을 탄생하는 데 큰 영향을 미치게 되었다.
24+
25+
AMD에서 중요한 두가지 개념
26+
27+
- `defind` 메서드 : 모듈 정의를 구현
28+
- `require` 메서드 : 의존성 로딩을 처리
29+
30+
## 10.3 Common Js
31+
32+
> 서버 사이드에서 모듈을 선언하는 간단한 API를 지정하는 모듈 제안
33+
> AMD와는 달리 파일시스템, 프로미스 등 더욱 광범위한 부분을 다룬다.
34+
35+
Node.js 환경에서는 common js가 기본 형식으로 쓰인다.
36+
(common js 모듈은 Node.js에서 사용할 자바스크립트 코드를 패키징하기 위해 처음 등장)
37+
38+
## 10.4 AMD vs CommonJS
39+
40+
AMD
41+
42+
- 브라우저 우선 접근방식 채택
43+
- 비동기 동작과 간소화된 하위 호환성을 선택
44+
- 파일 I/O에 대한 개념 X
45+
- 다양한 형태 모듈 지원, 브라우저에서 자체적으로 실행되어 유연한 포맷
46+
47+
CommonJS
48+
49+
- 서버 우선 접근방식
50+
- 동기적 작동, 전역 변수와의 독립성 챙김
51+
- 객체만을 모듈로써 지원
52+
53+
UMD
54+
55+
- 브라우저와 서버 환경에서 모두 작동할 수 있는 모듈을 원함, AMD와 Common js의 약점을 해결
56+
- AMD는 클라이언트 사이드에서 많이 사용되고, CommonJS는 서버 사이드에서 많이 사용되기 때문에, UMD를 사용하면 두 개의 모듈을 따로 만들 필요가 없게 된다.

챕터_11/변수미.md

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
네임스페이스는 코드 단위를 고유한 식별자로 그룹화한 것을 뜻한다.
2+
3+
- 전역 네임스페이스 내에 존재하는 다른 객체나 변수와의 충돌을 방지할 때 유용
4+
- 프로그램의 기능들을 체계적으로 구성하여 코드의 재사용성과 관리의 편의성을 높여준다.
5+
6+
---
7+
8+
자바스크립트는 다른 언어와 같이 네임스페이스를 기본적으로 지원하지 않지만, 객체와 클로저를 활용해 비슷한 효과를 낼 수 있다.
9+
10+
## 11.2 단일 전역 변수 패턴
11+
12+
하나의 주요 참조 객체로 사용하는 방식
13+
14+
👎 다른 개발자가 같은 이름의 전역변수를 이미 사용하고 있는 가능성이 있다는 것이 큰 단점
15+
16+
```ts
17+
const myUniqueApplication = (() => {
18+
function myMethod() {}
19+
20+
return { myMethod };
21+
})();
22+
```
23+
24+
## 11.3 접두사 네임스페이스 패턴
25+
26+
고유한 접두사를 설정한 다음, 모든 메서드, 변수,객체를 접두사 뒤에 붙여 정의
27+
28+
```
29+
const myUniqueApplication_propertyA = {};
30+
```
31+
32+
👍 전역에서 특정 변수와 이름이 겹칠 가능성을 효과적으로 줄임
33+
👎 애플리케이션이 커질수록 많은 전역 객체가 생성됨
34+
35+
## 11.4 객체 리터럴 표기법 패턴
36+
37+
키와 값으로 이뤄진 집합
38+
39+
```javascript
40+
myApplication.foo = () => "bar";
41+
42+
myApplication.utils = {
43+
toString() {},
44+
};
45+
```
46+
47+
👍 전역 네임스페이스를 오염시키지 않으면서도 코드와 매개변수를 논리적으로 구성하는 데 도움을 줌
48+
👍 키-값 구조이므로 알아보기 쉬움
49+
50+
## 11.5 중첩 네임스페이스 패턴
51+
52+
객체 리터럴 표기법 패턴을 발전시킨 형태
53+
54+
```javascript
55+
YAHOO.util.Dom.getElementsByClassName("test");
56+
```
57+
58+
👍 다른 패턴에 비해 충돌 위험이 낮음
59+
👍 단일 객체 네임스페이스 패턴과 성능상 차이가 크지 않음
60+
61+
## 11.6 즉시 실행 함수 표현식 패턴
62+
63+
== 익명 함수
64+
65+
```javascript
66+
(() => {
67+
/** */
68+
})();
69+
(function foobar() {
70+
/** */
71+
})();
72+
```
73+
74+
- 애플리케이션의 로직을 캡슐화하여 전역 네임스페이스로부터 보호하는 방법
75+
76+
## 11.9 권장하는 패턴
77+
78+
저자가 권장하는 패턴은 **'객체 리터럴 패턴을 사용한 중첩 네임스페이스 방법'**
79+
80+
> 객체 리터럴 패턴은 단점 자체를 언급하지 않았던것 같음

0 commit comments

Comments
 (0)