javascript on 오늘도 개발을 한다.

[Webpack/Vite 파헤치기] 2. Create React App 내부의 의존성과 환경 설정 꺼내기

Sat, 01 Nov 2025 18:16:27 +0900

서론

앞선 게시물에 이어, CRA 기반의 React App과 Vite 기반의 React App 비교를 위해 먼저 CRA 기반의 React App의 구조 및 내포하고 있는 설정들의 파악이 필요하다고 판단했습니다.
따라서 React App을 eject하여, 내포하고 있던 다양한 dependencies와 config들을 분석하는 시간을 먼저 갖고자 했습니다.
따라서 이번 포스트에서는 React App을 eject 했을 때 드러나는 의존성 및 설정들의 역할과, 최종적으로 그 구조를 도식화하여 살펴볼 예정입니다.

CRA eject시 드러나는 의존성들

CRA로 생성한 React App을 react-scripts eject 명령어를 통해 숨겨진 설정들과 의존성들을 꺼내면(eject) 다음과 같은 의존성들이 추가됨.
크게 요약하면 Babel 관련 종속성, Webpack 관련 종속성(Webpack Loader), CSS/SASS 관련 종속성, ESLint 관련 종속성, 테스트 관련 종속성, 기타 유틸 로 이뤄져 있음

Babel 관련

Babel이란?

ES6 이상의 코드를 이전 환경에 호환되도록 변환하거나, 타입스크립트, React jsx 등 다른 문법의 코드를 변환해주는 툴체인

Webpack 관련

Webpack이란?

webpack : Javascript 기반의 모듈 번들러로, React App의 여러 모듈들을 의존관계끼리 엮어 하나 이상의 번들 정적 에셋으로 번들링하는 툴

로더 #

로더란?

웹팩이 처리할 수 없는 Javascript 파일 이외의 파일들 을 변환할 수 있도록 도와주는 라이브러리로, 파일을 import하거나 로드할 때 사전처리를 수행할 수 있음
- 로더는 체이닝 될 수 있으며, 체인의 각 로더는 각각 (앞선 로더에 의해) 처리된 리소스를 전달 받아 변환을 적용함
- 최종적으로, Webpack은 이러한 체인의 마지막 로더로 부터 Javascript 파일을 넘겨 받기를 기대함
로더는 webpack.config.js의 module.rules 배열에서 지정할 수 있으며, 선언된 역순으로 로더가 적용됨
- 예를 들어 module: { rules: ["style-loader", "css-loader", "sass-loader"]} 라고 선언이 되어있다면, sass-loader -> css-loader -> style-loader 순으로 작업이 이뤄짐

CSS / SASS 관련

browserslist: Babel, Autoprefixer 등 여러 프론트엔드 툴에서 동일한 타깃 브라우저 및 Node.js 런타임 버전을 공유하기 위한 Configuration
- 이를 통해 불필요한 Polyfil, 벤더 프리픽스 등을 줄일 수 있으며, 프론트엔드 툴 간 일관성이 보장됨
- CRA 프로젝트 설정에서는 프로덕션 빌드의 경우 0.2% 이상의 점유율을 지녔으며(>0.2%) 24개월 내 업데이트가 없는 브라우저를 제외하고(not dead) 오페라 미니를 제외한(not op_mini all), 개발 환경에서는 가장 최신 버전의 크롬/파이어폭스/사파리 를 지원 하도록 설정됨
mini-css-extract-plugin : CSS를 포함하고 있는 JS 파일 별로 CSS를 추출해 JS 파일 당 CSS 파일을 생성 하는 웹팩 플러그인으로, css-loader와 함께 사용하기를 권장함
- 다만, 웹팩 엔트리 포인트 또는 initial chunk에서 import 하고 있는 CSS의 경우, (이 플러그인이) 페이지에서 해당 CSS들을 로드하도록 하지 않음
  - 엔트리 포인트: webpack.config.js에서 entry로 설정된 파일
  - initial chunk: 엔트리 포인트의 메인 청크를 의미하며, 엔트리 포인트에 명시된 모든 모듈 및 의존성을 포함하고 있는 청크
- 즉, 엔트리 포인트에 대응되는 CSS 파일의 경우, 자동으로 <link> 태그를 생성하거나 / <link> 태그를 포함한 index.html을 만들기 위해 html-webpack-plugin를 사용해야 함
  - html-webpack-plugin: 웹팩 번들 서빙을 위한 HTML 파일 생성을 간소화 시켜주는 웹팩 플러그인
  If you have any CSS assets in webpack’s output (for example, CSS extracted with the mini-css-extract-plugin) then these will be included with <link> tags in the HTML head.
  ( 만약 Webpack 출력이 CSS 에셋을 포함할 경우, HTML <head>에 <link> 태그로 포함될 것입니다.)
  출처: jantimon/html-webpack-plugin: Simplifies creation of HTML files to serve your webpack bundles
tailwindcss: 유틸리티-우선(utility-first) CSS 프레임워크로, 프레임워크에서 지정한 클래스 명을 사용하면 CSS 유틸리티가 적용됨
- 인라인 스타일과 비슷하지만, 미리정의된 디자인(predefined design)을 사용할 수 있고 호버/포커스 등 상태 및 미디어 쿼리를 사용할 수 있음
postcss: Javascript 플러그인을 사용해 CSS 린팅, 변수 및 믹스인 지원, 최신 CSS 문법의 트랜스파일 등의 기능을 제공하는 변환기
- 내부적으로 CSS -> Parser -> [Plugin 1, Plugin 2, ... ] -> Stringifier -> New CSS로 이어지는 구조를 갖고 있음
  - CSS를 Tokenizer와 Parser를 통해 분해 및 AST화 한 뒤, Plugin 들을 적용시키고 나온 AST를 순수 CSS 문자열로 변환함
- 널리 사용되고 있는 autoprefixer가 대표적인 PostCSS 플러그인임
postcss-flexbugs-fixes : flowbox 이슈 및 크로스-브라우저 이슈를 수정하기 위한 PostCSS 플러그인
postcss-normalize: browserlist 설정에 맞춰 normalize.css 라이브러리 또는 sanitize.css 라이브러리를 사용할 수 있도록 해주는 툴
- normalize.css : HTML 요소에 대해 크로스-브라우저 간 일관된 스타일을 제공하는 CSS 라이브러리
  - nomarlize.css의 내용을 살펴보면, 중첩 리스트(dl, ol, ul)의 margin 없애기(line 36), Firefox에서의 box-sizing 추가 및 border 색상을 상속하도록 정정(line 46) 하는 등의 내용을 포함함
- sanitize.css : normalize.css의 모든 요소들이 포함되어 있으며, 나아가 유용한 기본 설정(useful defaults)을 포함하는 CSS 라이브러리
  - sanitize.css의 내용을 살펴보면, 커서는 불명확한 인터페이스에 힌트를 주기 위해서만 변하도록 하거나(line 37), background-repeat이 기본적으로 반복되지 않도록 하는(line 13) 등의 내용을 포함함
[postcss-preset-env]: 최신 CSS 문법을 브라우저가 이해할 수 있도록 변환하고, 타겟 브라우저 및 런타임에 맞춰 필요한 폴리필을 결정하는 PostCSS 플러그인
- MDN과 Can I Use로부터 버전 별 지원 기능 정보들을 가져와 browserlist를 기반으로 기능의 변환이 필요한지 판단하며, 내부적으로 autoprefixer를 포함해 브라우저 지원 목록에 따라 필요할때만 접두사를 적용하도록 함
- CRA 프로젝트 설정에서는 autoprefixer: { flexbox: 'no-2009' }, stage: 3라고 옵션을 지정하여 최신 및 IE 버전의 flexbox 문법에만 접두사를 추가하도록 하며, 또한 stage 3에 해당하는 CSS 기능들을 변환하도록 설정
  - 참고1) Interactive Playground - PostCSS Preset Env - CSS Tools를 통해 browserlist 옵션 별 변환된 CSS를 확인할 수 있음
  - 참고2) flexbox의 경우, 과거 display:box -> display: flexbox -> display: flex 와 같은 변경을 거친 옵션임 “Old” Flexbox and “New” Flexbox | CSS-Tricks
  - 참고3) CSS 기능의 stage 수준을 확인하고 싶다면 CSS Database - CSS Tools을 확인할 것

ESLint 관련

eslint: Javascript 코드에서 발견된 패턴을 식별 및 보고하는 툴
- 여기서 말하는 “패턴"으로는 문법 오류, 버그를 일으킬 수 있는 사용되지 않는 변수/접근 불가능한 코드 등의 요소, 정해진 코딩 컨벤션을 위반하는 코드 등이 있음
- Espree를 사용해 Javascript 코드를 파싱하며, 패턴을 확인하기 위해 AST를 사용함
- 사람들이 종종 대체제로 오인하는 Prettier와는 다른 작업을 수행하는 툴임: Linter(ESLint)와 Code Formatter(Prettier)
  - Linter는 코드에서 발견되는 잠재적 오류, 안티 패턴 등을 식별하고 경고 하는 도구이고, Code Formatter는 들여쓰기(indent), 줄바꿈(line break) 등의 요소들을 일관되도록 하여 코드 가독성 을 높이는 도구임
eslint-config-react-app: CRA에서 사용되는 ESLint 설정을 포함하고 있는 패키지
- create-react-app/packages/eslint-config-react-app/index.js at main · facebook/create-react-app 에서 그 설정 값들을 확인할 수 있음

테스트 관련

