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, 11 #98

Merged
merged 1 commit into from
Dec 2, 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
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 권장하는 패턴

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

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