File tree Expand file tree Collapse file tree 2 files changed +136
-0
lines changed
Expand file tree Collapse file tree 2 files changed +136
-0
lines changed Original file line number Diff line number Diff line change 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를 사용하면 두 개의 모듈을 따로 만들 필요가 없게 된다.
Original file line number Diff line number Diff line change 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+ > 객체 리터럴 패턴은 단점 자체를 언급하지 않았던것 같음
You can’t perform that action at this time.
0 commit comments