Skip to content

Commit

Permalink
챕터 10,11 추가
Browse files Browse the repository at this point in the history
  • Loading branch information
sumi-0011 committed Nov 26, 2024
1 parent 3881db8 commit 792ba0a
Show file tree
Hide file tree
Showing 2 changed files with 136 additions and 0 deletions.
56 changes: 56 additions & 0 deletions 챕터_10/변수미.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
확장 가능한 자바스크립트 환경에서 모듈형이란, 서로 의존성이 낮은 기능들이 모듈로써 저장된 형태를 뜻한다.
<- 느슨한 결합은 의존성을 제거하여 서비스의 유지보수를 용이하게 만들어준다.

es2015이전에 사용된 다양한 모듈 형식에 대해 알아보자.

## 10.1 스크립트 로더에 대한 참고사항

스크립트 로더 : 모듈형 자바스크립트를 구현하기 위한 핵심적인 도구, 호환되는 스크립트 로더를 사용해야만 모듈형 자바스크립트를 구현할 수 있다.
ex) RequireJs, curl.js

## 10.2 AMD

> 모듈과 의존성 모두를 비동기적으로 로드할 수 있도록 설계된 모듈 정의 방식
장점

- 비동기적이면서도 높은 유연성을 가지고 있다.
- `define()`이 네임스페이스의 역할을 하여 모듈에서 사용하는 변수와 전역변수를 분리

단점

- AMD는 여러 파일을 로딩해야 하고, 순서를 맞춰주어야 하여 널리 사용하지는 않게 되었다.
-> 이후 ESM의 표준 import 구문을 탄생하는 데 큰 영향을 미치게 되었다.

AMD에서 중요한 두가지 개념

- `defind` 메서드 : 모듈 정의를 구현
- `require` 메서드 : 의존성 로딩을 처리

## 10.3 Common Js

> 서버 사이드에서 모듈을 선언하는 간단한 API를 지정하는 모듈 제안
> AMD와는 달리 파일시스템, 프로미스 등 더욱 광범위한 부분을 다룬다.
Node.js 환경에서는 common js가 기본 형식으로 쓰인다.
(common js 모듈은 Node.js에서 사용할 자바스크립트 코드를 패키징하기 위해 처음 등장)

## 10.4 AMD vs CommonJS

AMD

- 브라우저 우선 접근방식 채택
- 비동기 동작과 간소화된 하위 호환성을 선택
- 파일 I/O에 대한 개념 X
- 다양한 형태 모듈 지원, 브라우저에서 자체적으로 실행되어 유연한 포맷

CommonJS

- 서버 우선 접근방식
- 동기적 작동, 전역 변수와의 독립성 챙김
- 객체만을 모듈로써 지원

UMD

- 브라우저와 서버 환경에서 모두 작동할 수 있는 모듈을 원함, AMD와 Common js의 약점을 해결
- AMD는 클라이언트 사이드에서 많이 사용되고, CommonJS는 서버 사이드에서 많이 사용되기 때문에, UMD를 사용하면 두 개의 모듈을 따로 만들 필요가 없게 된다.
80 changes: 80 additions & 0 deletions 챕터_11/변수미.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
네임스페이스는 코드 단위를 고유한 식별자로 그룹화한 것을 뜻한다.

- 전역 네임스페이스 내에 존재하는 다른 객체나 변수와의 충돌을 방지할 때 유용
- 프로그램의 기능들을 체계적으로 구성하여 코드의 재사용성과 관리의 편의성을 높여준다.

---

자바스크립트는 다른 언어와 같이 네임스페이스를 기본적으로 지원하지 않지만, 객체와 클로저를 활용해 비슷한 효과를 낼 수 있다.

## 11.2 단일 전역 변수 패턴

하나의 주요 참조 객체로 사용하는 방식

👎 다른 개발자가 같은 이름의 전역변수를 이미 사용하고 있는 가능성이 있다는 것이 큰 단점

```ts
const myUniqueApplication = (() => {
function myMethod() {}

return { myMethod };
})();
```

## 11.3 접두사 네임스페이스 패턴

고유한 접두사를 설정한 다음, 모든 메서드, 변수,객체를 접두사 뒤에 붙여 정의

```
const myUniqueApplication_propertyA = {};
```

👍 전역에서 특정 변수와 이름이 겹칠 가능성을 효과적으로 줄임
👎 애플리케이션이 커질수록 많은 전역 객체가 생성됨

## 11.4 객체 리터럴 표기법 패턴

키와 값으로 이뤄진 집합

```javascript
myApplication.foo = () => "bar";

myApplication.utils = {
toString() {},
};
```

👍 전역 네임스페이스를 오염시키지 않으면서도 코드와 매개변수를 논리적으로 구성하는 데 도움을 줌
👍 키-값 구조이므로 알아보기 쉬움

## 11.5 중첩 네임스페이스 패턴

객체 리터럴 표기법 패턴을 발전시킨 형태

```javascript
YAHOO.util.Dom.getElementsByClassName("test");
```

👍 다른 패턴에 비해 충돌 위험이 낮음
👍 단일 객체 네임스페이스 패턴과 성능상 차이가 크지 않음

## 11.6 즉시 실행 함수 표현식 패턴

== 익명 함수

```javascript
(() => {
/** */
})();
(function foobar() {
/** */
})();
```

- 애플리케이션의 로직을 캡슐화하여 전역 네임스페이스로부터 보호하는 방법

## 11.9 권장하는 패턴

저자가 권장하는 패턴은 **'객체 리터럴 패턴을 사용한 중첩 네임스페이스 방법'**

> 객체 리터럴 패턴은 단점 자체를 언급하지 않았던것 같음

0 comments on commit 792ba0a

Please sign in to comment.