jest: 자바스크립트 테스팅 프레임워크로, 테스트를 찾아 실행하는 테스트 러너 뿐만 아니라 Test Matcher(expect()와 같은 Assertion)그리고 Test Mock(jest.spyOn, jest.mock 등) 프레임워크를 제공
- CRA 프로젝트 설정에서는 <rootDir>/src 내 모든 js/jsx/ts/tsx 파일 중 __test__폴더 내 모든 테스트 파일 또는 *.spec.{확장자}/*.test.{확장자} 파일 에 대해 테스트를 수행하도록 설정되어 있음
babel-jest : 코드 전처리(transform)를 위해 Babel을 사용하도록 하는 Jest의 플러그인
- Javascript/JSX 파일 테스트 전, 전처리 수행
- CRA 프로젝트 설정에서는 babel-preset-react-app 프리셋을 사용하고, 해당 프리셋에서 runtime을 classic(react 17 미만) 또는 automatic(_jsx(react/jsx-runtime)을 사용하는 환경)으로 설정한 트랜스포머를 생성해 사용하는데에 쓰임
jest-resolve: jest 내부에서 배포하는 패키지로, 모듈 경로를 Resolve 하는데 사용되는 AsyncResolver, SyncResolver와 같은 Resolver를 배포
- AsyncResolver - SyncResolver는 이름 그대로 모듈이름을 동기적으로(resolveStubModuleName : string) 또는 비동기적으로(resolveStubModuleNameAsync : Promise) Resolve 할 것인지 차이
jest-watch-typeahead: 파일 이름 또는 테스트 이름으로 테스트들을 필터링해 실행할 수 있는 플러그인

기타 유틸

bfj: Big-Friendly JSON의 약자로, 대형 JSON 데이터 셋용 비동기 스트리밍 함수를 제공
- 만약 큰 JSON 문자열을 파싱하거나, 대규모 데이터 셋을 문자열로 변환할 경우 이벤트 루프를 독점하고, OOM(메모리 부족) 예외를 발생시킬 수 있음
- 이때, BFJ는 비동기 함수, 그리고 사전-할당된 고정-길이 배열을 사용해 이런 문제를 완화하려고 함
- CRA 프로젝트 설정에서는 빌드 시 발생하는 stat(warning, error 등)들을 기록한 bundle-stats.json 파일을 작성하기 위해 사용
camelcase: 대시(-)/점(.)/밑줄(_)/공백( )으로 구분된 문자열을 camelCase 또는 PascalCase로 변환해주는 함수를 제공
- camelCase와 PascalCase 모두, 단어들을 합칠때 공백없이 각 단어의 첫 글자를 대문자로 표기한다는 공통점이 있지만 camelCase는 첫 번째 단어의 첫 글자를 소문자로, PascalCase는 첫 번째 단어를 포함한 모든 단어의 첫 글자를 대문자로 표기한다는 차이가 있음
- CRA 프로젝트 설정에서는 커스텀 Jest 트랜스포머(fileTransform.js)에서 SVG 파일을 React 컴포넌트처럼 가져올 때, SVG 파일 이름을 PascalCase로 처리하기 위해 사용
dotenv: .env 파일로부터 환경 변수들을 불러와, node.js의 process.env 객체에 주입하는 패키지
- .env 파일에는 키=값으로 이루어진 변수들을 두고 사용
- 2년 전부터 dotenv에 "암호화 된" .env 파일 을 지원하고, 크로스-플랫폼 일관성 을 지원하는 dotenvx를 사용하길 권고하고 있음
dotenv-expand: dotenv에 변수 확장(variable expansion) 기능을 추가한 패키지
- 변수 확장: 한 변수에서 다른 변수를 ${이름} 구문을 통해 참조할 수 있는 기능
```
	HOST_URL=http://localhost:3000 
	API_URL=${HOST_URL}/api
```
- CRA 프로젝트 설정에서는 env.js에서 환경 변수들을 설정할 때, .env파일들을 우선순위가 높은대로 배열에 담은 뒤 순회하며 dotenv 를 통해 환경변수들을 불러온 뒤, 그 사이에 존재하는 변수 확장을 처리하기 위해 dotenv-expand로 한 번 더 처리하는 형태로 사용
fs-extra: node.js의 fs 모듈에 포함되어 있지 않은 파일 시스템 메서드를 추가하고, fs 메서드들에 대한 Promise 지원을 추가한 패키지
- fs 모듈의 모든 기능을 포함한채 확장하기 때문에 fs-extra만 가져와 사용하면 됨
- 또한, 모든 fs 메서드들이 Promise를 지원하도록 했기 때문에, 별도의 callback을 넘기지 않을 경우 Promise를 반환함
- ESM(ES Module)도 지원하나(fs-extra/esm), fs 메서드들이 포함되어 있지 않으므로 별도로 import 해주어야 함
- CRA 프로젝트 설정에서는 애플리케이션을 build할 때 사용됨
```
// 1. Yarn 패키지 매니저가 사용되는지 확인하는데 사용
const useYarn = fs.existsSync(paths.yarnLockFile);

// 2. 빌드 디렉토리 내 파일들을 지우는데 사용
fs.emptyDirSync(paths.appBuild);

// 3. `Public` 폴더 내 정적 에셋들을 빌드 디렉토리로 복사하는데에 사용 
fs.copySync(paths.appPublic, paths.appBuild, {
dereference: true,
filter: file => file !== paths.appHtml,
});
```

identity-obj-proxy: ES6 Proxy를 이용한 항등(Identity) 객체를 제공하는 패키지로, CSS 모듈과 같이 Webpack이 처리해주는 import 동작을 모킹하는데 유용함

Proxy: 다른 객체에 대한 프록시를 생성하여, 해당 객체의 기본적인 작업을 가로채고, 재정의할 수 있도록 하는 ES6 문법
- Proxy(obj, handler): Proxy 생성자는 프록시할 다른 객체(obj)와 다른 객체의 어떤 작업을 가로채고 해당 작업을 어떻게 재정의할 지 정의된 객체(hanlder) 두 가지 매개변수를 받음
  - 정의할 수 있는 handler 함수로는 apply(), construct(), get(), set() 등이 있으며, 아래 idObj에서는 객체 프로퍼티에 접근하는 메서드인 get()을 재정의한 handler function을 정의하고 있음
- identity-obj-proxy에서는 아래와 같이, 접근하려는 key 이름을 그대로 반환하는 Proxy 객체를 제공함
```
idObj = new Proxy({}, {
  // 객체 내부 메서드(Object internal methods)인 get 호출을 가로채고 대신 응답하는 handler function
  get: function getter(target, key) {
    if (key === '__esModule') {
      return false;
    }
    return key;
  }
});
```
항등(Identity) 객체: 모든 원소를 자기 자신과 같은 값을 대응시키는 함수인 항등 함수(ex) f(x) = x)처럼, 모든 key에 대해 obj[key] = 'key' (또는 obj.key = 'key')인 객체

// 예시 코드

// jest.config.js
// ...
module.exports = {  
	moduleNameMapper: {  
	'\\.jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$':  
		'<rootDir>/__mocks__/fileMock.js',   
	// CSS 또는 LESS(Leaner Style Sheets) 정적 에셋 모듈 경로에 대해 identity-obj-proxy의 프록시 객체를 대신 사용하도록 설정
	// 즉, 프로젝트 내 사용되는 모든 CSS Module에 대해 className을 `identity-obj-proxy`에서 제공하는 프록시 객체에서 lookup 하도록 설정
	'\\.(css|less)$': 'identity-obj-proxy',
	},  
};

// SomeComponent.js
import React, { Component } from 'react';

// jest와 같은 프레임워크를 통해 컴포넌트를 테스트 할 땐 이미지, CSS와 같은 정적 에셋들이 특별히 유용하진 않음
// 따라서, 이들을 실제처럼 `css-loader`와 같은 툴을 통해 해싱된 클래스 명을 주입하기 보다, 모킹된 프록시를 만들어 className이 일치하는지만 확인하도록 하는 것이 더 안전하고 편리
// 따라서 `identity-obj-proxy`와 같은 모듈이 제공하는 `항등 객체`에서 className을 lookup해 확인하도록 설정
import styles from './App.css'; // CSS Module import

export default class App extends Component {
  render() {
    return (
      <div className={styles.root}>
        <h1 className={styles.hello}>Hello, world!</h1>
      </div>
    );
  }
}

prompts: CLI 프롬프트를 쉽게 만들어주는 패키지
- jest-cli, react-dev-utils에서 의존하는 패키지
react-app-polyfill: Create-React-App 프로젝트에서 일반적으로 사용된 Javascript 기능과 최소 요구 사항에 대한 Polyfill을 포함하는 패키지
- 프로젝트에서 지원하고자 하는 최소 버전의 진입점을 import하면 Create React App 프로젝트를 이용하기 위한 최소 언어 기능을 포함하도록 할 수 있음
```
// 아래와 같은 import문을 프로젝트 진입점('src/index.js')의 첫 번째 줄로 기입해야 함

// 최소 IE 9버전 이상(IE9, IE10, IE11, ...)을 지원하려는 경우
import 'react-app-polyfill/ie9';

// 최소 IE 11버전 이상을 지원하려는 경우
import 'react-app-polyfill/ie11';
```
- 또한, stable한 기능이지만 타겟 브라우저에서 이를 지원하지 않는 경우 이를 제공하는 Polyfill('react-app-polyfill/stable')을 사용할 수 있음 (Create-React-App을 사용하고 있는 경우, 사용자가 정의한 browserlist를 자동적으로 불러와, 타겟 브라우저에서 필요한 폴리필만 가져옴)
react-dev-utils: Create-React-App에서 사용되는 몇가지 유틸리티들을 포함하는 패키지
- react-dev-utils는 단일 엔트리 포인트를 갖고 있지 않으며, 각각의 모듈을 직접 import 해야 하는 형태로 작성되어 있음
- react-dev-utils를 구성하는 주요 모듈 중, CRA 프로젝트에서 사용된 모듈은 다음과 같음
  - InterpolateHtmlPlugin: html-webpack-plugin을 사용해 index.html에 사용자 정의 변수를 삽입할 수 있도록 돕는 웹팩 플러그인
  - InlineChunkHtmlPlugin: 마찬가지로 html-webpack-plugin을 사용해 index.html에 인라인 스크립트 청크를 삽입하는 웹팩 플러그인
    - 즉, <script src="..."> 대신 <script>태그 내부에 직접 코드를 삽입
  - ModuleScopePlugin: 애플리케이션의 소스 디렉토리에서 상대 경로로 가져온(relative import) 파일들을 디렉토리 외부에서 접근하지 못하도록 보장하는 웹팩 플러그인
  - getCSSModuleLocalIdent: index.module.css라는 이름의 CSS 파일에 대해 파일 이름 또는 폴더 이름을 사용한 CSS 모듈 클래스 이름을 생성해주는 style-loader 모듈
  - ModuleNotFoundPlugin: Webpack에서 발생하는, 모듈을 찾을 수 없다는 에러를 알기 쉽게 꾸며주는 웹팩 플러그인
  - ForkTsCheckerWebpackPlugin: 타입스크립트 타입 검사를 별도의 프로세스에서 실행하는 웹팩 플러그인
  - eslintFormatter: Create React App 콘솔 출력과의 통합을 위한 커스텀 ESLint 포매터
  - checkRequiredFiles: 필수 파일 목록을 받아 포함되지 않은 파일들을 chalk를 사용해 터미널에 출력하는 함수
  - formatWebpackMessages: webpack의 stats 객체가 갖고있는 경고 및 에러 메시지를 추출하고 꾸며주는 유틸리티 함수
  - printHostingInstructions: 패키지 경로, public URL 등을 받아, 프로젝트 빌드 후 호스팅 지침을 출력해주는 유틸리티 함수
  - FileSizeReporter: 빌드 전 JS 및 CSS 에셋 파일 크기를 기록해두고, 빌드 후 이들의 크기 비교를 수행하고 출력하는 유틸리티 함수 모음
  - printBuildError: 잘 알려진 빌드 에러들을 꾸며주는 유틸리티 함수
  - evalSourceMapMiddleware: /__get-internal-source로 시작하는 요청에서 웹팩 내부 URL(webpack-internal:///<module-id>)의 module id를 추출해 <source-text><sourceMappingURL><sourceURL> (모듈 원본 소스코드 + 소스맵 URL(base64 인코딩된 소스맵 정보) + 소스 URL )를 반환하는 웹팩 내부 미들웨어 생성 함수
  - noopServiceWorkerMiddleware: ${servedPath}/service-worker.js라는, 이전의 Service Worker 설정을 초기화하는 파일을 제공하는 Express 미들웨어
  - ignoredFiles: 소스 디렉토리 외부의 node_modules를 파일 감시에서 무시하기 위해, 정규표현식을 활용해 파일 경로 패턴을 생성하는 함수
```
// webpackDevServer.config.js
      watch: {
        // Reportedly, this avoids CPU overload on some systems.
        // https://github.com/facebook/create-react-app/issues/293
        // src/node_modules is not ignored to support absolute imports
        // https://github.com/facebook/create-react-app/issues/1065
        ignored: ignoredFiles(paths.appSrc),
      },
```
  - redirectServedPathMiddleware: req.url이 servedPath로 시작하지 않을 경우 ${servedPath}/${req.path}로 리다이렉션 시키는 Express 미들웨어
  - clearConsole: 콘솔 내용을 지우는 유틸리티 함수
  - WebpackDevServerUtils: WebpackDevServer를 위한 웹팩 컴파일러 인스턴스를 생성하거나, 대체 포트를 제공하거나, package.json의 proxy세팅을 기반으로 WebpackDevServer 프록시 설정 객체를 생성하는 등의 작업을 수행하는 유틸리티 함수 모음
  - openBrowser: 주어진 URL과 함께 브라우저를 여는 유틸리티 함수
react-refresh: Fast Refresh라고 부르는, “실행중인 React 애플리케이션에서 컴포넌트를 상태값의 손실 없이 편집할 수 있도록 해주는 기능"을 번들러에 통합시키기 위한 패키지
- How should we set up apps for HMR now that Fast Refresh replaces react-hot-loader? · Issue #16604 · facebook/react 에 따르면, 과거에 사용되던 react-hot-loader라는 패키지를 대체하는 패키지임
- CRA 프로젝트 설정에서는 개발환경이며(isEnvDevelopment), React Refresh를 사용해야 하는 경우(shouldUseReactRefresh) ReactRefreshWebpackPlugin 플러그인을 사용하며, babel-loader에 react-refresh/babel플러그인을 연결함
resolve: node.js의 require.resolve() 알고리즘을 구현하여, 비동기/동기적으로 require.resolve()를 호출할 수 있도록 해주는 패키지
- require.resolve(): require()를 통해 모듈을 탐색할 때, 주어진 경로를 해석하는 함수
  - 대략적인 pseudo algorithm은 문서참고
semver: npm을 위한 시멘틱 버전 관리(Semantic Versioning) 도구.
- Semantic Versioning 2.0.0 | Semantic Versioning에 따르면, 의존성이 많은 시스템에서 의존성 지정이 너무 엄격해 발생할 수 있는 버전 락(Version Lock), 또는 의존성이 너무 느슨하게 지정되어 발생할 수 있는 버전 난잡성(Version Promiscuity)를 방지하기 위해서 시멘틱 버전 관리 사양을 제안함
- 시멘틱 버저닝에서는, X.Y.Z와 같은 체계의 형태로 버전 번호를 관리하는데, 이때 각 부분은 다음을 의미
  - X: 메이저 업데이트. 하위 호환성이 없는 API의 변경 사항
  - Y: 마이너 업데이트. 하위 호환성이 있는(Backward Compatible) API의 추가/변경 사항
  - Z: 패치. API에 영향을 주지않는 버그 수정(Bug Fixes)
- 이러한 시멘틱 버저닝 관리 체계에 있어, 유용한 여러 유틸리티 함수를 제공하는 것이 semver
```
const semver = require('semver')

semver.valid('1.2.3') // '1.2.3'
semver.valid('a.b.c') // null
semver.clean('  =v1.2.3   ') // '1.2.3'
semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // 첫 번째 인자가 두 번째 인자로 주어진 버전 조건을 만족하는가? true
semver.gt('1.2.3', '9.8.7') // 첫 번째 인자가 두 번째 인자보다 높은 버전인가? false
semver.lt('1.2.3', '9.8.7') // 첫 번째 인자가 두 번째 인자보다 낮은 버전인가? true
```

Ejecting 이후 콘솔에 출력된 메세지

// 의존성용 config 파일들 및 스크립트 파일 생성
  Adding \config\env.js to the project
  Adding \config\getHttpsConfig.js to the project
  Adding \config\modules.js to the project
  Adding \config\paths.js to the project
  Adding \config\webpack.config.js to the project
  Adding \config\webpackDevServer.config.js to the project
  Adding \config\jest\babelTransform.js to the project
  Adding \config\jest\cssTransform.js to the project
  Adding \config\jest\fileTransform.js to the project
  Adding \scripts\build.js to the project
  Adding \scripts\start.js to the project
  Adding \scripts\test.js to the project
  Adding \config\webpack\persistentCache\createEnvironmentHash.js to the project

// 감춰져있던 의존성들 추가
Updating the dependencies
  Removing react-scripts from dependencies
  Adding @babel/core to dependencies
  Adding @pmmmwh/react-refresh-webpack-plugin to dependencies
  Adding @svgr/webpack to dependencies
  Adding babel-jest to dependencies
  Adding babel-loader to dependencies
  Adding babel-plugin-named-asset-import to dependencies
  Adding babel-preset-react-app to dependencies
  Adding bfj to dependencies
  Adding browserslist to dependencies
  Adding camelcase to dependencies
  Adding case-sensitive-paths-webpack-plugin to dependencies
  Adding css-loader to dependencies
  Adding css-minimizer-webpack-plugin to dependencies
  Adding dotenv to dependencies
  Adding dotenv-expand to dependencies
  Adding eslint to dependencies
  Adding eslint-config-react-app to dependencies
  Adding eslint-webpack-plugin to dependencies
  Adding file-loader to dependencies
  Adding fs-extra to dependencies
  Adding html-webpack-plugin to dependencies
  Adding identity-obj-proxy to dependencies
  Adding jest to dependencies
  Adding jest-resolve to dependencies
  Adding jest-watch-typeahead to dependencies
  Adding mini-css-extract-plugin to dependencies
  Adding postcss to dependencies
  Adding postcss-flexbugs-fixes to dependencies
  Adding postcss-loader to dependencies
  Adding postcss-normalize to dependencies
  Adding postcss-preset-env to dependencies
  Adding prompts to dependencies
  Adding react-app-polyfill to dependencies
  Adding react-dev-utils to dependencies
  Adding react-refresh to dependencies
  Adding resolve to dependencies
  Adding resolve-url-loader to dependencies
  Adding sass-loader to dependencies
  Adding semver to dependencies
  Adding source-map-loader to dependencies
  Adding style-loader to dependencies
  Adding tailwindcss to dependencies
  Adding terser-webpack-plugin to dependencies
  Adding webpack to dependencies
  Adding webpack-dev-server to dependencies
  Adding webpack-manifest-plugin to dependencies
  Adding workbox-webpack-plugin to dependencies

Updating the scripts

Configuring package.json
  Adding Jest configuration
  Adding Babel preset

참고

각 의존성들의 Github Repository 및 공식 문서

[Webpack/Vite 파헤치기] 1. Create React App의 Deprecated 발표

Thu, 29 May 2025 23:50:07 +0900

서론

SSAFY 과정에서 Webpack(Create React App) 기반의 React App과 Vite 기반의 React App의 개발 서버 구동 및 빌드시간에 현저한 격차가 있음을 확인했습니다.
하지만, Create React App의 경우, Webpack 뿐만 아니라 내포한 다른 추가적인 라이브러리들이 있기 때문에 명확한 비교가 아니라는 것을 깨닫게 되었습니다.
따라서 최대한 여러 플러그인, 라이브러리들을 배제하고 비슷한 환경을 구성해 테스트를 해야 겠다는 생각이 들었습니다.
올해 2월, React측에서 CRA(Create-react-app)이 deprecated되었다고 발표했습니다.(Sunsetting Create React App – React)
따라서 발표 이후, 새로운 React App을 생성하는데에 다른 프레임워크들을 사용하기를 권장하고 있습니다. 또한, 현재 CRA기반의 React App들도 다른 프레임워크나 빌드 툴로 마이그레이션 하기를 권장하고 있습니다.
아래 내용은 위 React의 Deprecated 발표를 번역한 내용입니다.

CRA의 대체 프레임워크

Next.js

npx create-next-app@latest

Vercel에서 관리중인 풀스택 프레임워크 입니다.

React Router

npx create-react-router@latest

Vite와 결합하여 풀스택 프레임워크를 만들 수 있는 라우팅 라이브러리 입니다.

Expo

npx create-expo-app@latest

Expo에서 관리중인 풀스택 프레임워크로, 네이티브 UI를 갖춘 범용 Android, iOS 및 웹 앱을 만들수 있는 프레임워크 입니다.

빌드 툴의 한계

CRA와 같은 빌드 툴은 기본적으로 dev 서버, 린팅, production 빌드 등에 대한 설정이 되어있어 React App을 구축하기 편리했습니다. 하지만, 이러한 빌드 툴들은 실제 Production App을 빌드하는데 있어 필요한 라우팅, 데이터 페칭, 코드 스플리팅 등의 문제에 대한 해결책을 필요로 합니다. 따라서 React 측에서는 상기한 프레임워크를 사용하기를 권장하고 있습니다.

라우팅

CRA에는 어떠한 라우팅 솔루션이 포함되어 있지 않아, React Router 또는 Tanstack Router와 같은 라우팅 라이브러리의 도움을 받아 라우팅을 해야 합니다.

데이터 페칭(데이터 불러오기)

export default function Dashboard() {
  const [data, setData] = useState(null);

  // ❌ Fetching data in a component causes network waterfalls
  useEffect(() => {
    fetch('/api/data')
      .then(response => response.json())
      .then(data => setData(data));
  }, []);

  return (
    <div>
      {data.map(item => <div key={item.id}>{item.name}</div>)}
    </div>
  )
}

CRA에는 특정한 데이터 페칭 솔루션이 포함되어 있지 않습니다. 따라서 보통 effect내부에서 fetch API와 같은 기능을 사용해 데이터를 불러오는데, 이는 컴포넌트 렌더링 후 데이터를 불러와 네트워크 워터폴이 발생할 수 있습니다.

네트워크 워터폴: 네트워크 요청이 병렬적으로 이뤄지지 않고, 순서대로 이루어져 페이지 컨텐츠를 볼 수 있는데까지 소요되는 시간이 늘어나는 현상
위 코드에서도 컴포넌트 함수 코드 불러오기 -> 컴포넌트 함수 실행 -> 컴포넌트 함수 내부 effect의 fetch 함수 실행 -> fetch를 통해 불러온 데이터 기반으로 렌더링 으로 이어지는 일련의 과정이 순차적으로 실행될 것임을 예상할 수 있음

export async function loader() {
  const response = await fetch(`/api/data`);
  const data = await response.json();
  return data;
}

// ✅ Fetching data in parallel while the code is downloading
export default function Dashboard({loaderData}) {
  return (
    <div>
      {loaderData.map(item => <div key={item.id}>{item.name}</div>)}
    </div>
  )
}

이러한 문제를 해결하기 위해 미리 데이터를 페칭(prefetch)하는 옵션을 제공하는 React Query, SWR, Apollo, Relay와 같은 라이브러리의 도움을 받을 수 있습니다. 특히 이러한 라이브러리들은 라우팅의 loader 패턴과 결합하여, 라우팅 레벨에서의 데이터 종속성을 지정할 경우 가장 적합하게 작동합니다. 위 코드의 경우, 라우터가 라우트 렌더링 이전 데이터를 불러와 “렌더링에 필요한 데이터"와 “라우트"를 동시에 가져오도록, 즉 병렬 처리를 하도록 할 수 있습니다.

코드 스플리팅

CRA에는 특정한 코드 스플리팅 솔루션이 포함되어 있지 않아, React App이 단일 번들 파일로 제공됩니다. 이는 사용자가 필요하지 않는 코드들까지 다운받게 하므로, 연관된 코드들끼리 묶인 번들로 분할하도록 해 앱 로딩에 걸리는 시간을 줄이는게 좋습니다.

import { lazy } from 'react';

// lazy 함수에는 React 컴포넌트를 resolve하는, Promise와 같은 thenable 객체를 인자로 넘깁니다.
// 이후 `lazy 함수로 감싼 컴포넌트`를 처음 렌더링하려고 할 때 React는 렌더링을 시작합니다.
const MarkdownPreview = lazy(() => import('./MarkdownPreview.js'));

React에서는 이를 위해 React.lazy 기능을 제공하지만, 이는 컴포넌트가 렌더링 될 때까지 코드를 페칭하지 않으므로 네트워크 워터폴을 발생시킬 수 있습니다. 더 최적의 방식으로 이를 해결하려면 라우터를 통해 코드 다운로드와 함께 코드 페칭을 병렬로 수행하는 방식을 적용하는게 좋습니다.

좀 더 자세히 말하자면, 컴포넌트 코드 다운로드와 함께, 컴포넌트와 연관된 loader, action등의 함수의 실행도 병렬적으로 수행한다는 것입니다.

import Home from './Home';
import Dashboard from './Dashboard';

// lazy 설정된 라우트들은 해당 라우트로 이동할 때 컴포넌트의 코드를 다운로드 합니다.
// 각 라우트들은 지정된 컴포넌트(라우트 모듈)들을 동적 import한 결과를 반환합니다.
const router = createBrowserRouter([
  {path: '/', lazy: () => import('./Home')},
  {path: '/dashboard', lazy: () => import('Dashboard')}
]);

// 라우트 모듈 내부에서는 라우트에 대해 정의하고 싶은 속성들을 export 합니다.
export async function loader({ request }) {
  let data = await fetchData(request);
  return json(data);
}
export function Component() {
  let data = useLoaderData();
  return (
    <>
      <h1>You made it!</h1>
      <p>{data}</p>
    </>
  );
}
export function ErrorBoundary() {
  let error = useRouteError();
  return isRouteErrorResponse(error) ? (
    <h1>
      {error.status} {error.statusText}
    </h1>
  ) : (
    <h1>{error.message || error}</h1>
  );
}

예시로 React Router에서 제공하는 lazy 기능을 사용하면 설정된 라우트를 동적으로 지연 로딩하여 초기 번들의 크기를 줄일 수 있습니다.

참고

[Javascript] Prototype 알아보기

Thu, 18 Jul 2024 11:47:14 +0900

서론

CS 스터디에서 7월 9일 발표한 Prototype에 대해 정리한 문서를 블로그에 공유하고자 한다.

`prototype` in Javascript

객체지향 프로그래밍 언어들에서 기존 코드를 확장하는 방식 중 대표적인 방식으로 상속(Inheritance)이 있습니다.
자바스크립트에서는 이러한 상속을 객체를 사용해 구현합니다.

프로토타입 체인

각 객체들은 프로토타입(prototype) 이라는 다른 객체에 대한 내부적인 링크를 갖고 있습니다. 그리고 그 프로토타입 객체는 또 다른 자체 프로토타입을 가지며, 프로토타입 체인이라 부르는 이러한 연결은 null을 프로토타입으로 가지는 객체에 도달할 때 까지 계속됩니다.

이 null은 프로토타입 체인의 최종 링크 역할을 합니다.

프로토타입 체인을 이루는 객체 중 어떤 멤버든 변경할 수 있으며, 런타임에 프로토타입을 교체하는 것이 가능하므로 정적 디스패치(static dispatching)와 같은 개념은 자바스크립트에 존재하지 않습니다.

정적 디스패치(static dispatch): 다형성의 구현 방식 중 하나로, 컴파일 시간 에 어떤 메서드나 함수의 구현을 사용할 지 선택하는 방법입니다. 이에 대응되는 개념으로는 런타임 시간에 이를 결정하는 동적 디스패치(dynamic dispatch)가 있습니다.
- C++의 template이 이러한 예이며, Rust 역시 아래와 같은 코드가 있다고 할때, 컴파일러가 전달된 인자의 타입을 보고, 그에 맞는 코드를 따로 실행하게 됩니다.

// rust의 trait은 타입 간의 공통된 사항들을 정의합니다.
// (Java의 Interface와 유사하지만 더 강력한 개념)
// 예를 들어, 아래 Speak이라는 trait을 가지는 타입은 반드시 speak 함수를 가져야 합니다.
trait Speak {
    fn speak(&self);
}

struct Cat;

// Cat 타입에 Speak trait을 붙이는 코드입니다.
impl Speak for Cat {
	// Speak trait에 포함된 'speak' 함수를 구현해야 합니다.
    fn speak(&self) {
        println!("Meow!");
    }
}

// Speak trait을 갖는 타입을 인자로 받는 함수
fn talk<T: Speak>(pet: T) {
    pet.speak();
}

fn main() {
    let pet = Cat;
    talk(pet);
}

코드 출처: Static dispatch - Wikipedia

프로퍼티 상속하기

자바스크립트의 객체는 자유롭게 프로퍼티를 추가 및 제거할 수 있는, property로 이뤄진 동적인 가방이라고 할 수 있습니다.
객체에서 프로퍼티를 탐색할 때는 현재 객체가 가진 프로퍼티(own property) 뿐만 아니라, 프로토타입 체인의 끝까지 탐색하며 이를 구성하는 프로토타입들에서도 찾는 형태로 동작합니다.
다음 코드는 후술할 프로토타입 접근 및 설정 방법 중 대표적인 방식인 obj.__proto__ 구문을 통해 객체의 프로토타입을 설정하고, 프로토타입 체인을 이루는 코드입니다.

const o = {
  a: 1,
  b: 2,
  // __proto__ 프로퍼티를 통해 프로토타입을 설정합니다.
  // 이때, 다른 객체 변수명을 할당하거나, 객체 리터럴을 할당할 수 있습니다.
  __proto__: {
    b: 3,
    c: 4,
    __proto__: {
      d: 5,
    },
  },
};
// 이렇게 되면, 객체 o를 이루는 프로토타입 체인은 다음과 같습니다.
// { a: 1, b: 2 } ---> { b: 3, c: 4 } ---> { d: 5 } ---> Object.prototype ---> null

console.log(o.a); // 1
// o에는 내부 프로퍼티인 a가 존재하므로 해당 값을 가져옵니다.

console.log(o.b); // 2
// o와 o의 프로토타입 모두 b를 가지고 있습니다.
// 이러한 경우, 프로토타입 체인에서 더 가까운 위치에 존재하는 프로퍼티를 우선합니다.
// 즉, 여기서는 o의 내부 프로퍼티 b의 값인 2를 가져옵니다.

// 이처럼 프로토타입 체인 상에서 동일한 이름의 프로퍼티가 존재할 경우
// 프로토타입 체인에서 더 가까운 프로퍼티를 찾으면 이후 프토토타입들을 더 탐색하지 않는 것을
// 프로퍼티 섀도잉(Property Shadowing)이라고 합니다.

console.log(o.c); // 4
// o에는 c 프로퍼티가 없기 때문에, 프로토타입 체인을 탐색합니다.
// o.[[prototype]]에 c가 존재하기 때문에, 해당 값인 4를 가져옵니다.

console.log(o.e); // undefined
// o에는 e 프로퍼티가 없기 때문에, 프로토타입 체인을 탐색합니다.
// o.[[prototype]]을 탐색하나, 이 역시 e 프로퍼티가 없습니다.
// o.[[prototype]].[[prototype]]을 탐색하나, 이 역시 e 프로퍼티가 없습니다.
// o.[[prototype]].[[prototype]].[[prototype]], 즉 Object.prototype을 탐색하나, 이 역시 e 프로퍼티가 없습니다.
// Object.prototype의 프로토타입은 null이므로, 프로토타입 체인 탐색을 종료합니다.
// 프로퍼티를 찾지 못했기 때문에, undefined를 반환합니다.

위 구조를 그림으로 표현하면 아래와 같습니다.

메서드 상속하기

자바스크립트에서는 클래스-기반 언어들에 존재하는 메서드라는 개념이 존재하지 않으며, 대신 프로퍼티 형태로 객체에 함수를 추가할 수 있습니다.
이와 같은 방식으로 상속한 함수는 상기한 프로퍼티들의 동작방식 대로 동작하며, 마찬가지로 프로퍼티 섀도잉이 이뤄집니다.
유의할 점은, 상속된 함수가 실행될 경우 해당 함수 내부의 this 값은 해당 함수를 지닌 프로토타입 객체가 아닌 함수를 상속받은 객체 를 가리킵니다.

const parent = {
	value: 1,
	add() {
		return this.value += 1;
	}
}

const child = {
	__proto__ : parent
}

parent.add(); // 2
parent.add(); // 3

child.add(); // 4
// child.add() 를 호출한 순간, 프로토타입 체인을 탐색하며 add 함수를 찾습니다.
// 그리고 add 함수 내부의 this는 child를 가리키게 됩니다.
// 이때, child는 value 프로퍼티를 갖고있지 않기 때문에, 프로토타입 체인을 탐색하며 value 프로터피를 찾습니다.
// 그리고 parent의 value 프로퍼티 값인 3을 가져와 1을 더하고, this.value에 할당합니다.
// 따라서 child 역시 내부 프로퍼티인 value를 갖게되며, 이 값은 4가 됩니다.
/ { value: 4,  __proto__: { value: 3, add: [Function] } }

parent.add(); // 4
child.add(); // 5
// 앞선 child.add()로 child 역시 value 프로퍼티를 갖게 되었으므로 
// child.value가 parent.value를 가리게되고(프로퍼티 섀도잉), 
// child.value 값인 4에 1을 더한 5를 반환합니다.

`생성자 함수(Constructor)`

프로토타입을 활용한 생성자 함수 개선

또한 프로토타입은 객체를 생성하는 생성자 함수에서, 함수를 통해 생성된 인스턴스들이 가지는 프로퍼티를 지정하는데 사용할 수 있습니다.
value라는 값과 method라는 함수를 가지는 객체 여럿을 생성해야 한다고 합시다. 단순히 구현한다면 다음과 같이 구현할 수도 있습니다.

const boxes = [
  { value: 1, method() { return this.value; } },
  { value: 2, method() { return this.value; } },
  { value: 3, method() { return this.value; } },
];

이는 각 인스턴스 마다 동일한 작업을 수행하는 자체 함수 프로퍼티가 있는 형태로, 함수들이 중복되고 불필요한 형태입니다.
method 함수를 프로토타입으로 옮긴다면 어떨까요?

const boxPrototype = {
  method() {
    return this.value;
  },
};

const boxes = [
  { value: 1, __proto__: boxPrototype },
  { value: 2, __proto__: boxPrototype },
  { value: 3, __proto__: boxPrototype },
];

이젠 모든 Box들이 똑같은 함수를 참조하므로, 중복이 없어지고 메모리를 덜 사용할 것입니다. 하지만 Box를 생성할 때 마다 __proto__를 직접 지정한다는 불편함은 계속 존재합니다.
이럴때, 생성자 함수를 만들고 해당 함수의 프로토타입에 method 함수를 추가한다면 더 간단화시킬 수 있습니다.

// 생성자 함수
function Box(value) {
  this.value = value;
}

//Box() 생성자로 생성된 인스턴스들은 다음 프로퍼티를 갖습니다.
Box.prototype.method = function () {
  return this.value;
};

const boxes = [new Box(1), new Box(2), new Box(3)];

생성자 함수로 생성된 모든 인스턴스들은 자동으로 생성자 함수의 prototype 프로퍼티를 프로토타입으로 갖습니다. 따라서 프로토타입에 존재하는 프로퍼티들을 공유하게 됩니다.

const box = new Box(1);
// 인스턴스들이 생성 된 후에도 Box.prototype를 수정해 동작을 변경할 수 있습니다.
Box.prototype.getValue = function () {
  return this.value + 1;
};
box.method(); // 2

추가로 Constructor.prototype(Constructor는 생성자 함수, 여기서는 Box)는 모든 인스턴스들의 prototype과 동일한 객체를 참조하므로, Constructor.prototype을 수정해 해당 인스턴스들의 동작을 변경할 수도 있습니다.

다만 이러한 행위를 할 경우, 재할당 이전에 생성된 인스턴스들의 프로토타입과 재할당 이후에 생성된 인스턴스들의 프로토타입이 다른 객체를 가리키게 되고, constructor 프로퍼티를 명시적으로 재설정하지 않을 경우 인스턴스에서 이를 추적할 수 없게 되는 단점이 있어 권장되지 않습니다.

console.log(Box.prototype.constructor);
// ƒ Box(value) {
//   this.value = value;
// }

console.log(Object.getOwnPropertyNames(Box.prototype);
// (2) ['constructor', 'method']

그리고 Constructor.prototype에는 생성자 함수 자체를 참조하는 constructor라는 프로퍼티가 존재합니다.
이를 통해 해당 생성자 함수로 생성된 모든 인스턴스에서 원래 생성자 함수를 접근할 수 있습니다.

주의사항

function WrongBox(value) {
    this.value = value;
    return {d: this.value};
}

WrongBox.prototype.method1 = function () {return this.value};
WrongBox.prototype.method2 = function () {return this.d};

const abcd = new WrongBox(10);

abcd.method1(); // TypeError: abcd.method1 is not a function

추가로, 생성자 함수가 원시 타입이 아닌 값을 반환할 경우, 해당 값이 new 표현식의 결과가 됩니다.
따라서 이러한 경우 prototype이 올바르게 바인딩 되지 않을 수 있습니다.

리터럴의 암시적 생성자

자바스크립트에서 몇몇 리터럴 구문은 인스턴스의 prototype을 암시적으로 설정해 생성합니다.

// 객체 리터럴(`__proto__` 프로퍼티를 기입하지 않은)은 자동으로 `Object.prototype`을 프로토타입으로 갖습니다.
const object = { a: 1 };
Object.getPrototypeOf(object) === Object.prototype; // true

// 배열 리터럴은 자동으로 `Array.prototype`을 프로토타입으로 갖습니다.
const array = [1, 2, 3];
Object.getPrototypeOf(array) === Array.prototype; // true

// 정규식 리터럴은 자동으로 `RegExp.prototype`을 프로토타입으로 갖습니다.
const regexp = /abc/;
Object.getPrototypeOf(regexp) === RegExp.prototype; // true

추가로, 일부 빌트-인 생성자의 prototype 프로퍼티는 그들 스스로의 인스턴스를 가리킵니다. 예를 들어 Number.prototype는 숫자 0을, Array.prototype은 빈 배열을, RegExp.prototype은 /(?:)/을 가리킵니다.

생성자 함수의 프로토타입 체인

생성자 함수로 생성된 인스턴스는 Constructor.prototype을 프로토타입으로 갖고, Constructor.prototype은 순수 객체이므로 다음과 같은 프로토타입 체인을 구성하게 됩니다.

function Constructor() {}

const obj = new Constructor();
// obj ---> Constructor.prototype ---> Object.prototype ---> null

만약 Constructor 함수의 프로토타입으로 다른 함수의 프로토타입을 연결한다면, 프로토타입 체인은 더 길어집니다. 이는 Class에서의 extends 구문와 유사합니다.

function Constructor() {}
function Extender() {}
Object.setPrototypeOf(Constructor.prototype, Extender.prototype);

const obj = new Constructor();
// obj ---> Constructor.prototype ---> Extender.prototype ---> Object.prototype ---> null

프로토타입 접근 및 설정

구문 생성자을 통한 객체 생성

const o = { a: 1; }
const p = { b: 2, __proto__: o };
// 위처럼 객체 리터럴 이니셜라이저에서 __proto__ 프로퍼티를 통해 프로토타입을 지정하는 방식이
// `Object.prototype.__proto__` 을 사용하는 것보다 표준화 및 최적화 되어있습니다.

중괄호({})로 묶인 프로퍼티 이름-값 쌍 목록인 객체 이니셜라이저에서 __proto__ 프로퍼티를 통해 프로토타입을 지정하는 방식입니다.
이때 __proto__ 프로퍼티가 객체가 아닌 값을 가리킬 경우 별도의 Exception 없이 프로토타입 연결에 실패합니다.

생성자 함수를 통한 객체 생성

function Graph() {
  this.vertices = [];
  this.edges = [];
}

Graph.prototype.addVertex = function (v) {
  this.vertices.push(v);
};

const g = new Graph();

생성자 함수는 초기 자바스크립트부터 사용되었기 때문에 표준적이고, JIT 최적화가 가능하다는 장점이 있습니다.
하지만, 이 방식으로 추가된 메서드는 열거 가능(enumerable)하므로 클래스 구문 또는 빌트-인 메서드의 동작 방식과 일치하지 않아 정상 동작하지 않을 수 있습니다.

`Object.create()`를 통한 객체

const a = { a: 1 };
// a ---> Object.prototype ---> null

const b = Object.create(a);
// b ---> a ---> Object.prototype ---> null
console.log(b.a); // 1 (상속된 값)

const c = Object.create(b);
// c ---> b ---> a ---> Object.prototype ---> null

const d = Object.create(c, { abc: 10});

Object.create() 함수를 통해 객체를 생성할 경우, 해당 함수에 첫 번째로 넘겨진 인수가 생성된 객체의 프로토타입으로 지정됩니다.
참고로 두 번째 인자를 사용하면 생성될 새로운 객체의 각 속성 값을 정확히 지정할 수 있습니다.

이는 객체 리터럴에서 불가능한 열거할 수 없는 프로퍼티 생성을 할 수 있지만, 객체 리터럴보다 오류가 발생하기 쉽고 느릴 수 있습니다.

클래스를 통한 객체 생성

class Rectangle {
  constructor(height, width) {
    this.name = "Rectangle";
    this.height = height;
    this.width = width;
  }
}

class FilledRectangle extends Rectangle {
  constructor(height, width, color) {
    super(height, width);
    this.name = "Filled rectangle";
    this.color = color;
  }
}

const filledRectangle = new FilledRectangle(5, 10, "blue");
// filledRectangle ---> FilledRectangle.prototype ---> Rectangle.prototype ---> Object.prototype ---> null

높은 가독성과 유지보수성을 제공하는 클래스 구조는 프로토타입 상속에서는 존재하지 않는 개인 속성(Private property)을 갖고 있지만, 전통적인 생성자 함수에 비해 덜 최적화 되어있고 ES6에 이르러서야 등장했기 때문에 이전 환경과 호환되지 않을 수 있습니다.

개인 속성(Private property): 접두어 #로 시작하는 프로퍼티로, 클래스 외부에서 합법적으로 참조할 수 없는 프로퍼티입니다.

`Object.set/getPrototypeOf()`를 사용한 프로토타입 지정 및 접근

const obj = { a: 1 };
const anotherObj = { b: 2 };
// obj의 프로토타입을 anotherObj로 설정
Object.setPrototypeOf(obj, anotherObj);
// obj ---> anotherObj ---> Object.prototype ---> null

Object.getPrototypeOf(anotherObj) // {b: 2} << anotherObj

Object에 존재하는 정적 메서드인 setPrototypeOf(obj, prototype) 함수와 getPrototypeOf(obj) 함수를 통해 특정 객체의 프로토타입을 설정하거나, 가져올 수 있습니다.
대부분의 JS 엔진은 프로토타입을 동적으로 수정시 프로토타입 체인에 적용된 최적화가 중단될 수 있기 때문에, 가능한 생성 중에 프로토타입을 설정하는 것이 좋습니다.

`proto` 접근자를 사용한 프로토타입 지정 및 접근

주의: Object.prototype.__proto__는 표준이 아니며, 많은 JS 엔진에서 구현하고 있긴 하지만 Deprecated 되어있으므로 setPrototypeOf 또는 getPrototypeOf를 사용하는 것이 권장됩니다. #

const obj = {};

obj.__proto__ = { barProp: "bar val" };
console.log(obj.__proto__); // {barProp: 'bar val'}

성능 관련

프로퍼티 순회 및 조회시 다음과 같이 동작하기 때문에, 성능을 고려해 코드를 작성하는게 좋습니다.

존재하지 않는 프로퍼티에 접근하려 하면 항상 프로토타입 체인 전체를 순회하게 됩니다.
객체의 프로퍼티들을 순회할 때, 모든 열거 가능한 프로퍼티들이 열거됩니다.
프로퍼티를 전체 프로토타입 체인이 아닌, 자체 프로퍼티에서 찾고 싶다면 Object.hasOwn() 메서드를 사용해야 합니다.(Object.prototype.hasOwnProperty 가 아닌)
null이 프로토타입으로 지정되어 있지 않고, 프로토타입 체인 아래로 재정의되지 않은 경우, 모든 객체는 Object.prototype의 hasOwnProperty()를 상속받습니다.

`class`와 `prototype`

자바스크립트에서 클래스가 구현되는 방식 역시 프로토타입 모델을 기반으로 하고 있으며, 클래스는 프로토타입을 추상화합니다.
즉, 기존에 존재하는 프로토타입-기반 상속의 문법적 설탕(Syntactical Sugar)이라고 할 수 있습니다. 다만, 클래스에서만 사용할 수 있는 구문도 존재하는데, static 프로퍼티 및 메서드, Private Property과 같은 문법이 바로 그것입니다.

`class`와 `생성자 함수`

또한 클래스와 생성자 함수 역시 종종 비교되는데, 클래스가 실제로는 런타임 시간에 생성자 함수로 동작하기 때문입니다.
심지어 prototype과 달리, 생성자 함수도 static 프로퍼티 및 메서드, Private Property를 가질 수 있습니다.

class Person {
	// 클래스의 스태틱 메서드
	static greetStatic() {
		return 'Static hello!';
	}
	// 클래스의 프라이빗 프로퍼티와 해당 값을 접근하는 getter
	#privateField = 20;
	getField () {
		return this.#privateField;
	}
}

function FuncPerson() {
	// 생성자 함수의 프라이빗 프로퍼티
	var privateField = 20;
	// 프라이빗 프로퍼티를 접근하는 getter
	this.getField = function () { return privateField; }
}
// 생성자 함수의 스태틱 함수
FuncPerson.greetStatic = function () { return 'Static Hello!'; }

console.log(Person.greetStatic()); // "Static hello!"
console.log(FuncPerson.greetStatic()); // "Static hello!"

console.log(new Person().getField()); // 20
console.log(new FuncPerson().getField()) // 20

따라서 자바스크립트의 클래스는 생성자 함수와 프로토타입-기반 상속을 종합한 문법적 설탕이라 할 수 있습니다.

왜 `Javascript`는 `프로토타입 기반(prototype-based)`을 채택했을까?

결론부터 말하자면, Javascript는 Java의 보조 수단으로써 설계되었기 때문입니다.
넷스케이프에 재직하며, 브라우저인 넷스케이프 네비게이터에서 사용할 스크립트 언어를 개발을 맡은 브랜든 아이크는, Scheme 언어를 브라우저에 구현하라는 지시를 받았었습니다.
하지만 넷스케이프가 웹에서 Java를 구현하기 위해 썬 마이크로시스템즈와 계약을 체결하고, 이를 위한 언어인 자바스크립트(이전에는 Mocha -> LiveScript로 이름이 계속 바뀌었다.)를 개발하게 되었습니다.
따라서 Java에 존재하는 Class를 자바스크립트에 포함하는 것이 허용되지 않았고, 자바스크립트는 이를 대체할 객체 지향 모델이 필요했고 브랜든 아이크는 프로토타입 기반 상속을 구현했습니다.
이는 브랜든 아이크의 블로그에 등록된 글 내용에서도 확인할 수 있습니다.

넷스케이프 2, 3 시절에는 Javascript를 최소화하고, DOM을 구현하며 “진짜 프로그래밍"은 Java에 맡겨야 한다는 큰 압박을 받았습니다.
(during Netscape 2 and 3 days I was under great pressure to minimize JS-the-language, implement JS-the-DOM, and defer to Java for “real programming” )
(중략)
따라서 Javascript를 최소화하기 위해, 명시적 프로토타입-기반 위임을 추가해 사용자가 단일 프로토타입 네임스페이스에서 빌트-인 메서드를 자신만의 메서드로 보완할 수 있도록 했습니다.
(Therefore in minimizing JS-the-language, I added explicit prototype-based delegation, allowing users to supplement built-in methods with their own in the same given single-prototype namespace.)
출처: JavaScript 1, 2, and in between – Brendan Eich

참조

[Javascript] 모듈 시스템들 알아보기

Wed, 03 Jul 2024 14:24:26 +0900

서론

CS 스터디에서 7월 2일 발표한 모듈 시스템에 대해 정리한 문서를 블로그에 공유하고자 한다.

Module in Javascript

Javascript에서 모듈이란, 다른 프로그래밍 언어의 모듈처럼, 커진 자바스크립트 코드들을 여러 파일로 분리하는 것을 말합니다.
초기에는 자바스크립트 코드들이 크기도 작고 단순한 작업을 수행했기 때문에 코드의 분리를 필요로 하지 않았지만, 자바스크립트가 완전한 애플리케이션을 실행할 수 있게 되고, 이에 따라 코드의 크기도 커지고 복잡해졌습니다.
특히 기존의 경우, <script> 태그를 통해 여러 자바스크립트 파일을 불러올 수 밖에 없었는데, 이들은 전역 네임스페이스를 공유하기 때문에 이전 스크립트의 변수를 뒤집어쓰는 등 혼동을 초래하기 쉬웠습니다.
따라서 이들을 보완하고자, 자바스크립트를 모듈화 하는 방법에 대해 여러 매커니즘이 등장하게 되었습니다.
이러한 모듈 시스템으로는 주로 AMD, CommonJS, UMD, ESM 4개의 시스템이 주로 사용됩니다.
상세하게는, AMD, CommonJS, UMD와 같은 비표준 시스템이 등장해 사용되다가, ES2015(ES6)에 ESM(ES Modules)가 등장하므로써 모듈 시스템이 표준으로 자리잡게 되었습니다.
2018년 Firefox 60이 등장한 이후, 모든 주요 브라우저들은 ES Module을 지원하게 되었으며 CommonJS를 기본적으로 지원하는 Node.js 역시 12버전 부터 ESM를 지원하기 시작했으며, 현재 완전한 지원(fully-support)을 제공하고 있습니다.

Node.js fully supports ECMAScript modules as they are currently specified and provides interoperability between them and its original module format, CommonJS.

Modules: ECMAScript modules | Node.js v22.3.0 Documentation (nodejs.org)

`AMD`

Asynchronous module definition(비동기 모듈 정의), 줄여서 AMD란 비동기적으로 모듈과 그 종속성을 불러올 수 있도록 모듈을 정의하는 메커니즘을 말합니다.

위 그림처럼, AMD 방식은 불러올 파일들 간에 종속성이 존재하더라도 이들을 순서대로 로딩하지 않고 모두 개별적으로 로딩할 수 있습니다.
AMD는 전역 변수(또는 자유 변수)로 사용할 수 있는 함수인 define()과, CommonJS와의 상호운용성을 제공하기 위해 유사한 형태의 exports와 require() 인터페이스를 제공합니다. (다만, 보통 define()을 사용하는 것이 더 선호됩니다.)

자유 변수: 함수에 사용되는 변수 중 지역 변수 또는 해당 함수의 매개 변수가 아닌 변수를 의미합니다.
알려진 AMD 구현체로는 Dojo Toolkit, RequireJS 등이 있습니다.

API 사양 #

`define()` 함수

전역변수로 사용할 수 있는 이 함수는 일종의 네임스페이스 역할을 해, 모듈에서 사용하는 변수와 전역 변수를 분리하는 역할을 해주는 함수입니다. 이를 통해 브라우저 환경의 Javascript에는 존재하지 않는 파일 스코프를 대신할 수 있습니다.
define() 함수는 다음과 같은 함수 시그니처를 가지며, 각 인수들은 다음을 뜻합니다.

define(id?, dependencies?, factory);

id
- 모듈을 식별하는데 사용되는 인수로, 문자열 리터럴입니다.
- 선택 사항이며, 이 값이 주어지지 않으면 로더가 요청하는 <script> 태그의 src 값(id)를 기본 id로 설정합니다.
  - 만약 명시할 경우, 모듈 id는 반드시 최상위 또는 절대 id(절대 경로) 여야 합니다.
- 모듈 id는 정의중인 모듈을 식별하는데 사용할 수 있고, 종속성 배열 인수에도 사용됩니다. AMD의 모듈 id는 CommonJS 모듈 식별자에서 허용되는 것의 상위 집합입니다.
  - 모듈 식별자는 /(슬래쉬)로 구분되는 용어들(terms)의 문자열입니다.
  - 용어는 카멜 케이스 식별자, . 또는 .. 여야 합니다.
  - 모듈 식별자는 ".js"와 같은 파일이름 확장자를 가질 수 없습니다.
  - 모듈 식별자는 상대적이거나, 최상위 일 수 있습니다. 만약 첫 번째 용어가 . 또는 .. 인 경우 상대적입니다.
  - 최상위 식별자는 개념적 모듈 네임스페이스루트에서 확인됩니다.
  - 상대적 식별자는 require 코드가 작성 및 호출되는 모듈의 식별자를 기준으로 합니다.
    - 만약 a/b/c 모듈이 ../d 모듈을 요청하면, 이는 a/d로 요청됩니다.
    - 만약 a/b/c 모듈이 ./e 모듈을 요청하면, 이는 a/b/e로 요청됩니다.
dependencies
- 현재 정의 중인 모듈에 필요한 의존성인 모듈 id의 배열 리터럴입니다.
- 이는 모듈 팩토리 함수가 실행되기 전 요청되어야 하며, 요청된 값은 의존성 배열에서의 인덱스와 동일한 순서로 팩토리 함수의 인자로 전달되어야 합니다.
- 종속성 모듈 id는 상대적 id일 수 있으며, 정의되는 모듈을 기준으로 요청됩니다.
- 만약 종속성 목록에 require, exports, module 이라는 값이 등장한다면 이는 CommonJS 모듈 사양에 정의된 해당 자유 변수로 해석되어야 합니다.
- 만약 이를 생략하면, 기본 값은 ["require", "exports", "module"]이 됩니다. - 그러나 팩토리 함수의 항수(매개변수의 개수)가 3보다 작은 경우, 로더는 함수의 항수(또는 길이)에 해당하는 수의 인수만 사용해 팩토리 함수를 호출하도록 선택할 수 있습니다.
factory
- 모듈 또는 객체를 인스턴스화하기위해 실행해야 하는 함수입니다.
- 만약 factory가 함수라면 싱글톤으로 한 번만 실행되며, 객체인 경우 해당 객체를 모듈의 exports 객체의 속성값으로 할당합니다.
  - 만약 factory 함수가 값(객체, 함수, 또는 true로 인식되는 모든 값)을 반환할 경우, 이 역시 해당 값을 exports 객체의 속성값으로 할당합니다.

`define.amd` 프로퍼티

<script> src 브라우저 로딩에 필요한 전역 define 함수가 AMD API를 준수한다는 표시를 하기 위해, 모든 전역 define 함수는 값이 객체인 amd 라는 프로퍼티를 갖고 있어야 합니다.
이는 AMD API를 준수하지 않는 define 함수를 정의하는 다른 코드와의 충돌을 막을 수 있습니다.
define.amd객체 내부의 속성은 지정되어 있지 않기 때문에, AMD 로더 구현체에 따라 해당 객체 내부의 프로퍼티를 활용해 여러 기능들을 추가할 수 있습니다.

예시 코드

define("alpha", ["require", "exports", "beta"], function (require, exports, beta) {
	// 외부에 verb 라는 프로퍼티를 내보냄
	exports.verb = function() {

		// 의존성으로 설정된 다른 모듈을 사용하려면
		// 넘겨받는 인수를 사용하거나,
		return beta.verb();
		
		// 또는 require()를 이용해
		// 얻어 온 모듈을 사용해도 된다.
		return require("beta").verb();  
	}
});

장점

전역변수 문제가 없음

define() 함수를 이용해 모듈을 구현하므로, 즉, 클로저를 사용해 모듈 정의를 캡슐화 하므로 전역 네임스페이스 오염을 방지할 수 있습니다.

`CommonJS`와의 상호운용성을 제공함

`CommonJS`

CommonJS란 모질라의 Kevin Dangoor에 의해 2009년 시작된(당시 이름은 ServerJS), “웹 브라우저 외부(특히 웹 서버 등 서버사이드)에서의 Javascript용 모듈 생태계를 표준화하기 위한 명세"를 포함한 프로젝트를 말합니다.
웹 브라우저 외부(특히 서버사이드)에서의 사용을 목표로 했기 때문에, Node.js와 같은 런타임에서 채택해 사용 중입니다.

특징

CommonJS는 동기식 모듈 시스템이기 때문에, 특정 모듈을 import한 경우 해당 모듈이 로드될 때 까지 코드 실행이 중단됩니다.
모듈을 가져오기 위해 require 함수를, 모듈을 내보내기 위해 module.exports 객체를 사용합니다.

API 명세 #

앞서 설명한 것 처럼, CommonJS에서 모듈을 불러오고, 내보내기 위해 require() 함수와 module.exports 객체를 사용합니다.
API 명세에는 이들에 대해 다음과 같은 계약이 명시되어 있으며, CommonJS 구현체들은 이를 지켜야 합니다.

require
- require() 함수는 모듈 식별자(id)를 인자로 받으며, 해당 모듈이 내보낸 API를 반환합니다.
- 만약 의존성 사이클이 존재할 경우, 외부 모듈이 전이적 의존성 중 하나에 의해 require 될 때 실행이 완료되지 않았을 수 있습니다.
  - 전이적 의존성: A가 B를 의존하고, B가 C를 의존할 경우 C는 A의 전이적 의존성이다.
  - 이 경우, require가 반환하는 객체에는 현재 모듈의 실행을 유도한 require의 실행 이전에 준비된 하나 이상의 exports를 포함해야 합니다.
- 요청된 모듈이 반환될 수 없으면, require는 에러를 던져야 합니다.
- require 함수는 main 프로퍼티를 가질 수 있으며, 이는 undefined 이거나 로드된 모듈의 module 객체와 동일해야 합니다.
- require 함수는 paths 속성을 가질 수 있으며, 이는 최상위 모듈 디렉토리 까지의 경로를 우선순위대로 배열한 문자열 배열입니다.
module
- module 컨텍스트 안에는 위 정의를 따르는 자유 변수인 require가 있습니다.
- module 컨텍스트 안에는 모듈이 실행될 때 API를 추가할 수 있는 객체인 자유 변수 exports가 있습니다.
  - 모듈은 exports를 유일한 내보내기 수단으로 사용해야 합니다.
- module 안에는 module이라는 객체인 자유 변수가 존재해야 합니다.
  - module 객체는 모듈의 최상위 식별자인 id 프로퍼티를 갖고 있어야 합니다.
    - 또한 이 id 프로퍼티를 사용해 require(module.id)를 호출한 경우, module.id의 출처가 된 exports 객체를 반환해야 합니다.
  - module 객체는 모듈이 생성된 리소스에 대한 정규화된 URI인 uri 문자열이 있을 수 있습니다.

예시 코드

// customers.js
var customers = ["Rachel", "Galen", "Charles"]

// 해당 모듈에서 내보내고자 하는 것들을 `exports`에 담아줍니다. 
// exports에 포함되지 않은 지역 변수는 외부에서 접근할 수 없습니다.
module.exports = {   
  getCustomers: function () {     
    return users   
  },   
  sortCustomers: function () {     
    return users.sort()   
  },   
  firstCustomer: function () {     
    return users[0]   
  } 
}

// acounting.js  
const customers = require('./customers')  
customers.getCustomers() // ["Rachel", "Galen", "Charles"]  
customers.sortCustomers() // ["Charles", "Galen", "Rachel"]  
customers.firsCustomer() // ["Charles"]

장점

배우고 사용하기 쉬움

`Node.js`에서 널리 사용됨

동기식이기 때문에, 모듈 실행 전 모든 종속성이 로드됨을 보장함

단점

동기식이기 때문에, 대규모 앱에서 성능 문제를 야기할 수 있음

모든 파일이 로컬 디스크에 있어 필요할 때 바로 불러올 수 있는 상황을 전제, 즉 동기적으로 동작 가능한 Server-side JS 환경을 전제로 하기 때문입니다.

tree-shaking이 없기 때문에 번들 크기가 커질 수 있음

브라우저에서 지원하지 않기 때문에, 클라이언트 측 개발에 적합하지 않음

만약 브라우저측에서 사용하고 싶다면 트랜스컴파일이 필요합니다.

`UMD`

Universal Module Definition(범용 모듈 정의), 줄여서 UMD란 모듈 작성 방식이 CommonJS와 AMD 두 방식으로 나누어져서 호환 문제가 발생하자, 이를 해결하기 위해 나온 디자인 패턴입니다.
CommonJS 방식과 AMD 방식 모두 사용할 수 있다는 장점이 있기 때문에 여러 모듈 로더에서 사용할 수 있습니다.

예시 코드 #

// 모듈을 생성하기 위해 CommonJS, AMD, 또는 이외의 브라우저 global을 사용합니다.
// 해당 예시는 `b` 라는 모듈을 의존하는 모듈을 불러옵니다.
// 만약 브라우저 전역 경로(global path)를 사용하고 싶지 않다면, 인수로 root 대신 `this`를 넘겨주어야 합니다.

// 모듈 로더를 확인하는 IIFE(즉시 실행 함수)
(function (root, factory) {
    if (typeof define === 'function' && define.amd) {
        // AMD 방식. 익명 모듈로 등록합니다.
        define(['exports', 'b'], factory);
    } else if (typeof exports === 'object' && typeof exports.nodeName !== 'string') {
        // CommonJS
        factory(exports, require('b'));
    } else {
        // Browser globals
        factory((root.commonJsStrict = {}), root.b);
    }
}(typeof self !== 'undefined' ? self : this, function (exports, b) {
    // Use b in some fashion.

	// `exports` 객체에 프로퍼티를 추가해 모듈로 내보낼 프로퍼티들을 정의합니다.
    exports.action = function () {};
}));

`ESM`

ECMAScript Module, 줄여서 ESM(또는 ES Module)이란 ECMAScript2015(ES6)에 도입된 네이티브 모듈 시스템을 말합니다. 즉 Javascript 언어의 일부로 모듈 시스템이 자리잡은 것으로, 웹 브라우저는 물론 Node.js와 같은 런타임에서도 광범위하게 지원되고 있습니다.
ES Module을 사용하기 위해서는 <script type="module"> 로 스크립트를 불러오거나, Node.js의 경우 package.json 파일에 "type": "module" 속성을 추가하거나 파일 확장자를 .mjs로 설정해야 합니다.

추가로, 만약 파일 확장자가 .cjs라면 항상 package 설정에 상관 없이 CommonJS 모듈로 취급됩니다.

로드 과정

ES Module은 비동기적으로 모듈을 불러온다고 알려져 있는데, 이는 ES Module 을 불러오는 3단계 과정이 개별적으로 될 수 있기 때문입니다.
ECMAScript 명세에 따르면, 3단계 과정은 다음과 같습니다.

LoadRequestedModules()
- 모든 종속성들을 재귀적으로 로드해 모듈을 연결(Link)할 준비를 하고, Promise를 반환합니다.
  - 모듈들을 비동기적으로 불러와, 모듈 레코드로 저장합니다.
Link()
- 모듈의 모든 종속성들을 전이적으로 불러오고, 모듈 환경 레코드(Module Environment Record)를 생성해 모듈을 평가할 수 있도록 준비합니다.
  - 모듈의 exports와 메모리 상의 imports를 연결합니다.
Evaluate()
- 모듈과 종속성의 평가에 대한 Promise를 반환합니다. 평가가 성공적으로 이뤄진 경우 resolve, 에러가 발생한 경우 reject 합니다. host는 Promise가 reject된 경우 평가 에러를 던져야 합니다.
  - 코드를 실행해 변수의 실제 값(모듈 레코드)으로 채웁니다.

명세 #

ES Module은 export 문을 통해 내보내고, import 문을 통해 다른 모듈을 불러옵니다.

export
- 내보내고 싶은 항목 앞에 export를 배치하거나, 중괄호로 묶어 내보낼 수 있습니다.
- 또는 default로 export할 수 있는데, 이는 CommonJS와 AMD 모듈 시스템과 함께 상호운용하는데 도움이 됩니다.
- 또한, as 키워드를 활용해 새로운 이름으로 내보낼 수도 있습니다.
- 추가로, 다른 모듈의 요소들을 불러와 함께 export 할 수도 있습니다.

// 1. 내보내고 싶은 항목 앞에 export 배치
export const name = "square";

// 2. 내보내고 싶은 항목들을 중괄호로 묶기
export { name, draw, reportArea, reportPerimeter };

// 3. 내보내고 싶은 항목을 default로 내보내기
export default randomSquare;

// 4. as를 사용해 새로운 이름으로 내보내기
export { function1 as newFunctionName, function2 as anotherNewFunctionName };

// 5. 다른 모듈의 요소들 함께 export 하기
// 현재 모듈과 다른 모듈의 요소들을 함께 내보내고 싶다면 다음과 같이 할 수 있습니다.
export { name } from "x.js";

import
- 불러오고 싶은 모듈의 항목들을 쉼표로 구분해 나열한 뒤 중괄호로 묶어 불러올 수 있습니다.
- from을 통해 모듈 파일 경로를 작성해야 하는데, 전체 절대 경로를 작성하거나, 상대 경로를 사용할 수 있습니다.
- 이 역시 export와 마찬가지로, as 키워드를 활용해 새로운 이름으로 불러올 수 있습니다.
- 추가로, import() 함수를 통해 모듈을 동적으로 불러올 수 있습니다.

// 1. 불러오고 싶은 항목들을 지정해 묶어 불러오기
import { name, draw, reportArea, reportPerimeter } from "./modules/square.js";

// 2. 모듈 객체로 묶어 불러오기
import * as Module from "./modules/module.js";

// 3. default로 내보낸 모듈 불러오기
import randomSquare from "./modules/square.js";
// 위는 아래 코드를 단축한 형태와 같습니다.
import { default as randomSquare } from "./modules/square.js";

// 4. as를 사용해 새로운 이름으로 불러오기
import {
  function1 as newFunctionName,
  function2 as anotherNewFunctionName,
} from "./modules/module.js";

// 5. 동적으로 모듈 불러오기
import("/modules/myModule.js").then((module) => {
  // Do something with the module.
});

장점

자바스크립트 언어에 내장된 표준화된 모듈 시스템임

비동기 방식으로 모듈을 로딩해 성능 향상

Tree-shaking을 통해 번들 크기 줄일 수 있음

단점

비교적 최근에 등장했기 때문에, 구형 브라우저에서는 완전히 지원되지 않음

모듈을 import 하고 export 하는 구문이 복잡할 수 있음

모듈을 캐시하지 않아 추가적인 네트워크 요청 발생 가능

모듈이 로드되면 메모리에 캐시하는 CommonJS와 달리, 기본적으로 모듈을 캐시하지 않습니다.

참고

[Javascript] 이벤트 전파 단계(버블링과 캡처링) 알아보기

Wed, 26 Jun 2024 17:00:00 +0900

서론

CS 스터디에서 6월 25일 발표한 이벤트 캡처링과 버블링에 대해 정리한 문서를 블로그에 공유하고자 한다.

이벤트 버블링과 캡처링

HTML 태그에서 발생할 수 있는 이벤트는 표준에 따르면 다음과 같은 순서로 전파됩니다.

캡처링 단계(CAPTURING_PHASE) : 이벤트가 DOM 트리 상의 하위 요소로 전파되는 단계
타깃 단계(AT_TARGET) : 이벤트가 실제 대상 요소에 전달되는 단계
버블링 단계(BUBBLING_PHASE) : 이벤트가 DOM 트리 상의 상위 요소로 전파되는 단계

즉, 위와 같은 형태로 DOM 트리가 구성되어 있다면, <span>을 클릭하면 이벤트가 최상위 조상부터 시작해 아래로 전파되고, 타겟 요소에 도착해 이벤트가 실행된 후, 다시 위로 전파됩니다.

참고로 이벤트 흐름 순서는 Event.eventPhase 프로퍼티를 통해 알 수 있습니다.
- 이 값이 1일 경우 캡처링 단계, 2일 경우 타깃 단계, 3일 경우 버블링 단계, 0일 경우 현재 이 이벤트가 처리중이지 않음을 의미합니다.
또한, 이벤트 캡처링 방식과 버블링 방식 모두 존재하는 이유는, 기존에 분리되어 있던 이벤트 전파 방식들을 W3C에서 표준화 하며 둘을 모두 포함하는 시스템을 만들었기 때문입니다.
- 정확히는 Netscape에서는 이벤트 캡처링만, IE에서는 이벤트 버블링만 사용했기 때문에 상호 호환성을 위해 이들을 모두 포함하는 시스템이 표준으로 자리잡게 된 것입니다.
  - Javascript - Event order (quirksmode.org)
  - Javascript - Event accessing (quirksmode.org)

이벤트?

Web API에서의 이벤트란, 마우스 클릭, 키보드 입력 등 DOM 상의 요소에서 발생할 수 있는 이벤트를 말합니다.
이벤트는 사용자의 행동 뿐만 아니라, HTMLElement.click()과 같은 메서드를 직접 호출하거나, EventTarget.dispatchEvent()와 같은 메서드를 통해 타겟 객체로 이벤트를 보내는 등 프로그래밍적으로도 발생시킬 수 있습니다.
이렇게 발생한 이벤트에 대응하고 싶다면, <button>, <div>와 같은 DOM 요소에 EventTarget.addEventListener()를 통해 이벤트 처리기를 연결할 수 있습니다.
하나의 요소(Element)는 하나 이상의 이벤트 처리기를 가질 수 있으며, 동일한 이벤트에 대해 여러 이벤트 처리기를 연결할 수도 있습니다.

같은 요소 / 같은 이벤트 / 같은 단계로 설정한 이벤트 처리기들은 설정한 순서대로 동작합니다.

element.addEventListener("click", e => alert(1)); // 먼저 트리거
element.addEventListener("click", e => alert(2));

발생한 이벤트는 상기한대로 캡처링 -> 타깃 -> 버블링의 흐름을 순서대로 거치게 됩니다.

캡처링 단계

캡처링 단계란, 이벤트가 하위 요소로 전파되는 이벤트 전파 단계를 말합니다.
on<event> 프로퍼티, HTML 속성, addEventListener(event, handler)를 이용해 이벤트 처리기를 연결한 경우, 이들은 캡처링에 대해 알 수 없습니다.

즉, 타깃, 버블링 단계에서만 동작합니다.

따라서 이들을 캡처링 단계에서 이벤트를 인식하게 하려면, addEventListener()의 capture 옵션을 true로 설정해주어야 합니다.

element.addEventListener(..., { capture: true });
// 또는
element.addEventListener(..., true);

이렇게 capture 옵션을 true로 할당해주면 특정 요소에서 이벤트가 발생했을 때, 최상위 조상부터 차례대로 이벤트가 전파될 것입니다.
이벤트는 document부터 DOM 트리를 따라 타깃(event.target)까지 전파되며, 해당 이벤트 유형을 처리하는 addEventListener(... , { capture: true })로 할당된 핸들러들을 동작시킵니다.

이어서 나올 버블링과 달리 캡처링은 실제 코드에서 사용될 일이 흔치 않습니다.
논리적으로 생각해보면, 더 세부적이고 특정적인 요소에 핸들러가 할당될수록 그 요소에 대한 세부 사항과 어떤 동작을 요하는지 더 잘 알 것입니다.
따라서 이벤트가 발생한 타깃 위치부터 전파되는 버블링 단계에서 이벤트를 처리하는 것이 더 적합할 것입니다.

타깃 단계

타깃 단계란, 이벤트가 실제 타깃 요소에 전달되는 이벤트 전파 단계를 말합니다.
엄밀히 말하면, 타깃 단계는 별도로 처리되지 않으며 (즉, 이벤트를 더 전파시키지 않음) 캡처링 및 버블링 단계의 핸들러가 타깃 단계에 트리거 됩니다.

`Event.target`

이벤트가 발생한 요소는 이벤트 핸들러 내부에서 Event.target을 통해 접근할 수 있습니다. 이와 관련해 주의해야 할 사항으로, Event.target를 Event.currentTarget과 헷갈리지 않아야 한다는 것입니다.
Event.target은 실제로 이벤트가 시작된, 타깃 요소를 의미하며, 이는 이벤트가 버블링되어 전파되어도 변하지 않습니다.
반면, Event.currentTarget(또는 핸들러 내부에서 호출한 this)은 현재 실행중인 이벤트 핸들러가 할당된 요소를 의미합니다.
예를 들어, div > p 형태로 DOM 트리가 구성되었고 p에서 발생한 이벤트를 div의 이벤트 핸들러가 처리하는 상황이라 가정합시다.
이때, div의 이벤트 핸들러에서 event.target을 호출한다면 이는 p를 가리키고, event.currentTarget을 호출한다면 이는 div를 가리킨다는 것입니다.

버블링 단계

버블링 단계란, 이벤트가 타깃 요소부터 최상위 요소까지 전파되는 이벤트 전파 단계를 말합니다.
이벤트는 상위 요소로 계속해서 전파되며, 해당 이벤트를 처리하는 핸들러를 동작시킵니다.
다만 focus, blur, load/unload 등과 같이 버블링되지 않는 몇몇 이벤트들도 존재합니다.

이벤트가 버블링 되는지 여부는 Event의 bubbles프로퍼티를 통해 알 수 있습니다. 이 값이 true라면 해당 이벤트는 버블링되어 위로 전파됩니다.

버블링 중단(`stopPropagation`)

버블링을 통해 이벤트가 전파되는 것이 유용할 수 있지만, 그렇지 않은 경우도 있을 수 있습니다.
예를 들어, 이벤트가 계속 전파되어 원하지 않았던 상위 요소의 이벤트 핸들러까지 동작시켜 오동작을 일으킬 수도 있습니다.
이럴 때, 이벤트 핸들러 내부에서 Event.stopPropagation() 메서드를 호출해 이벤트가 더 버블링 되는 것을 막을 수 있습니다.
다만, 한 요소에 특정 이벤트를 처리하는 핸들러가 여러 개일 경우, 위로 이벤트가 버블링 되는 것은 막을 수 있지만 다른 핸들러가 동작 하는 것은 막을 수 없습니다.
따라서 버블링을 막고 다른 핸들러의 동작까지 막으려면 Event.stopImmediatePropagation() 을 사용해야 합니다.
이렇게 버블링을 막을 수 있긴 하지만, 대부분의 경우(특히 분석, 로깅등을 수행할 때) 버블링이 유용하기 때문에 꼭 멈춰야 하는 상황이 아니라면 막지 않는 것이 좋습니다.

이벤트 위임(Event Delegation)

버블링을 통해 이벤트가 위로 전파된다는 점을 활용해서, 모든 하위 요소에 이벤트 핸들러를 설정하는 대신 상위 요소에서 하위 요소에서 발생하는 이벤트들을 처리하는 핸들러를 설정하는 형태로 구현할 수도 있습니다.
만약 하위 요소에서 이벤트가 발생할 때 비슷한 또는 똑같은 작업을 수행하는 경우, 번거롭게 이들에 모두 이벤트 핸들러를 설정하는 것 보다 위임하는 형태로 작성하면 코드가 더욱 간결해질 수 있습니다.

예시 - 16개의 타일 색 바꾸기

예시로 16개의 div 타일이 있고, 각 타일을 클릭하면 랜덤으로 타일의 색깔을 바꾼다고 합시다.

<div id="container">
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
  <div class="tile"></div>
</div>

만약 전자처럼 모든 하위요소(tile)에 이벤트 핸들러를 단다면 코드는 다음과 같을 것입니다.

function randomColor() {
   return `rgb(${Math.floor(Math.random() * 255)} ${Math.floor(Math.random() * 255)} ${Math.floor(Math.random() * 255)})`;
}
const children = document.getElementById("container").children;
for(e of children) {
    e.addEventListener("click", e => e.target.style.backgroundColor = randomColor();
}

반면, 이벤트를 상위 요소(container)로 위임하게 된다면 코드를 다음과 같이 바꿀 수 있습니다.

const container = document.querySelector("#container");

container.addEventListener("click", (event) => {
  event.target.style.backgroundColor = randomColor();
});

참고

[Javascript] Map과 Object, 뭘 써야 할까?

Sun, 21 Apr 2024 06:13:01 +0900

서론

최근 한 기업의 코딩 테스트를 푸는데, 중첩된 구조의 객체를 필요로 하는 문제를 맞닥들이게 되었다.
나는 ‘Object가 Map보다 있는 기능이 별로 없으니까, 혹시 몰라서 메모리 터질 수 있는 Map 보단 Object가 낫지 않을까?’ 라는 생각으로 Object를 활용해 해당 문제를 풀었다.
그리고 그 이후 내 생각이 맞을까? 라는 생각을 갖게 되었고 이를 직접 테스트 한 뒤 내용을 정리해보고 싶어졌다.
따라서 여러 글을 찾아 보았고, 직접 문제와 유사한 상황을 가정하고 코드를 작성해 시간과 메모리 사용량을 측정해보았다.

TL;DR

Map은 ES6 명세에 따라 선형시간 이하의 접근 시간을 제공해야 한다.
V8과 같은 대부분의 JS 엔진에서는 HashTable을 활용해 빠른 삽입/접근 시간을 제공한다.
테스트 결과, 다른 벤치마크들 처럼 Map이 Object보다 30~50% 정도 빠른 속도를 보였다.

`Map` vs `Object`

자바스크립트에서 Map과 Object 모두 키-값 쌍으로 데이터를 저장하는 것은 동일하지만, 세부적으로는 다른점들이 존재합니다.

`Map`

Javascript 2015(ES6)에서 처음으로 등장했습니다.
Map은 원시 타입, 객체, 함수 등 어떤 데이터 타입이든 키로 지정할 수 있습니다.
맵의 키는 삽입된 순서대로 순서를 유지합니다.
Map은 원소들을 반복(Iteration)하는데 사용하는 forEach, keys, values, entries와 같은 빌트인 메서드 들을 갖고 있습니다.
원소에 접근하기 위해 set(), get()와 같은 메서드를 사용해야 합니다.

`Object`

Object의 키는 문자열이거나 기호여야 합니다.
- 만약 다른 자료형을 사용할 경우, 자동적으로 문자열로 변경됩니다.
  - 즉, 키가 동일한지 검사할 때 느슨한 동등 비교(==)를 통해 값만 비교합니다.
    - 이와 달리 Map은 엄격한 동등 비교(===)를 사용합니다.
Object의 속성들은 순서를 보장하지 않습니다.
- 대부분의 JS 엔진들이 삽입된 순서를 유지하려고 하지만, 이는 엔진에서 처리해주는것이지 언어 자체에서 규정된 사항이 아닙니다.
Object는 prototype chain이 있어, 프로토타입 객체들로부터 속성과 메서드를 상속받습니다.
- 프로토타입 체인(prototype chain): 모든 객체에는 프로토타입이라는 다른 객체에 대한 링크가 존재하며, 해당 프로토타입 또한 자체 프로토타입을 가지는데 이러한 연결이 null을 프로토타입으로 하는 객체를 만날 때 까지 계속되는 형태를 뜻합니다.
  - 출처: Object prototypes - Learn web development | MDN (mozilla.org)
Object의 원소를 반복하려면, Object.keys(obj) 를 통해 키 배열을 추출하거나, for in문을 사용해야 합니다.
Object는 원소에 접근하기 위해 대괄호 표현식 또는 .을 사용해 직접 접근합니다.

성능은 어떨까?

온라인에 올라온 대부분의 Map vs Object 성능 벤치마크에서는 Map이 삽입, 삭제, 갱신 등의 작업에서 성능 우위를 보이고 있었습니다.

Map이 성능우위임을 보여주는 벤치마크

zhenghao라는 유저의 벤치마크(When You Should Prefer Map Over Object In JavaScript (zhenghao.io)), MeasureThat의 벤치마크(Benchmark: Map vs Object (real-world) Performance - MeasureThat.net) 등 데이터를 살펴보면 삽입/값 가져오기 연산시 27~50% 가량 Map이 더 빠르다는 결과가 나왔음을 알 수 있습니다.

이 테스트들은 Map이 중첩되지 않은, 깊이가 1인 평면상에서 이뤄진 테스트입니다.
추가로 메모리 역시 Map이 더 적게 차지한다는 결과가 많았습니다.

왜?

ES6 명세에 따르면, Map 객체는 HashTable, 또는 다른 메커니즘을 활용해 컬렉션 요소 수에 대해 선형 이하의 접근 시간을 제공할 수 있어야 합니다.

Map object must be implemented using either hash tables or other mechanisms that, on average, provide access times that are sublinear on the number of elements in the collection. The data structures used in this Map objects specification is only intended to describe the required observable semantics of Map objects. It is not intended to be a viable implementation model.

이러한 명세를 지키기 위해, 다양한 JS 엔진에서 HashTable을 활용해 Map 객체를 구현하고 있습니다.

V8(Google) - v8/src/objects/map.cc at master · v8/v8 (github.com)
SpiderMonkey(Mozilla) - MapObject.cpp - mozsearch (searchfox.org)

오늘은 세계에서 가장 많이 사용되는 Chromium 기반의 환경을 가정하고 성능을 비교해보기 위해, V8 엔진의 Map에 대해 알아보겠습니다.

Map in V8 Engine

V8 엔진에서 Map은 HashTable, 정확히는 OrderedHashTable 이라는 삽입된 순서를 유지하는 HashTable을 사용합니다.

Issue 220293002: OrderedHashTable implementation with Set and Map interfaces - Code Review (chromium.org)

이는 Deterministic hash table라는 자료구조를 기반으로 합니다.

`Deterministic hash table`

// pseudocode of Deterministic hash table
struct Entry {
    Key key;
    Value value;
    Entry *chain;
}

class CloseTable {
    Entry*[] hashTable;  // array of pointers into the data table
    Entry[] dataTable;
}

기존의 버킷/체인 해시 테이블과 조회/삽입은 비슷하게 진행되지만, 각 Entry들이 Heap에 별도로 할당되지 않고 삽입 순서대로 dateTable에 저장되게 됩니다. (hashTable의 각 요소들은 버킷인 dataTable을 가리킴)
따라서 hashTable에서 삽입된 순서를 유지할 수 있습니다.
V8 엔진에서 HashTable을 사용하므로, set을 통한 삽입과 get을 통한 탐색에 $O(1)$ 의 시간이 걸릴것으로 유추할 수 있습니다.

직접 확인 해보자

앞서 살펴본 테스트들 결과에 따르면, Map이 시간적으로나 공간적으로나 Object에 우위를 보이고 있음을 알 수 있습니다.
그래도 한 번 제 케이스에 맞게 직접 실험해보고 싶었고, Nested한 구조에서도 우위일지 알아보고 싶어졌습니다.

테스트 진행 방식

테스트에 사용할 명령어 set을 먼저 만듭니다.
- 1,000,000개의 명령어 배열을 만들고, 500,000개의 삽입 명령과 500,000개의 삭제 명령을 만들어 채웁니다. 각 명령은 다음과 같은 형태를 가집니다.
  - 주어지는 경로는 .으로 구분되며, 경로를 이루는 문자열들은 key 또는 property의 이름에 해당합니다.
    - ex) abc.def.fgi라면, root.get('abc').get('def').get('fgi')를 통해 접근할 수 있습니다.
    - 편의상 주어지는 경로는 모두 절대경로입니다.
  1. [삽입, "경로"]
    - 경로의 마지막 문자열을 제외한 위치까지 이동한 후, 마지막 문자열의 이름으로 새 Map(또는 Object)을 생성합니다.
      - 올바르지 않은 경로인 경우 생성하지 않습니다.
  2. [삭제, "경로"]
    - 경로의 마지막 문자열을 제외한 위치까지 이동한 후, 마지막 문자열의 이름에 해당하는 Map(또는 Object)을 삭제합니다.
      - 올바르지 않은 경로인 경우 삭제하지 않습니다.
Map으로 먼저 해당 명령들을 수행하고, 시간을 기록합니다.
Object로 해당 명령들을 동일하게 수행하고, 시간을 기록합니다. 테스트에 사용된 코드는 아래와 같습니다.

테스트 결과

테스트는 Node.js를 통해 2 * 10회, MS Edge의 DevTools에 있는 Console에서 1 * 10회 진행되었습니다.

Time Spent in `Node.js`

앞서 찾아보았던 벤치마크들의 데이터처럼 3~50% 정도의 시간 차이가 발생한 것을 알 수 있었습니다.

Time Spent in `MS Edge Devtools`

MS Edge의 Devtools의 Console에서 진행한 테스트 역시 50%가량의 차이를 보이고 있음을 알 수 있었습니다.

추가) Memory Usage in `Node.js`

아무래도 제가 Object를 선택했었던 이유가 메모리 사용량에 대한 우려였기 때문에, 실제로 둘 간의 메모리 사용량 차이가 어느정도 나는지도 파악하고자 했습니다.
하지만, performance를 통해 브라우저에서 측정하는 것은 정확한 데이터가 나오지 않았습니다.
(--enable-precise-memory-info 플래그를 켜고 실행하라는 조언대로 했는데도 불구하고 말이죠)

performance.memory의 usedJSHeapSize 변화량을 추적하고자 했으나, 보안상 이슈?로 정확한 값을 브라우저에서 제공하지 않았습니다. (추가로, MDN의 API 문서에 따르면 Deprecated된 기능이라고 합니다.)
따라서 performance.measureUserAgentSpecificMemory() 나, Toast UI 팀 블로그의 글을 읽고 performance.measureMemory() 같은 다른 API를 사용하고자 했으나, Experimental 기능이기 때문인지 사용할 수가 없었습니다.

그래서 Node.js에서라도 메모리 사용량을 측정해보고자 했습니다.
찾아보니, Node.js에서는 --expose-gc 플래그를 이용해 사용자가 명시적으로 gc를 호출하므로써 자동으로 gc가 발생하는 텀을 늘려, 잦은 gc 발생 없이 테스트하는 시간동안의 메모리 변동을 측정할 수 있다고 하여 해당 방법을 사용했습니다.
그러나 Map을 테스트할 때 메모리 사용량 값이 튀는 경우가 발생해, 측정한 데이터도 그냥 ‘아 메모리 사용량도 Map이 훨씬 적구나’ 정도를 짐작 하는 용도로만 사용할 수 있을것 같습니다.

결론

Javascript에서 key를 통해 탐색해야하는 Dictionary 형태의 구조체(중첩된 형태의 구조더라도)를 사용해야 한다면, 웬만하면 Map을 쓰는 것이 좋다!

추가로, V8 엔진에서 사용하는 hashTable의 구조라던지, V8 소스 코드를 찾아보는 등의 경험을 할 수 있어서 새로웠다!
나중엔 이런 소스 코드들을 전부 이해하고 나아가 Contribute 할 수 있는 개발자가 될 수 있도록 노력해야겠다!

참고

[Javascript] 순환 참조 (Circular Import)

Sun, 19 Feb 2023 11:22:33 +0900

오늘은 Javascript, Python같은 언어에서 import시 발생할 수 있는 순환 참조 에러에 대한 포스트를 작성하고자 한다.

순환 참조

메모리 관점에서의 순환 참조 ( In Javascript )

간단히 요약하자면, 서로 다른 두 객체가 서로를 참조하여, 가비지 컬렉션 알고리즘의 대상에 포함되지 않아 해당 객체들이 불필요해져도 메모리 회수되지 않고 존속하게되는 문제이다.
Mozilla Developer Network의 문서의 예시를 드는게 이해하기 쉽다.

import b from "b";
function f() {
  var x = {};
  var y = {};
  x.a = y;         // x는 y를 참조합니다.
  y.a = x;         // y는 x를 참조합니다.

  return "azerty";
}

f();

다음 예제에서는 두 객체가 서로 참조하는 속성으로 생성되어 순환 구조를 생성합니다.
함수 호출이 완료되면 이 두 객체는 스코프를 벗어나게 될 것이며, 그 시점에서 두 객체는 불필요해지므로 할당된 메모리는 회수되어야 합니다.
그러나 두 객체가 서로를 참조하고 있으므로, 참조-세기 알고리즘은 둘 다 가비지 컬렉션의 대상으로 표시하지 않습니다.

참조-세기(Reference-counting) 알고리즘 : 가비지 컬렉션시 사용하는 알고리즘으로, “어떤 다른 객체도 참조하지 않는 객체"를 더 이상 필요없는 객체로 인식하고 가비지 컬렉션을 수행.

import에서의 순환 참조(Circular Dependencies) (In Javascript)

2가지 이상의 모듈에서 import가 꼬리의 꼬리를 물어 순환 구조를 이루어 에러가 발생하는 경우.
예시
위와 같이 참조의 순환 고리가 발생하게 될 경우, 그 고리의 어느 한 모듈(순환 고리안의 다른 모듈을 참조하는)을 이용하려 하면
ReferenceError: Cannot access '모듈 이름' before initialization
라며 에러가 발생한다.

나의 사례

본인은 Axios 모듈, Redux 객체(store)를 export 하는 모듈, Redux Toolkit의 slice 객체를 export하는 모듈를 사용하며 React 프로젝트를 개발하고 있었다.
개발 초-중반기에만 해도 ‘Redux 객체 -> Redux Toolkit의 Slice 객체’, ‘Slice 객체 -> Axios 모듈’ 로의 참조 외에는 모듈간의 연관관계가 존재하지 않아 순환 참조가 발생하지 않아 에러가 발생하지 않았다.
- ‘Redux 객체 -> Redux Toolkit의 Slice 객체’
  - Redux Toolkit Slice들의 Reducer를 모은 rootReducer를 메인 Redux객체(store)에 할당하기 위해 Slice 객체를 참조.
- ‘Slice 객체 -> Axios 모듈’
  - 비동기 작업 후 state를 update하는 로직을 위해, Redux 액션 생성함수(Action Creator)를 만들어서 사용하였다.
  - 이 때, 비동기 작업을 위해 Axios 모듈을 사용했다.

사건의 발단

그러다 Axios 모듈에 interceptor를 설정해, request를 보내기 전 ‘유저 Slice’에 저장된 AccessToken을 불러와 Header에 첨부해주려 했는데 순환 참조 에러가 발생했다.
Uncaught ReferenceError: Cannot access '__WEBPACK_DEFAULT_EXPORT__' before initialization
- 해당 에러를 맞닥들인 당시, 나는 ‘순환 참조’라는 개념도 잘 알지 못했고 이러한 행위가 에러를 발생시킨다는 것 역시 알지 못했다.
- 그리고 여러 글들을 찾아 보다가, 관련된 stackoverflow 글을 보고 어느정도 왜 에러를 발생시키는 행위인지 알 수 있었다.

원인

request를 보내기 전에 Redux Store를 확인하고 만약 AccessToken이 존재하면 해당 값 가져와서 Header의 Authorization으로 설정한 뒤 요청을 보내는 로직을 수행하는 interceptor를 Axios 모듈에다 달아주고 싶었다.
React에서 자주 쓰던것 처럼, useDispatch()훅을 통해 dispatch 함수를 반환 받아, Action Creator를 통해 만든 Action을 dispatch하는 방식으로 AccessToken을 가져오는 것이 원래 계획이었다.
그러나 Axios 모듈은 React Component가 아니기 때문에, React Component 외부에서는 Redux Store 모듈을 불러와 Store 객체가 갖고있는 dispatch 함수를 호출해야 했다.
그래서 Redux Store 모듈을 불러와 dispatch를 함수를 호출하려 했는데, Redux Store를 불러오는 로직을 추가하니 상기한 내용의 에러를 내놓고 있었다.
즉, Axios 모듈에서 Redux Store 모듈을 import함으로써 아래와 같은 구조가 형성되어 버린것이었다.

store 객체를 생성하려면 user-slice의 reducer가 필요해 user-slice.js를 import

user-slice.js 내부에 정의된 Action Creator 함수는 비동기 작업을 처리하기 위해 Axios 모듈이 필요해 http.js를 import

Axios 모듈에서는 store 객체 안에 저장된 AccessToken을 가져오기 위해 store 객체가 필요해 store.js를 import

해결?

Action Creator 함수, Store에 접근하는 interceptor, Slice들의 reducer를 combine해 사용하는 store 객체 모두 놓치고 싶지 않았지만, 에러를 해결해야 해 어쩔 수 없이 Action Creator 함수를 사용하지 않는 방향으로 코드를 수정했다.
- Axios 모듈을 사용하는 Action Creator 함수로 로그인, 로그아웃이 있었는데, 해당 작업을 각 기능을 사용하는 component(로그인 - 로그인 페이지, 로그아웃 - 네비게이션 바)에서 정의하도록 하여 순환 관계를 끊었다.

결론?

순환 참조가 발생할 경우, 순환 고리에 포함된 모듈(객체)들은 생성이 안 되어 사용이 불가능하므로 순환 참조가 발생하지 않도록 코드를 짜는것이 중요하다는걸 몇 시간의 실랑이 끝에 알 수 있었다….

javascript on 오늘도 개발을 한다.

[Webpack/Vite 파헤치기] 2. Create React App 내부의 의존성과 환경 설정 꺼내기

서론

CRA eject시 드러나는 의존성들

Babel 관련

Babel이란?

관련 종속성

Webpack 관련

Webpack이란?

관련 종속성

로더 #

로더란?

관련 종속성

CSS / SASS 관련

ESLint 관련

테스트 관련

기타 유틸

Ejecting 이후 콘솔에 출력된 메세지

참고

[Webpack/Vite 파헤치기] 1. Create React App의 Deprecated 발표

서론

CRA의 대체 프레임워크

Next.js

React Router

Expo

빌드 툴의 한계

라우팅

데이터 페칭(데이터 불러오기)

코드 스플리팅

참고

[Javascript] Prototype 알아보기

서론

prototype in Javascript

프로토타입 체인

프로퍼티 상속하기

메서드 상속하기

생성자 함수(Constructor)

프로토타입을 활용한 생성자 함수 개선

주의사항

리터럴의 암시적 생성자

생성자 함수의 프로토타입 체인

프로토타입 접근 및 설정

구문 생성자을 통한 객체 생성

생성자 함수를 통한 객체 생성

Object.create()를 통한 객체

클래스를 통한 객체 생성

Object.set/getPrototypeOf()를 사용한 프로토타입 지정 및 접근

__proto__ 접근자를 사용한 프로토타입 지정 및 접근

성능 관련

class와 prototype

class와 생성자 함수

왜 Javascript는 프로토타입 기반(prototype-based)을 채택했을까?

참조

[Javascript] 모듈 시스템들 알아보기

서론

Module in Javascript

AMD

API 사양 #

define() 함수

define.amd 프로퍼티

예시 코드

장점

전역변수 문제가 없음

CommonJS와의 상호운용성을 제공함

CommonJS

특징

API 명세 #

예시 코드

장점

배우고 사용하기 쉬움

Node.js에서 널리 사용됨

동기식이기 때문에, 모듈 실행 전 모든 종속성이 로드됨을 보장함

단점

동기식이기 때문에, 대규모 앱에서 성능 문제를 야기할 수 있음

tree-shaking이 없기 때문에 번들 크기가 커질 수 있음

브라우저에서 지원하지 않기 때문에, 클라이언트 측 개발에 적합하지 않음

UMD

예시 코드 #

ESM

로드 과정

`prototype` in Javascript

`생성자 함수(Constructor)`

`Object.create()`를 통한 객체

`Object.set/getPrototypeOf()`를 사용한 프로토타입 지정 및 접근

`proto` 접근자를 사용한 프로토타입 지정 및 접근

`class`와 `prototype`

`class`와 `생성자 함수`

왜 `Javascript`는 `프로토타입 기반(prototype-based)`을 채택했을까?

`AMD`

`define()` 함수

`define.amd` 프로퍼티

`CommonJS`와의 상호운용성을 제공함

`CommonJS`

`Node.js`에서 널리 사용됨

`UMD`

`ESM`

`Event.target`

버블링 중단(`stopPropagation`)

`Map` vs `Object`

`Map`

`Object`

`Deterministic hash table`

Time Spent in `Node.js`

Time Spent in `MS Edge Devtools`

추가) Memory Usage in `Node.js`