Skip to content

Commit

Permalink
Docs: 박승훈 10장 (#96)
Browse files Browse the repository at this point in the history
  • Loading branch information
Orchemi authored Dec 1, 2024
1 parent a312f0a commit a2414db
Show file tree
Hide file tree
Showing 2 changed files with 167 additions and 0 deletions.
167 changes: 167 additions & 0 deletions 챕터_10/박승훈.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,167 @@
## 들어가며

- 모듈형 : "서로 의존성이 낮은 기능들이 모듈로써 저장된 형태"
- 느슨한 결합은 의존성을 제거하여 앱의 유지보수에 용이

## 스크립트 로더

- 모듈형 JS를 구현하기 위한 핵심도구
- 호환 가능한 스크립트 로더를 사용해야만 모듈형 JS 구현 가능


## AMD

- Asynchronous Module Definition
- 모듈과 의존성 모두를 비동기적으로 로드할 수 있도록 설계된 모듈 정의 방식
- 주요 목표 : 개발자들이 활용할 수 있는 모듈형 JS 솔루션 제공
- JS 모듈화를 위한 주춧돌


### AMD의 구조

- define() : 모듈을 정의하는 함수
- require() : 모듈을 로드하는 함수


```javascript
define('module', ['dependency'], function(dependency) {
return {
method: function() {
dependency.method();
}
};
});

require(['module'], function(module) {
module.method();
});
```


### AMD 결론

- 탄탄한 애플리케이션 작성에 여러 장점을 제공
- 전역 객체의 사용을 최소화
- 변수에 모듈을 할당 가능
- 의존성 관리 측면에서 효율적


### 나의 생각

AMD는 사용할 일이 없어서 조금 어려운 감이 있네요. 예제에는 더 다양한 예시와 설명들이 있는데 가볍게 훑고 지나간 것 같습니다.


## CommonJS

- 서버 사이드에서 모듈을 선언하는 간단한 API를 지정하는 모듈 제안
- AMD와는 달리 I/O, 파일시스템, 프로미스 등 더욱 광범위한 기능 제공


### CommonJS의 구조

- 모듈을 함수로 감싸는 작업이 불필요(AMD의 define과 달리)
- exports 객체를 통해 다른 모듈에 내보내고자 하는 객체를 담음
- require() 함수를 통해 다른 모듈을 불러옴


```javascript
var lib = require('package/lib');

function foo() {
lib.log('hello world');
}

exports.foo = foo;
```

만약 위의 코드를 AMD로 구현했다면?

```javascript
// 정적 의존성
define(['package/lib'], function(lib) {
function foo() {
lib.log('hello world');
}

return {
foo: foo
};
});

// 동적 의존성
define(function(require) {
var lib = require('package/lib');

function foo() {
lib.log('hello world');
}

return {
foo: foo
};
});
```


### Node.js 환경에서의 CommonJS

- Node.js 환경에서는 CommonJS가 기본 형식으로 사용됨
- Node.js 버전 13.2.0 이후의 안정적인 버전에서는 ES 모듈도 지원
- 최근에는 ES 모듈 형식이 재사용 가능한 JS 코드를 모듈화하는 표준으로 자리잡음


#### Node.js가 CommonJS를 모듈로 인식하는 경우

- .cjs 확장자
- package.json 파일에 "type": "commonjs" 속성이 있거나 type 항목이 없을 때 .js 확장자
- .mjs, .cjs, .json, .node, .js 이외의 확장자를 가진 파일


#### 메서드에 따라 다른 모듈 로더

- require : 항상 CommonJS 모듈 로더 사용
- import : ECMAScript 모듈 로더 사용


#### CJS / ESM 호환성

- 많은 Node.js 라이브러리와 모듈은 CommonJS 형식으로 작성되어 있음
- 브라우저 호환을 위해 모든 주요 브라우저에서는 ESM 문법 지원
- Babel 등의 트랜스파일러를 사용해 구버전 Node.js에서도 작동하는 require() 함수로 변환 가능
- **정리 : ES6 모듈 문법으로 작성된 라이브러리를 Node.js에서 실행하는 경우 내부적으로 CommonJS로 트랜스파일링됨**


### AMD vs CommonJS

> AMD, CommonJS는 서로 다른 목표를 가진 유효한 모듈 형식
#### AMD

- 브라우저 우선 접근 방식 채택
- 비동기 동작과 간소화된 하위 호환성을 선택
- 파일 I/O에 대한 개념 없음
- 객체, 함수, 생성자, 문자열, JSON 등 다양한 형태의 모듈 지원
- 브라우저에서 자체적으로 실행된다는 점에서 유연한 포맷

#### CommonJS

- 서버 우선 접근 방식
- 동기적 작동, 전역 변수와의 독립성, 미래의 서버 환경 고려
- CommonJS가 언래핑된 모듈을 지원하기 때문에 ES2015+ 표준에 조금 더 가깝게 느껴짐


### 나의 생각

AMD 파트에서는 진짜 막막했는데, CommonJS부터는 눈이 조금씩 트이는 기분이었어요. 나중에 ESM, 혹은 더 진보된 무언가가 나온 미래에는 CommonJS도 "뭐야 저게?"하는 날이 올까 싶네요ㅋㅋㅋ Node.js 기반 라이브러리나 옛날 코드를 볼 때 require 방식의 cjs를 많이 보게 되는데, CommonJS에 대해 조금 알고 넘어간다는 것에 의미를 두고 싶어요.


## 마치며

> 이런 모듈 형식들은 단순히 모듈 패턴만 사용하는 것보다 장점이 있다.
- 전역 변수 관리의 필요성 감소
- 정적/동적 의존성 관리에 대한 향상된 지원
- 스크립트 로더와의 높은 호환성
- 서버 환경에서의 모듈 호환성 강화


File renamed without changes.

0 comments on commit a2414db

Please sign in to comment.