Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[박승훈] 챕터 10: 모듈형 자바스크립트 디자인 패턴 #96

Merged
merged 1 commit into from
Dec 1, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
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.
Loading