혼자공부끄적끄적

더 나은 Git 커밋 메시지 작성하기(커밋 옵션, 컨벤션, 템플릿)

SH_Roh — Fri, 2 Jun 2023 02:03:37 +0900

무조건 git commit -m으로만 커밋 메시지를 작성했던 지난 날.. 이걸로만은 한계를 느껴 커밋 메시지에 대해 좀 더 알아보았다.

Commit Options

커밋 메시지 작성

-m: 인라인 형식으로 바로 커밋 메시지 작성

git commit -m "커밋 메시지"

-a 또는 --all: 별도의 add 명령어를 사용하지 않고, 수정된 모든 파일에 대해 add, commit을 한번에 수행(단, 한번도 add되지 않은 파일은 add를 따로 해주어야 함)

git commit -a -m "커밋 메시지"

-am: a, m 옵션을 합친 형태(파일을 스테이지에 올리고 커밋)

git commit -am "커밋 메시지"

커밋 메시지 수정

1. 커밋을 push하기 전인 경우

--amend 옵션으로 가장 최근에 만든 커밋 메시지 수정하기

git commit --amend -m "수정할 커밋 메시지"

수정하고자 하는 커밋이 가장 최근 커밋이 아닌 경우

git rebase -i HEAD~[숫자]

숫자는 최근까지 실행된 커밋 중 몇 개까지 살펴볼 것인지를 말한다. 예를 들어 2를 입력 시, 최근 커밋보다 이전에 커밋된 2개의 git 메시지를 수정 가능하다.

위 명령어를 통해 수정화면에 들어가면 각 커밋 앞에 pick이 적혀있다.

수정하고자 하는 커밋 앞의 pick을 reword로 변경한 뒤 저장하면 해당 커밋을 수정할 수 있는 창이 열린다. (i를 눌러 내용을 수정하고, esc를 누른 후 :wq를 입력하면 저장할 수 있다.)

자세한 과정은 아래에 있는 gif를 참고하면 된다.

2. 커밋을 이미 push한 경우

이 경우 다른 개발자들이 해당 변경사항을 이미 pull 받았을 수도 있기 때문에 커밋 메시지를 수정하는 것을 권장하지 않는다. 하지만 그럼에도 불구하고 반드시 수정해야 하는 경우라면 위에서 설명한 방법으로 커밋 메시지를 수정한 후 git push --force를 입력하면 된다.

-amend 또는 rebase -i HEAD~로 커밋 메시지 수정
git push --force

이미 push한 커밋을 rebase -i로 메시지 수정 후 --force로 푸시

Commit Message Convention

커밋 메시지 컨벤션이란 프로젝트 참여자들이 일관된 형식의 커밋 메시지를 작성하기 위한 규칙을 말한다.

커밋 컨벤션의 중요성

일관된 커밋 메시지의 형태를 유지하면 가독성을 높일 수 있고, 소스 변경 이력을 효율적으로 추적할 수 있다.

또한 코드 리뷰 및 버그 수정 과정에서 불필요한 의사소통 과정을 간소화해 프로젝트 관리에 들어가는 시간을 줄일 수 있다.

기본 포맷

일반적으로 아래와 같은 형태로 작성한다.

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

type과 description은 필수적으로 작성하고, scope, body, footer는 필요에 따라 작성해주면 된다. (e.g. feat: 로그인 기능 추가)

type에는 상황에 따라 다음과 같은 단어들이 들어가면 좋다.

FEAT: 새로운 기능 추가
FIX: 버그 수정
DOCS: 문서 수정
STYLE: 스타일 관련 기능(코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우)
REFACTOR: 코드 리팩토링
TEST: 테스트 코드 추가
CHORE: 빌드 업무 수정, 패키지 매니저 수정(ex .gitignore 수정 같은 경우)

좋은 커밋 메시지를 쓰기 위한 규칙

1. 제목과 본문을 빈 행으로 분리한다.

사소한 변경으로 커밋 메시지를 한 줄만 작성해도 괜찮은 경우도 있다. 이럴 경우에는 본문을 쓰지 않아도 괜찮다.

하지만 어떤 변경 사항인지 맥락과 설명이 필요하다면 본문을 작성해야 한다. 제목과 본문을 구분해서 작성할 때는 무조건 그 사이에 빈 행이 존재해야 제대로 동작한다.

2. 제목 행을 50자로 제한한다.

이는 강제로 제한하는 규칙이 아닌 경험에 의한 규칙이다.

이 길이로 하면 읽기 편하고, 작성자가 무슨 일이 일어나는지 간결하게 작성하는 데 집중할 수 있도록 돕게 된다.

(제목을 요약하는 것이 너무 어렵다면 한 번에 커밋하기에 너무 많은 변경을 포함하는 경우일 수도 있다.)

3. 제목 행 첫 글자는 대문자로 쓴다.

4. 제목 행 끝에 마침표를 넣지 않는다.

5. 제목 행에 명령문을 사용한다.

6. 본문을 72자 단위로 개행한다.

7. 어떻게 보다는 무엇과 왜를 설명한다.

'왜' 이렇게 바꾸었는지에 먼저 주목하자. 바꾸기 전에 무엇을 했는지(무엇이 잘못 동작했는지), 지금은 어떻게 동작하는지, 그리고 왜 당신이 그렇게 바꾸기로 했는지에 대해 적자.

Commit Message Template

커밋 메시지 템플릿을 이용하면 일관된 커밋 메시지를 작성하도록 유도할 수 있다.

기본 구조가 적힌 템플릿 파일을 생성한 후, git config commit.template 명령어로 해당 템플릿 파일을 git config에 등록하면 템플릿을 사용할 수 있다.

템플릿 파일 작성하기

먼저 .gitmessage.txt라는 이름의 파일을 생성한 후, 파일에 아래 내용을 붙여넣고 저장한다.

################
# <타입> : <제목> 의 형식으로 제목을 아래 공백줄에 작성
# 제목은 50자 이내 / 변경사항이 "무엇"인지 명확히 작성 / 끝에 마침표 금지
# 예) FEAT: 로그인 기능 추가

# 바로 아래 공백은 지우지 마세요 (제목과 본문의 분리를 위함)

################
# 본문(구체적인 내용)을 아랫줄에 작성
# 여러 줄의 메시지를 작성할 땐 "-"로 구분 (한 줄은 72자 이내)

################
# 꼬릿말(footer)을 아랫줄에 작성 (현재 커밋과 관련된 이슈 번호 추가 등)
# 예) Close #7

################
# FEAT: 새로운 기능 추가
# FIX: 버그 수정
# DOCS: 문서 수정
# STYLE: 스타일 관련 기능(코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우)
# REFACTOR: 코드 리팩토링
# TEST: 테스트 코드 추가
# CHORE: 빌드 업무 수정, 패키지 매니저 수정(ex .gitignore 수정 같은 경우)
################

#으로 시작하는 부분은 주석으로, 커밋에 반영되지 않는다.

아래 명령어를 통해 템플릿 파일을 설정할 수 있다. 이렇게하면 git commit 명령을 실행할 때 지정한 템플릿 메시지를 편집기에서 매번 사용할 수 있다.(-m 옵션을 사용하지 않고 git commit만 입력하면 된다.)

git config --global commit.template .gitmessage.txt

config options

따로 범위 옵션을 지정하지 않으면 git은 기본적으로 --local 옵션을 지정한다. 상황에 따라 맞는 옵션을 선택해 지정해주면 된다.

--system: 해당 시스템에 있는 모든 사용자와 모든 저장소에 적용되는 설정 파일
--global: 해당 사용자에게만 적용되는 설정 파일(내 로컬에서 커밋하는 모든 프로젝트에서 동일한 템플릿이 적용됨)
--local: 현재 작업 중인 저장소의 git 디렉토리에 있는 파일을 찾는다. 이 파일은 해당 저장소에만 적용된다.

커밋 메시지 작성하기

먼저 git add 명령어를 통해 변경사항이 있는 파일을 스테이지에 올린다. 그 후 git commit을 실행한다.(-m 옵션을 빼고 git commit만 입력하면 설정한 템플릿이 나온다.)

vi 에디터가 나오면 i를 눌러 편집모드로 변경 후 내용을 작성한다. 입력이 완료되었으면 esc를 누른 후 :wq를 입력해 저장해주면 커밋이 완료된다.

작업이 끝났다면 git push를 통해 커밋을 원격 저장소에 올릴 수 있다.

커밋 메시지 자동화 툴

git 커밋 메시지를 자동으로 생성하고 관리하기 위한 다양한 자동화 도구들이 있다.

commitlint: git 커밋 메시지를 검사해 컨벤션을 따르는지 확인
Husky: git hook을 설정해 커밋 및 푸시 전에 자동화된 작업(커밋 메시지 검사, 코드 포매팅 등)을 설정할 수 있음.

References

https://git-scm.com/docs/git-commit

https://yozm.wishket.com/magazine/detail/1974/

https://velog.io/@bky373/Git-커밋-메시지-템플릿

https://chanhuiseok.github.io/posts/git-4/

https://richone.tistory.com/26

yarn unknown workspace 오류 해결

SH_Roh — Tue, 23 May 2023 03:20:11 +0900

프로젝트에 모노레포를 적용해보는 중에 한 워크스페이스에만 패키지를 추가하기 위해 커맨드를 입력했다.

// yarn workspace [워크스페이스 이름] add [패키지 이름]
yarn workspace admin-front add @mui/material @emotion/react @emotion/styled

하지만 Unknown workspace 라는 오류가 발생했다.

Unknown workspace

해결 방법

1. 루트 package.json의 workspaces의 값들이 배열로 되어있는지 확인

{
  // ...
  "workspaces": [
    "common/*",
    "apps/*"
  ]
 }

루트 디렉토리에 있는 package.json의 workspaces가 배열로 되어있는지 확인한다.

2. workspace 이름과 package.json의 name이 일치하는지 확인

yarn add [워크스페이스 이름] add [패키지]

위 커맨드를 실행할 때의 워크스페이스 이름과 추가하려는 워크스페이스에 있는 package.json의 name이 일치하는지 확인해야 한다.

예를 들어 admin-front라는 프로젝트에만 mui를 추가하고 싶은 경우,

yarn workspace admin-front add @mui/material @emotion/react @emotion/styled

위에서 입력한 admin-front와 apps/admin-front에 있는 package.json의 name이 일치해야 한다.

{
  "name": "admin-front",
  // ...
}

이 이름이 일치하지 않아서 생긴 문제였다.

처음에 프로젝트 세팅을 한 뒤 폴더 이름만 수정했었는데 폴더 이름을 기준으로만 생각하다보니 패키지 이름은 생각하지 못했다. package.json의 name까지 수정을 해주니 해당 오류는 더이상 발생하지 않았다. (아직도 낯설고 어려운 모노레포 )

https://classic.yarnpkg.com/en/docs/cli/workspace

https://stackoverflow.com/questions/60910762/how-can-i-fix-the-yarn-error-unknown-workspace

Delete `␍`eslint(prettier/prettier) 해결하기

SH_Roh — Thu, 18 May 2023 23:10:45 +0900

Delete `␍`eslint(prettier/prettier)

새로 프로젝트를 생성했는데 위와 같은 오류가 발생했다. (전에도 비슷한 오류가 발생했었는데 어떻게 해결했는지 기억이 나지 않아서 정리해보려 한다.)

VSCode의 Change End of Line Sequence를 통해 바꿔줄 수도 있다. 하지만 이는 근본적인 해결방법이 아니며, 모든 파일마다 바꿔주기에는 너무 번거롭다.

해결방법

ESLint 설정 부분에서 rules 옵션에 아래 내용을 추가해주면 된다.

.eslintrc.json

{
  "rules": {
    "prettier/prettier": [
      "error",
      {
        "endOfLine": "auto"
      }
    ]
  }
}

이는 prettier 2.0 버전 이상에서 endOfLine 옵션의 default 값이 auto에서 lf로 바뀌었기 때문이라고 한다. auto로 바꿔주면 더이상 기존의 오류가 발생하지 않는다. :-)

LF vs CRLF

개행 문자는 텍스트의 한 줄이 끝남을 표시하는 문자 또는 문자열이다. 개행 문자에는 Line Feed(LF)와 Carriage Return(CR)이 있다.

CR 과 LF 는 타자기 시절 부터 줄바꿈을 위해 사용하던 방식인데 각각의 의미는 다음과 같다.

LF : 커서를 정지한 상태에서 종이를 한 줄 올리는 동작
CR : 종이를 움직이지 않고 커서를 맨 앞줄로 이동하는 동작

윈도우는 CRLF로 새 줄을 나타내고 유닉스, 리눅스는 LF로 새 줄을 나타낸다. (macOS에서는 버전 9까지 CR로 새줄을 나타내다가 이후부터 LF를 사용한다고 한다.)

https://noogoonaa.tistory.com/62

[JS] 스크롤 프로그레스 바 만들기

SH_Roh — Thu, 4 May 2023 18:40:52 +0900

완성본

프로그레스 바 완성!

HTML

<div class="progressWrap">
  <div class="bar"></div>
</div>

CSS

body {
  margin: 0;
  padding: 0;
  height: 1000px; /* 스크롤을 위해 임시로 추가 */
}

.progressWrap {
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 3px;
  background-color: #fff;
}

.bar {
  width: 0%;
  height: inherit;
  position: absolute;
  z-index: 100;
  background-color: #a9c4ff;
  border-top-right-radius: 3px;
  border-bottom-right-radius: 3px;
  transition: width 300ms;
}

JS

const progressBar = document.querySelector(".bar");

let scrollNum = 0;
let documentHeight = 0;

// 전체 문서에서 얼마나 스크롤되었는지 계산
const getPercent = (scroll, total) => {
  return (scroll / total) * 100;
};

window.addEventListener("scroll", () => {
  // scroll top이기 때문에 height가 5000px이면 5000에서 화면높이를 뺀 값까지만 나온다.
  scrollNum = document.documentElement.scrollTop; // 또는 window.scrollY 사용 가능
  
  // scroll top값을 기준으로 계산할 것이기 때문에 문서의 전체 길이에서 화면 크기만큼 빼준다.
  documentHeight = document.documentElement.scrollHeight - document.documentElement.clientHeight;
  
  // 전체 문서에서 몇 %만큼 스크롤되었는지 계산해 progress bar의 width를 바꿔준다.
  progressBar.style.width = getPercent(scrollNum, documentHeight) + "%";
});

document.documentElement

document.documentElement는 <html>태그와 상응하는 요소로, 다양한 메서드를 지원한다. 이는 유용하지만 몇 가지 주의할 점이 있다.

1. window 객체보다는 document.documentElement 사용하기

창이 차지하는 너비와 높이를 알기 위해 document.documentElement의 clientWidth와 clientHeight를 사용했다. 그런데 window 객체에도 innerHeight, innerWidth 프로퍼티가 있기 때문에 이를 통해 창 크기를 구할 수 있다.

그런데 document.documentElement를 사용하는 이유가 무엇일까?

이는 window.innerHeight/innerWidth의 경우 화면에서 스크롤바가 차지하는 영역을 포함해 값을 계산하기 때문이다. 그에 반해 clientWidth, clientHeight는 스크롤바가 차지하는 공간을 제외해 너비, 높이 값을 계산한다.

보통 스크롤 바 안쪽에서 무언가를 그리거나 위치시킬 때 창의 사이즈를 필요로 하기 때문에 documentElement의 clientHeight/clientWidth를 쓰는 것이 좋다.

아래 예시를 통해 window.innerHeight를 사용했을 때 발생할 수 있는 문제에 대해 알아보자.

body {
  margin: 0;
  padding: 0;
  height: 1000px;
  width: 110vw; /* 화면 너비를 늘려 가로 스크롤바가 생기도록 함 */
}

먼저 화면 너비를 110vw로 늘려서 아래에 가로 스크롤바가 생기도록 한다.

그 후 document.documentElement.clientHeight와 window.innerHeight를 비교해보자.

console.log(document.documentElement.clientHeight, window.innerHeight);

console에 찍힌 값을 보면 window.innerHeight는 가로 스크롤바를 포함한 값이 나온다.

window.addEventListener("scroll", () => {
  // ...
  documentHeight = document.documentElement.scrollHeight - window.innerHeight;
  // ...
});

원래 코드에서 document.documentElement.clientHeight 부분을 window.innerHeight로 변경해보자. 가로 스크롤바가 없을 경우에는 동일하게 잘 동작하지만, 가로 스크롤바가 있는 경우 예상치 못한 결과가 나올 수 있다.

스크롤을 덜내렸는데도 프로그레스 바의 width가 100%로 되어있다.

2. '정확한' 문서 전체 높이 값을 알고 싶다면

document.documentElement는 문서의 루트 요소에 상응하고, 루트 요소엔 콘텐츠 전부가 들어가기 때문에 보통 문서 전체의 크기를 구할 때 document.documentElement의 scrollWidth/scrollHeight를 사용한다.

그런데 스크롤이 없는 경우 scrollHeight가 clientHeight보다 작을 때가 있어 예상대로 동작하지 않을 수 있다.

프로그레스 바 구현에서는 스크롤이 없을 경우 scrollTop이 계속 0이기 때문에 이런 상황은 고려하지 않아도 된다.

하지만 정확한 문서 전체 높이 값을 얻고 싶다면 아래와 같이 여섯개의 프로퍼티가 반환하는 값 중 최댓값을 골라야 한다.

let scrollHeight = Math.max(
  document.body.scrollHeight, document.documentElement.scrollHeight,
  document.body.offsetHeight, document.documentElement.offsetHeight,
  document.body.clientHeight, document.documentElement.clientHeight
);

scrollHeight 사용 시 주의할 점

페이지의 전체 높이를 구할 때 document.documentElement.scrollHeight 대신 document.body.scrollHeight를 사용할 수도 있다.

하지만 기본적으로 scrollHeight는 border과 margin을 제외한 컨텐츠의 전체 높이를 반환하기 때문에 이 역시 예상치 못한 결과가 나올 수 있다.

어떤 상황이 발생할 수 있는지 아래 예시를 통해 확인해보자.

HTML

<body>
  <div class="progressWrap">
    <div class="bar"></div>
  </div>
  <div class="box"></div>
</body>

프로그레스 바 밑에 box라는 클래스명을 가진 div를 추가해준다.

CSS

.box {
  margin-top: 500px;
}

그리고 box에 margin 값을 부여해준다.

JS

window.addEventListener("scroll", () => {
  // documentElement -> body
  documentHeight = document.body.scrollHeight - document.documentElement.clientHeight;
  
  console.log(document.body.scrollHeight, document.documentElement.scrollHeight);
  // ...
});

원래 코드에서 document.documentElement를 document.body로 변경해보자.

scrollHeight에 margin값이 측정되지 않아 스크롤을 다 내리지 않아도 프로그레스 바가 100%에 도달해버리는 것을 볼 수 있다.

콘솔에 찍어보면 document.body.scrollHeight와 document.documentElement.scrollHeight에 차이가 있다.

scrollHeight는 말 그대로 'content의 전체 길이'를 반환하기 때문에 margin과 border는 포함하지 않는다.

이처럼 body 안 요소의 border나 margin 때문에 의도치 않은 결과가 나올 수 있기 때문에 document.documentElement를 사용하는 것이 좋다.

References

몇 줄로 끝내는 인터랙티브 웹 개발 노하우[초급편]

https://developer.mozilla.org/ko/docs/Web/API/Element/clientHeight

scrollHeight, clientHeight, offsetHeight 의 차이

https://ko.javascript.info/size-and-scroll-window

https://stackoverflow.com/questions/21064101/understanding-offsetwidth-clientwidth-scrollwidth-and-height-respectively

[JS] 클로저 - 클로저와 렉시컬 환경

SH_Roh — Wed, 19 Apr 2023 18:42:39 +0900

클로저에 대해 알아보기 전에! 실행 컨텍스트를 잘 모르신다면 아래의 글들을 먼저 읽어보시는 것을 추천드립니다 :)

실행 컨텍스트 - (1) 실행 컨텍스트의 역할, 실행 컨텍스트 스택

실행 컨텍스트 - (2) 실행 컨텍스트의 생성과 식별자 검색 과정

클로저(Closure)

클로저는 자바스크립트의 고유의 개념이 아닌(ECMAScript 사양에도 등장하지 않는다) 함수를 일급 객체로 취급하는 함수형 프로그래밍 언어에서 사용되는 중요한 특성이다.

MDN에서는 클로저에 대해 '함수와 그 함수가 선언된 렉시컬 환경과의 조합'으로 정의하고 있다.

const x = 1

function outerFunc() {
  const x = 10
  
  function innerFunc() {
    console.log(x)
  }
  innerFunc()
}
outerFunc() // 10

위 예제에서 innerFunc의 상위 스코프가 outerFunc이기 때문에 innerFunc 안에서 outerFunc의 변수에 접근 가능하다. 만약 innerFunc의 상위 스코프가 outerFunc가 아닐 경우 outerFunc 함수의 변수에 접근할 수 없다.

이런 현상이 발생하는 이유는 자바스크립트가 렉시컬 스코프를 따르는 프로그래밍 언어이기 때문이다.

렉시컬 스코프

자바스크립트 엔진은 함수를 어디에 호출했는지가 아니라 어디에 정의했는지에 따라 상위 스코프를 결정한다. 이를 렉시컬 스코프라고 한다.

const x = 1

function foo() {
  const x = 10
  bar()
}

function bar() {
  console.log(x)
}

foo() // 1
bar() // 1

위 예제에서 foo 함수와 bar 함수는 모두 전역에 정의된 함수이다. 따라서 상위 스코프는 전역이다. 즉, 함수의 상위 스코프는 함수를 정의한 위치에 의해 결정되고 변하지 않는다.

함수 객체의 내부 슬롯 [[Environment]]

함수가 정의되는 위치와 호출되는 위치는 다를 수 있다. 따라서 렉시컬 스코프가 가능하려면 함수는 자신이 호출되는 환경과는 상관없이 자신이 정의된 환경(상위 스코프)을 기억해야 한다. 이를 위해 함수는 자신의 내부 슬롯 [[Environment]]에 자신이 정의된 환경, 즉 상위 스코프의 참조를 저장한다.

함수 객체의 내부 슬롯 [[Environment]]에 저장된 참조가 바로 상위 스코프이고, 이는 자신이 호출되었을 때 생성될 함수 렉시컬 환경의 '외부 렉시컬 환경에 대한 참조'에 저장될 참조값이다.

const x = 1

function foo() {
  const x = 10
  bar()
}

function bar() {
  console.log(x)
}

foo() // 1
bar() // 1

위 예시에서 foo, bar 함수는 전역에서 함수 선언문으로 정의되었다. 따라서 foo, bar는 모두 전역 코드가 평가될 때 평가되어 함수 객체를 생성한다. 이 때 생성된 함수 객체의 내부 슬롯 [[Environment]]에 전역 렉시컬 환경의 참조가 저장된다.

함수가 호출되면 함수 내부로 코드 제어권이 이동하고, 함수 코드가 평가된다. 이 때 외부 렉시컬 환경에 대한 참조에는 함수 객체의 내부 슬롯 [[Environment]]에 저장된 렉시컬 환경의 참조가 할당된다.

이것이 바로 함수 정의 위치에 따라 상위 스코프를 결정하는 렉시컬 스코프의 실체다.

클로저와 렉시컬 환경

const x = 1

function outer() {
  const x = 10
  const inner = function() { console.log(x) }
  
  return inner
}

const innerFunc = outer()
innerFunc() // 10

위 예시에서 outer 함수를 호출하면 outer 함수는 중첩함수 inner를 반환한 후 더 이상 실행할 코드가 없으므로 실행 컨텍스트 스택에서 제거된다. outer 함수의 실행 컨텍스트가 제거되었으므로 outer 함수의 지역 변수 x에 접근할 수 없어 보이지만 innerFunc의 실행 결과를 보면 outer 함수의 지역 변수 x값이 출력된 것을 볼 수 있다.

이처럼 외부 함수보다 중첩 함수가 더 오래 유지되는 경우 중첩 함수는 이미 생명 주기가 종료한 외부 함수의 변수를 참조할 수 있다. 이러한 중첩 함수를 클로저(Closure)라고 부른다.

함수 코드 평가 과정 - 함수 객체의 [[Environment]]에 전역 렉시컬 환경을 상위 스코프로 저장

outer 함수가 평가되어 함수 객체를 생성할 때, 현재 실행 중인 컨텍스트의 렉시컬 환경(전역 렉시컬 환경)을 [[Environment]] 내부 슬롯에 저장한다.

outer의 [[Environment]]에 저장된 렉시컬 환경을 outer 함수 렉시컬 환경의 외부 렉시컬 환경에 대한 참조에 할당

outer 함수를 호출하면 outer 함수의 렉시컬 환경이 생성되고, outer 함수 객체의 [[Environment]]에 저장된 전역 렉시컬 환경을 outer 함수 렉시컬 환경의 '외부 렉시컬 환경에 대한 참조'에 할당한다. 그리고 중첩 함수 inner가 평가되어 inner의 [[Environment]]에 outer 함수의 렉시컬 환경을 상위 스코프로서 저장한다.

outer 함수의 실행 컨텍스트가 제거되어도 전역 변수 innerFunc가 참조하고 있는 inner 함수가 outer 함수를 참조하고 있기 때문에 outer 함수의 렉시컬 환경은 유지된다.

outer 함수의 실행이 종료하면 inner 함수를 반환하며 outer 함수 실행 컨텍스트가 실행 컨텍스트 스택에서 제거된다. 하지만 outer 함수의 렉시컬 환경까지 소멸하는 것은 아니다.

전역 변수 innerFunc가 inner 함수를 참조하고, inner 함수의 [[Environment]]가 outer 함수의 렉시컬 환경을 참조하고 있으므로 가비지 컬렉션의 대상이 되지 않기 때문이다. 가비지 컬렉터는 누군가가 참조하고 있는 메모리 공간을 함부로 해제하지 않는다.

어떤 함수가 클로저일까?

자바스크립트의 모든 함수는 상위 스코프를 기억하므로 이론적으로는 모든 함수가 클로저이다. 하지만 일반적으로 모든 함수를 클로저라고 하지는 않는다.

상위 스코프의 어떤 식별자도 참조하지 않는 함수는 클로저가 아니다.

function foo() {
  const x = 1
  const y = 2
  
  function bar() {
    const z = 3
    debugger
    console.log(z)
  }
  
  return bar
}

const bar = foo()
bar()

Local: 지역 스코프, Script: 현재 실행 중인 함수, Global: 전역 객체

위 예제의 중첩 함수 bar는 외부 함수 foo보다 더 오래 유지되지만 상위 스코프의 어떤 식별자도 참조하지 않는다.

상위 스코프의 어떤 식별자도 참조하지 않는 경우 대부분의 모던 브라우저는 최적화를 통해 상위 스코프를 기억하지 않는다. 따라서 bar 함수는 클로저라고 할 수 없다.

외부 함수보다 일찍 소멸되는 중첩 함수는 클로저의 본질에 부합하지 않는다.

function foo() {
  const x = 1
  
  function bar() {
    debugger
    console.log(x)
  }
  bar()
}
foo()

bar 함수는 클로저이지만 곧바로 소멸한다.

중첩 함수 bar는 상위 스코프의 식별자를 참조하고 있으므로 클로저이다. 하지만 외부 함수보다 중첩 함수 bar의 생명 주기가 짧기 때문에 생명 주기가 종료된 외부 함수의 식별자를 참조할 수 있다는 클로저의 본질에 부합하지 않는다. 따라서 중첩 함수 bar는 일반적으로 클로저라고 하지 않는다.

외부 함수보다 더 오래 유지되고 상위 스코프를 참조하는 중첩함수가 클로저다.

function foo() {
  const x = 1
  const y = 2
  
  function bar() {
    debugger
    console.log(x)
  }
  return bar
}
const bar = foo()
bar()

상위 스코프의 식별자 중 클로저가 참조하고 있는 식별자만 기억한다.

클로저는 중첩 함수가 상위 스코프의 식별자를 참조하고 있고 중첩 함수가 외부 함수보다 더 오래 유지되는 경우에 한정하는 것이 일반적이다.

클로저인 중첩 함수 bar는 상위 스코프의 x, y 식별자 중 x만 참조하고 있다. 이런 경우 대부분의 모던 브라우저는 최적화를 통해 상위 스코프의 식별자 중에서 클로저가 참조하고 있는 식별자만 기억한다. 클로저에 의해 참조되는 상위 스코프의 변수(위의 경우 foo의 x 변수)를 자유 변수라고 한다.

[JS] 실행 컨텍스트 - (2) 실행 컨텍스트의 생성과 식별자 검색 과정

SH_Roh — Wed, 12 Apr 2023 19:03:52 +0900

스압 주의!

시리즈

실행 컨텍스트 - (1) 실행 컨텍스트의 역할, 실행 컨텍스트 스택

실행 컨텍스트 - (2) 실행 컨텍스트의 생성과 식별자 검색 과정

실행 컨텍스트의 생성과 식별자 검색 과정

아래 예시를 통해 실행 컨텍스트의 생성과 식별자 검색 과정에 대해 알아보자.

var x = 1
const y = 2

function foo (a) {
  var x = 3
  const y = 4
  
  function bar (b) {
    const z = 5
    console.log(a + b + x + y + z)
  }
  bar(10)
}

foo(20) // 42

실행 컨텍스트 생성과 식별자 검색 과정

1. 전역 객체 생성

전역 객체는 전역 코드가 평가되기 이전에 생성된다. 전역 객체에 빌트인 전역 프로퍼티와 빌트인 전역 함수, 표준 빌트인 객체가 추가되며 동작 환경에 따라 클라이언트 사이드 Web API 또는 특정 환경을 위한 호스트 객체를 포함한다.

+ 전역 객체도 프로토타입 체인의 일원이다.

2. 전역 코드 평가

소스코드가 로드되면 자바스크립트 엔진은 전역 코드를 평가한다.

1 - 전역 실행 컨텍스트 생성

비어있는 전역 실행 컨텍스트를 생성해 실행 컨텍스트 스택에 푸시한다. 이때 전역 실행 컨텍스트가 실행 중인 실행 컨텍스트가 된다.

2 - 전역 렉시컬 환경 생성

전역 렉시컬 환경을 생성하고 전역 실행 컨텍스트에 바인딩한다.

렉시컬 환경은 환경 레코드(Environment Record)와 외부 렉시컬 환경에 대한 참조(OuterLexicalEnvironmentReference)로 구성된다.

2-1. 전역 환경 레코드 생성

전역 환경 레코드는 전역 스코프, 전역 객체의 빌트인 전역 프로퍼티와 빌트인 전역 함수, 표준 빌트인 객체를 제공한다.

ES6 이전에는 전역 객체가 전역 환경 레코드의 역할을 수행했다. 하지만 ES6의 let, const로 선언한 전역 변수는 전역 객체의 프로퍼티가 되지 않고 개념적인 블록 내에 존재하게 된다.

이처럼 var로 선언한 전역 변수와 let, const로 선언한 전역 변수를 구분해 관리하기 위해 전역 스코프 역할을 하는 전역 환경 레코드는 객체 환경 레코드와 선언적 환경 레코드로 구성되어 있다.

객체 환경 레코드(Object Environment Record)는 var로 선언한 전역 변수와 함수 선언문으로 정의한 전역 함수, 빌트인 전역 프로퍼티와 빌트인 전역 함수, 표준 빌트인 객체를 관리한다.

그리고 선언적 환경 레코드(Declarative Environment Record)는 let, const로 선언한 전역 변수를 관리한다.

2-1-1. 객체 환경 레코드 생성

객체 환경 레코드는 BindingObject라고 부르는 객체와 연결된다. BindingObject는 '1. 전역 객체 생성' 단계에서 생성된 전역 객체이다.

var로 선언한 전역 변수, 함수 선언문으로 정의된 전역 함수는 객체 환경 레코드에 연결된 BindingObject를 통해 전역 객체의 프로퍼티와 메서드가 된다.

이때 등록된 식별자를 객체 환경 레코드에서 검색하면 전역 객체의 프로퍼티를 검색하여 반환한다. 이것이 전역 객체를 가리키는 식별자(window) 없이 전역 객체의 프로퍼티를 참조(e.g. window.alert을 alert으로 참조)할 수 있는 메커니즘이다.

var x = 1
const y = 2

function foo (a) {
 // ...
}

x는 var로 선언한 변수이기 때문에 '선언 단계'와 '초기화 단계'가 동시에 진행된다. 다시 말해, BindingObject를 통해 전역 객체에 변수 식별자를 키로 등록한 다음, 암묵적으로 undefined를 바인딩한다. 따라서 var 키워드로 선언한 변수는 코드 실행 단계에서 변수 선언문 이전에도 참조할 수 있다. 이것이 변수 호이스팅이 발생하는 원인이다.

함수 선언문으로 정의한 함수가 평가되면 함수 이름과 동일한 이름의 식별자를 BindingObject를 통해 전역 객체에 키로 등록하고 생성된 함수 객체를 즉시 할당한다. 즉, 함수 선언문으로 정의한 함수는 함수 선언문 이전에 호출할 수 있다. 이것이 변수 호이스팅과 함수 호이스팅의 차이이다.

BindingObject를 통해 var로 선언한 전역변수, 함수 선언문으로 선언한 전역함수가 전역 객체의 프로퍼티와 메서드가 된다.

2-1-2. 선언적 환경 레코드 생성

let, const로 선언한 전역 변수는 선언적 환경 레코드에 등록되고 관리된다.

전역 변수 y는 let, const로 선언한 변수이므로 전역 객체의 프로퍼티가 되지 않기 때문에 window.y와 같이 전역 객체의 프로퍼티로서 참조할 수 없다.

또한 '선언 단계'와 '초기화 단계'가 분리되어 진행되기 때문에 런타임에 실행 흐름이 변수 선언문에 도달하기 전까지 일시적 사각지대(Temporal Dead Zone;TDZ)에 빠지게 된다.

const로 선언한 변수 y가 선언적 환경 레코드에 등록된다.

위 그림에서 y 변수에 바인딩되어 있는 <uninitialized>는 초기화 단계가 진행되지 않아 변수에 접근할 수 없음을 나타내기 위해 사용한 표현이다. 실제로 해당 값이 바인딩된 것이 아니다.

let, const로 선언한 변수도 변수 호이스팅이 발생하는 것은 변함이 없으나, 런타임에 컨트롤이 변수 선언문에 도달하기 전까지 일시적 사각지대에 빠지기 때문에 참조할 수 없다.

2-2. this 바인딩

전역 환경 레코드의 [[GlobalThisValue]] 내부 슬롯에 this가 바인딩된다. 일반적으로 전역 코드에서 this는 전역 객체를 가리키므로 전역 환경 레코드의 [[GlobalThisValue]] 내부 슬롯에는 전역 객체가 바인딩된다.

[[GlobalThisValue]] 내부 슬롯에는 전역 객체가 바인딩된다.

참고로 객체 환경 레코드와 선언적 환경 레코드에는 this 바인딩이 없다. this 바인딩은 전역 환경 레코드와 함수 환경 레코드에만 존재한다.

2-3. 외부 렉시컬 환경에 대한 참조 결정

외부 렉시컬 환경에 대한 참조(Outer Lexical Environment Reference)는 현재 평가 중인 소스코드의 상위 스코프를 가리킨다. 이를 통해 단방향 연결 리스트인 스코프 체인을 구현한다.

현재 평가 중인 소스코드는 전역 코드이기 때문에 전역 렉시컬 환경의 OuterLexicalEnvironmentReference에는 null이 할당된다.

외부 렉시컬 환경에 대한 참조에는 null이 할당된다.

3. 전역 코드 실행

전역 코드가 순차적으로 실행되면서 변수 할당문이 실행되어 전역 변수 x, y에 값이 할당되고 foo 함수가 호출된다.

var x = 1
const y = 2

function foo (a) {
 // ...
}

변수 할당문, 함수 호출문을 실행하려면 먼저 변수나 함수 이름이 선언된 식별자인지 확인해야 한다.

이때 동일한 이름의 식별자가 다른 스코프에 여러 개 존재할 수도 있기 때문에 어느 스코프의 식별자를 참조하면 되는지 결정할 필요가 있다. 이를 식별자 결정이라고 한다.

식별자 결정을 위해 실행 컨텍스트에서 식별자를 검색한다.

현재 실행 중인 실행 컨텍스트는 전역 실행 컨텍스트이므로 전역 렉시컬 환경에서 x, y, foo를 검색한다. 만약 검색할 수 없으면 상위 스코프(외부 렉시컬 환경에 대한 참조가 가리키는 렉시컬 환경)로 이동해 식별자를 검색한다.

이것이 스코프 체인의 동작 원리다. (전역 렉시컬 환경에서 검색할 수 없는 식별자는 ReferenceError를 발생시킨다.)

4. 함수 코드 평가

foo 함수가 호출되면 전역 코드의 실행을 일시 중단하고 foo 함수 내부로 코드의 제어권이 이동한다. 그리고 함수 코드를 평가하기 시작한다.

function foo (a) {
  var x = 3
  const y = 4
  
  function bar (b) {
    // ...
  }
  bar(10)
}

1 - 함수 실행 컨텍스트 생성

foo 함수 실행 컨텍스트를 생성하고 실행 컨텍스트 스택에 푸시한다. 이때 foo 함수 실행 컨텍스트가 실행 중인 실행 컨텍스트가 된다.

2 - 함수 렉시컬 환경 생성

foo 함수 렉시컬 환경을 생성해 foo 함수 실행 컨텍스트에 바인딩한다.

2-1. 함수 환경 레코드 생성

함수 환경 레코드는 매개변수, arguments 객체, 함수 내부에서 선언한 지역 변수와 중첩 함수를 등록하고 관리한다.

매개변수, arguments 객체, 함수 몸체에서 선언된 식별자를 등록한다.

2-2. this 바인딩

함수 환경 레코드의 [[ThisValue]] 내부 슬롯에 this가 바인딩된다. 바인딩될 객체는 함수 호출 방식에 따라 결정되며, foo 함수는 일반 함수로 호출되었으므로 this는 전역 객체를 가리킨다.

foo 함수 내부에서 this를 참조하면 함수 환경 레코드의 [[ThisValue]] 내부 슬롯에 바인딩되어 있는 객체가 반환된다.

함수 환경 레코드의 [[ThisValue]]는 함수 호출 방식에 따라 결정된다.

2-3. 외부 렉시컬 환경에 대한 참조 결정

외부 렉시컬 환경에 대한 참조에는 함수 정의가 평가된 시점에 실행 중인 실행 컨텍스트의 렉시컬 환경의 참조가 할당된다.

foo 함수는 전역 코드에 정의된 전역 함수이다. 따라서 foo 함수 정의는 전역 코드 평가 시점에 평가되고, 이 시점의 실행 중인 실행 컨텍스트는 전역 실행 컨텍스트이다. 따라서 외부 렉시컬 환경에 대한 참조에는 전역 렉시컬 환경의 참조가 할당된다.

함수 렉시컬 환경의 외부 렉시컬 환경에 대한 참조는 함수 정의가 평가된 시점에 실행 중인 실행 컨텍스트의 렉시컬 환경의 참조가 할당된다

자바스크립트는 함수를 어디서 호출했는지가 아니라 어디에 정의했는지에 따라 상위 스코프를 결정한다. 그리고 함수 객체는 자신이 정의된 스코프(상위 스코프)를 기억한다.

자바스크립트 엔진은 함수 객체를 생성할 때 현재 실행 중인 실행 컨텍스트의 렉시컬 환경(상위 스코프)을 함수 객체의 내부 슬롯 [[Environment]]에 저장한다. 함수 렉시컬 환경의 외부 렉시컬 환경에 대한 참조에는 함수 객체의 [[Environment]]에 저장된 렉시컬 환경의 참조이다. 즉, 함수 객체의 내부 슬롯 [[Environment]]가 바로 렉시컬 스코프를 구현하는 메커니즘이다.

5. 함수 코드 실행

foo 함수의 소스코드가 순차적으로 실행되면서 매개변수에 인수가 할당되고, 변수 할당문이 실행되어 지역 변수 x, y에 값이 할당된다. 그리고 bar 함수가 호출된다.

이때 식별자 결정을 위해 실행 중인 실행 컨텍스트의 렉시컬 환경에서 식별자를 검색한다. 만약 검색할 수 없으면 상위 스코프로 이동해 식별자를 검색하고, 검색된 식별자에 값을 바인딩한다.

중첩 함수 bar

var x = 1
const y = 2

function foo (a) {
  var x = 3
  const y = 4
  
  function bar (b) {
    const z = 5
    console.log(a + b + x + y + z)
  }
  bar(10)
}

foo(20) // 42

1 - 중첩 함수 코드 평가

bar 함수가 호출되면 bar 함수 내부로 코드 제어권이 이동하고, bar 함수 코드의 평가가 시작된다.

bar 함수의 실행 컨텍스트 생성과 렉시컬 환경의 생성 환경은 foo 함수 코드 평가와 동일하다.

2 - 중첩 함수 코드 실행

매개변수에 인수가 할당되고, 변수 할당문이 실행되어 지역 변수 z에 값이 할당된다. 그리고 console.log(a + b + x + y + z)가 실행된다. 이 코드는 다음과 같은 순서로 실행된다.

1. console 식별자 검색

console 식별자를 스코프 체인에서 검색한다. 식별자를 검색할 때는 언제나 현재 실행 중인 실행 컨텍스트의 렉시컬 환경에서부터 검색하기 시작한다.

실행 중인 실행 컨텍스트는 bar 함수 실행 컨텍스트이기 때문에 bar 함수 실행 컨텍스트의 렉시컬 환경에서 console 식별자를 검색한다. 이곳에는 console 식별자가 없으므로 상위 스코프로 이동해 검색한다. 이곳에도 console 식별자가 없으므로 상위 스코프로 이동해 검색한다.

console 식별자는 전역 렉시컬 환경의 객체 환경 레코드의 BindingObject를 통해 전역 객체에서 찾을 수 있다.

2. log 메서드 검색

console 객체에서 log 메서드를 검색한다. 이때 console 객체의 프로토타입 체인을 통해 메서드를 검색한다.

3. 표현식 a + b + x + y + z의 평가

console.log에 전달할 인수를 평가하기 위해 a, b, x, y, z 식별자를 검색한다.

식별자는 현재 실행 중인 실행 컨텍스트(bar 함수 실행 컨텍스트)의 렉시컬 환경부터 시작해 외부 렉시컬 환경에 대한 참조로 이어지는 렉시컬 환경의 연속에서 검색한다.

4. console.log 메서드 호출

표현식 a + b + x + y + z가 평가되어 생성한 값을 console.log 메서드에 전달해 호출한다.

3 - 중첩 함수 코드 실행 종료

더는 실행할 코드가 없으므로 bar 함수 코드의 실행이 종료된다.

실행 컨텍스트 스택에서 bar 함수 실행 컨텍스트가 제거되고, foo 실행 컨텍스트가 실행 중인 실행 컨텍스트가 된다.

주의할 점

실행 컨텍스트 스택에서 bar 함수 실행 컨텍스트가 제거되었다고 해서 bar 함수 렉시컬 환경까지 즉시 소멸되는 것은 아니다.

객체를 포함한 모든 값은 누군가에 의해 참조되지 않을 때 가비지 컬렉터에 의해 메모리 공간의 확보가 해제되어 소멸된다. bar 함수 렉시컬 환경을 누군가 참조하고 있다면 bar 함수 렉시컬 환경은 소멸하지 않는다.

6. 함수 코드 실행 종료

더 이상 실행할 코드가 없으므로 foo 함수 코드의 실행이 종료된다.

실행 컨텍스트 스택에서 foo 함수 실행 컨텍스트가 제거되고, 전역 실행 컨텍스트가 실행 중인 실행 컨텍스트가 된다.

7. 전역 코드 실행 종료

더는 실행할 전역 코드가 없으므로 전역 코드의 실행이 종료된다.

실행 컨텍스트 스택에서 전역 실행 컨텍스트가 제거되고, 실행 컨텍스트 스택에는 아무것도 남아있지 않게 된다.

시리즈

실행 컨텍스트 - (1) 실행 컨텍스트의 역할, 실행 컨텍스트 스택

실행 컨텍스트 - (2) 실행 컨텍스트의 생성과 식별자 검색 과정

이렇게 실행 컨텍스트에 대해 알아보았다.

전부터 몇 번을 시도했는데 드디어 좀 이해한 것 같다. 그렇다면 다음은 클로저..

역시 직접 써보면 더 이해가 잘된다 :)

[JS] 실행 컨텍스트 - (1) 실행 컨텍스트의 역할, 실행 컨텍스트 스택

SH_Roh — Tue, 11 Apr 2023 19:34:31 +0900

시리즈

실행 컨텍스트 - (1) 실행 컨텍스트의 역할, 실행 컨텍스트 스택

실행 컨텍스트 - (2) 실행 컨텍스트의 생성과 식별자 검색 과정

소스코드의 타입

ECMAScript 사양은 소스코드를 4가지 타입으로 구분한다. 4가지 타입의 소스코드는 실행 컨텍스트를 생성한다.

전역 코드: 전역에 존재하는 소스코드(전역에 정의된 함수, 클래스 등의 내부 코드는 포함 x)
함수 코드: 함수 내부에 존재하는 소스코드(중첩된 함수, 클래스 등의 내부 코드는 포함 x)
eval 코드: 빌트인 전역 함수인 eval 함수에 인수로 전달되어 실행되는 소스코드
모듈 코드: 모듈 내부에 존재하는 소스코드(모듈 내부의 함수, 클래스 등의 내부 코드는 포함 x)

4가지 타입으로 분류하는 이유는 소스코드의 타입에 따라 실행 컨텍스트를 생성하는 과정과 관리 내용이 다르기 때문이다.

출처 - 자바스크립트 Deep Dive

소스코드의 평가와 실행

자바스크립트 엔진은 소스코드를 '소스코드의 평가'와 '소스코드의 실행' 과정으로 나누어 처리한다.

var x;
x = 1;

1. 소스코드 평가

실행 컨텍스트 생성
변수, 함수 식별자를 키로 렉시컬 환경의 환경 레코드에 등록

변수 선언문 var x;를 먼저 실행하고, 이때 생성된 변수 식별자 x는 실행 컨텍스트가 관리하는 스코프(렉시컬 환경의 환경 레코드)에 등록되고 undefined로 초기화된다.

2. 소스코드 실행

런타임 시작
변수, 함수의 참조를 실행 컨텍스트가 관리하는 스코프에서 검색, 취득
소스코드의 실행 결과를 스코프에 등록

소스코드 실행 단계에서는 x = 1;만 실행된다. x에 값을 할당하려면 먼저 x가 선언된 변수인지 확인해야 한다. 이를 위해 실행 컨텍스트가 관리하는 스코프에 x 변수가 등록되어 있는지 확인한다.

x 변수가 스코프에 등록되어 있다면 값을 할당하고 할당 결과를 실행 컨텍스트에 등록해 관리한다.

실행 컨텍스트의 역할

코드가 실행되려면 다음과 같이 스코프, 식별자, 코드 실행 순서 등의 관리가 필요하다.

선언에 의해 생성된 모든 식별자를 스코프를 구분하여 등록하고 식별자에 바인딩된 값의 변화를 지속적으로 관리할 수 있어야 한다.
스코프 체인을 통해 상위 스코프로 이동하며 식별자를 검색할 수 있어야 한다.
현재 실행 중인 코드의 실행 순서를 변경(e.g. 함수 호출에 의한 실행 순서 변경)할 수 있어야 하며 다시 되돌아갈 수도 있어야 한다.

이 모든 것을 관리하는 것이 실행 컨텍스트이다.

실행 컨텍스트는 소스코드를 실행하는 데 필요한 환경을 제공하고 실행 결과를 실제로 관리하는 영역이다.

실행 컨텍스트는 식별자를 등록하고 관리하는 스코프와 코드 실행 순서를 구현한 내부 메커니즘으로, 모든 코드는 실행 컨텍스트를 통해 실행되고 관리된다.

식별자와 스코프는 실행 컨텍스트의 렉시컬 환경으로 관리하고, 코드 실행 순서는 실행 컨텍스트 스택으로 관리한다.

실행 컨텍스트 스택(코드 실행 순서 관리)

const x = 1

function foo() {
  const y = 2
  
  function bar() {
    const z = 3
    console.log(x + y + z)
  }
  bar()
}

foo() // 6

자바스크립트 엔진은 코드를 평가해 실행 컨텍스트를 생성한다. 이 때 생성된 실행 컨텍스트는 스택 자료구조로 관리되고, 이를 실행 컨텍스트 스택이라고 한다.

1. 전역 코드의 평가와 실행

자바스크립트 엔진은 먼저 전역 코드를 평가해 전역 실행 컨텍스트를 생성하고 실행 컨텍스트 스택에 푸시한다.

2. foo 함수 코드의 평가와 실행

전역 함수 foo가 호출되면 전역 코드의 실행은 일시 중단되고 코드의 제어권이 foo 함수 내부로 이동한다.

자바스크립트 엔진은 foo 함수 내부의 함수 코드를 평가해 foo 함수 실행 컨텍스트를 생성하고 실행 컨텍스트 스택에 푸시한다.

3. bar 함수 코드의 평가와 실행

중첩 함수 bar가 호출되면 foo 함수 코드의 실행은 일시 중단되고 코드의 제어권이 bar 함수 내부로 이동한다.

마찬가지로 자바스크립트 엔진은 bar 함수 실행 컨텍스트를 생성해 실행 컨텍스트 스택에 푸시한다.

4. foo 함수 코드로 복귀

bar 함수가 종료되면 자바스크립트 엔진은 bar 함수 실행 컨텍스트를 실행 컨텍스트 스택에서 제거하고, 코드의 제어권은 다시 foo 함수로 이동한다. 그리고 foo 함수는 더 이상 실행할 코드가 없으므로 종료된다.

5. 전역 코드로 복귀

foo 함수가 종료되면 foo 함수 실행 컨텍스트를 실행 컨텍스트 스택에서 제거하고, 코드의 제어권은 전역 코드로 이동한다. 그리고 더 이상 실행할 코드가 없으므로 전역 실행 컨텍스트도 pop되어 실행 컨텍스트 스택에는 아무것도 남지 않게 된다.

소스코드가 평가되면 실행 컨텍스트가 생성되고 실행 컨텍스트 스택의 최상위에 쌓인다. 실행 컨텍스트 스택의 최상위에 존재하는 실행 컨텍스트는 언제나 현재 실행 중인 코드의 실행 컨텍스트이고, 이를 실행 중인 실행 컨텍스트(running execution context)라고 부른다.

렉시컬 환경(식별자와 스코프 관리)

렉시컬 환경(Lexical Environment)은 식별자와 식별자에 바인딩된 값, 그리고 상위 스코프에 대한 참조를 기록하는 자료구조로, 실행 컨텍스트를 구성하는 컴포넌트다.

렉시컬 환경은 다음과 같이 두 개의 컴포넌트로 구성된다.

1. 환경 레코드(Environment Record)

스코프에 포함된 식별자를 등록하고, 등록된 식별자에 바인딩된 값을 관리하는 저장소다.

2. 외부 렉시컬 환경에 대한 참조(Outer Lexical Environment Reference)

상위 스코프를 가리킨다. 이때 상위 스코프란 해당 실행 컨텍스트를 생성한 소스코드를 포함하는 상위 코드의 렉시컬 환경을 말한다. 이를 통해 단방향 연결 리스트인 스코프 체인을 구현한다.

시리즈

실행 컨텍스트 - (1) 실행 컨텍스트의 역할, 실행 컨텍스트 스택

실행 컨텍스트 - (2) 실행 컨텍스트의 생성과 식별자 검색 과정

[VanillaJS, React] 마우스 따라다니는 원 만들기(feat. requestAnimationFrame)

SH_Roh — Sat, 1 Apr 2023 15:55:20 +0900

잘 만들어진 인터랙티브 웹들을 보며 저건 어떻게 만드는걸까 항상 궁금했었다. 인프런을 둘러보다가 몇 줄로 끝내는 인터랙티브 웹 개발 노하우라는 강의를 발견했고, 기초적인 것들을 만들어봐야겠다고 생각했다.

몇 줄로 끝내는 인터랙티브 웹 개발 노하우 [초급편] - 인프런 | 강의

짧은 시간에 실무에서 가장 많이 사용하는 인터랙티브 스킬을 알려드립니다., - 강의 소개 | 인프런

www.inflearn.com

가장 첫 실습인 마우스를 따라다니는 원 만들기를 해보려고 한다.

미리보기!

VanillaJS로 구현해보기

HTML

<div class="box"></div>

먼저 box라는 클래스명을 가진 div를 하나 만들어준다.

CSS

.box {
  background-color: lightgray;
  border-radius: 50%;
  width: 80px;
  height: 80px;
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  z-index: 1001;
  pointer-events: none;
}

position: absolute; 지정
top: 50%; left:50%; 지정: box의 오른쪽 위 모서리가 body의 가운데에 올 수 있도록 해준다.
transform: translate(-50%, -50%); 지정: 요소의 가운데 부분이 가운데로 올 수 있도록 한다.
pointer-events: none; 지정: 마우스 클릭 시 box 뒤에 있는 요소를 클릭할 수 있도록 한다.
z-index를 높게 설정해주어 다른 요소들보다 위에 올라올 수 있도록 한다.

원이 마우스를 따라가도록 만들기

const box = document.querySelector(".box");

window.addEventListener("mousemove", (e) => {
  box.style.top = e.pageY + "px";
  box.style.left = e.pageX + "px";
});

box를 querySelector를 통해 가져온 후 mousemove의 event 값을 console.log로 찍어보면 pageX, clientX, offsetX, screenX 등 여러 값들이 출력되는 것을 확인할 수 있다.

page? client? offset? screen?

pageX, pageY: 스크롤 화면을 포함한 전체 문서를 기준으로 x, y좌표를 반환한다.
clientX, clientY: 브라우저 화면에서의 가로, 세로 좌표를 제공한다. 이 때 스크롤은 무시하고 해당 페이지의 상단을 0으로 측정한다. (현재 보이는 화면 상에서 어느 지점에 위치하는 지를 의미하기 때문에 스크롤 해도 값은 변하지 않음)
offsetX, offsetY: 이벤트 대상 객체에서의 상대적 마우스 좌표 위치를 반환한다. (화면 중간에 있는 박스 내부에서 클릭한 위치를 찾을 때 해당 박스의 왼쪽 모서리 좌표가 0이 된다.)
screenX, screenY: 브라우저 화면이 아닌 모니터 화면을 기준으로 좌표를 제공한다.

브라우저 화면 내에서 스크롤 화면을 포함한 전체 문서에서 따라다니도록 만들 것이기 때문에 여기서는 pageX, pageY 값을 사용해주면 된다.

그래서 window에서 mousemove 이벤트가 발생할 때마다 box style의 top과 left를 해당 좌표로 이동시켜주면 된다.

부드럽게 따라다니기

원이 좀 더 부드럽게 마우스를 따라다니도록 만들어보자.

requestAnimationFrame?

window.requestAnimationFrame(callback);

직접 구현해보기 전에 여기에서 사용할 requestAnimationFrame에 대해 알아보자.

배경

자바스크립트에는 이벤트 루프가 있어 지속적으로 자바스크립트를 실행한다. 과거에는 애니메이션을 구현하기 위해 setTimeout() 또는 setInterval()을 사용했다.

하지만 이는 아무리 정확히 시간을 예측하더라도 브라우저가 다른 작업 중인 경우 setTimeout이 repaint 시간에 맞추지 못해 다음 사이클로 지연될 수 있었다. 그리고 이렇게 되면 애니메이션이 다음 사이클에 두 번 실행되기 때문에 자연스럽지 못한 애니메이션으로 보일 수 있다.

이런 문제점을 해결하기 위해 requestAnimationFrame이 등장했다.

그래서 그게 뭔데?

requestAnimationFrame은 브라우저에게 수행하길 원하는 애니메이션을 알려주고 다음 repaint가 진행되기 전에 해당 애니메이션을 업데이트하는 함수를 호출한다. (애니메이션 전용 API는 아니지만 대부분 애니메이션 활용을 위해 사용된다.)

let request

const performAnimation = () => {
  request = requestAnimationFrame(performAnimation)
  //animate something
}

requestAnimationFrame(performAnimation)

//...

cancelAnimationFrame(request) //stop the animation

위와 같이 사용할 수 있다. 이는 setTimeout, setInterval을 이용한 애니메이션 구현과 비슷해보이지만 매우 다르게 동작한다.

Timeline

아래 그림은 setTimeout이나 setInterval을 사용했을 때의 타임라인이다. 보라색은 render, 초록색은 paint, 노란색은 setTimeout/setInterval 코드의 실행을 의미한다.

https://flaviocopes.com/requestanimationframe/

setTimeout, setInterval은 paint, render가 일어난 후에 일어난다. 위의 그림에서는 하나의 프레임에 한 번만 사용되었기 때문에 정상적으로 동작한다.

https://flaviocopes.com/requestanimationframe/

하지만 애니메이션 호출이 지연될 경우, 이벤트 루프의 코드 블로킹 때문에 특정 프레임에서 setTimeout(setInterval)이 실행되지 않는 경우가 생길 수 있다. 그리고 이 경우 애니메이션이 끊기는 현상이 발생한다.

https://flaviocopes.com/requestanimationframe/

게다가 실행되지 않은 애니메이션이 다음 프레임에서 여러 번 호출되면서 애니메이션이 버벅거리는 결과가 나올 수 있다.

requestAnimationFrame은 아래와 같이 동작한다.

보라색: render, 초록색: paint, 노란색: requestAnimationFrame

모든 requestAnimationFrame의 애니메이션은 항상 렌더링과 페인트 이전에 실행되기 때문에 조금 더 예측 가능한 애니메이션을 만들 수 있다. 그리고 이벤트 루프의 지연 및 블로킹 현상이 나타나지 않아 setTimeout, setInterval에 비해 더 부드러운 애니메이션을 제공한다.

setTimeout, setInterval은 탭이 보이지 않는 상태에서도 계속 돌아간다. 하지만 requestAnimationFrame은 cpu에 매우 친화적이기 때문에 현재 창이나 탭이 보이지 않으면 애니메이션이 중지된다. 이는 cpu 전력 소모를 줄일 수 있고, 배터리 절약에도 성공적이기 때문에 requestAnimationFrame을 사용하면 브라우저는 리소스 사용을 최적화하고 애니메이션을 더 부드럽게 만들 수 있다.

직접 적용해보자!

const box = document.querySelector(".box");

let x = 0;
let y = 0;
let targetX = 0;
let targetY = 0;
const speed = 0.03; // 따라오는 속도

window.addEventListener("mousemove", (e) => {
  x = e.pageX;
  y = e.pageY;
});

const loop = () => {
  // 애니메이션의 가속, 감속
  targetX += (x - targetX) * speed;
  targetY += (y - targetY) * speed;

  box.style.top = targetY + "px";
  box.style.left = targetX + "px";
  
  // 재귀적으로 호출
  window.requestAnimationFrame(loop);
};

loop();

mousemove 이벤트가 발생할 때는 마우스의 x, y 변수만 바꿔주고, requestAnimationFrame에서 바뀐 x, y로 이동을 시켜주는 식으로 코드를 짜주면 된다. (이 때 mousemove 함수 안에서 requestAnimationFrame을 사용하지 않도록 주의하자. 이렇게 되면 함수가 계속 중첩되어 실행된다.)

React로 구현해보기

React 프로젝트에도 한번 적용해보고 싶어서 만들어봤다.

routes/index.tsx

import { useRef } from 'react'

const App = () => {
  const mouseRef = useRef<HTMLDivElement>(null)

  return(
    <div className={styles.pageContainer}>
      <div className={styles.mouseMoveDiv} ref={mouseRef} />
    </div>
  )
}

export default App

div를 만들고, 마우스의 움직임에 따라 이 div를 직접 움직여줄 것이기 때문에 ref를 걸어준다.

그리고 기본적인 스타일을 div에 적용해준다.

routes.module.scss

.mouseMoveDiv {
  position: absolute;
  top: 50%;
  left: 50%;
  z-index: 1001;
  width: 50px;
  height: 50px;
  pointer-events: none;
  background-color: #000000;
  border-radius: 50%;
  opacity: 0.2;
  transition: display 1000ms ease-in-out;
  transform: translate(-50%, -50%);
}

routes/index.tsx

let x = 0
let y = 0
let targetX = 0
let targetY = 0
const speed = 0.05

const App = () => {
  const mouseRef = useRef<HTMLDivElement>(null)
  const requestRef = useRef(0)

  const handleMouseMove: MouseEventHandler = (e) => {
    x = e.pageX
    y = e.pageY
  }

  const loop = useCallback(() => {
    targetX += (x - targetX) * speed
    targetY += (y - targetY) * speed

    if (mouseRef.current) {
      mouseRef.current.style.top = `${targetY}px`
      mouseRef.current.style.left = `${targetX}px`
    }

    requestRef.current = requestAnimationFrame(loop)
  }, [])

  useEffect(() => {
    requestRef.current = requestAnimationFrame(loop)

    return () => cancelAnimationFrame(requestRef.current)
  }, [loop])
  
  return (
    <div className={styles.pageContainer} onMouseMove={handleMouseMove}>
      <div className={styles.mouseMoveDiv} ref={mouseRef} />
    </div>
  )
}

기본적인 구현은 바닐라js에서 만든 방식과 비슷하지만 리액트에서는 requestAnimationFrame을 useEffect안에서 실행해준다.

https://css-tricks.com/using-requestanimationframe-with-react-hooks/

Using requestAnimationFrame with React Hooks | CSS-Tricks

Animating with requestAnimationFrame should be easy, but if you haven’t read React’s documentation thoroughly then you will probably run into a few things

css-tricks.com

추가적인 효과

간단하지만 추가적으로 마우스를 눌렀을 때, 마우스가 브라우저 밖으로 나갔을 때 이벤트를 추가해주었다.

routes/index.tsx

const App = () => {
  // ...
  
  // 마우스 누르고 있을 때 div 색 변경
  const handleMouseDown = () => {
    if (mouseRef.current) {
      mouseRef.current.style.backgroundColor = '#ea3a4b'
    }
  }

  // 마우스를 눌렀다가 뗐을 때 다시 원래 색으로 변경
  const handleMouseUp = () => {
    if (mouseRef.current) {
      mouseRef.current.style.backgroundColor = '#000000'
    }
  }

  // 마우스가 브라우저 안에 들어올 때
  const handleMouseEnter = () => {
    if (mouseRef.current) {
      mouseRef.current.style.display = 'block'
    }
  }

  // 마우스가 브라우저 밖으로 나갈 때 div의 display를 none으로 변경
  const handleMouseLeave = () => {
    if (mouseRef.current) {
      mouseRef.current.style.display = 'none'
    }
  }
  
  return (
    <div
      className={styles.pageContainer}
      onMouseMove={handleMouseMove}
      onMouseDown={handleMouseDown}
      onMouseUp={handleMouseUp}
      onMouseEnter={handleMouseEnter}
      onMouseLeave={handleMouseLeave}
    >
      <div className={styles.mouseMoveDiv} ref={mouseRef} />
    </div>
  )
}

CSS-in-JS를 사용하고 있다면 직접 style을 설정해줄 수 있었겠지만, scss에서는 따로 props를 넘길 수 없기 때문에 그냥 ref에서 직접 스타일을 변경해주었다.

전체 코드

let x = 0
let y = 0
let targetX = 0
let targetY = 0
const speed = 0.05

const App = () => {
  const mouseRef = useRef<HTMLDivElement>(null)
  const requestRef = useRef(0)

  const handleMouseMove: MouseEventHandler = (e) => {
    x = e.pageX
    y = e.pageY
  }

  const loop = useCallback(() => {
    targetX += (x - targetX) * speed
    targetY += (y - targetY) * speed

    if (mouseRef.current) {
      mouseRef.current.style.top = `${targetY}px`
      mouseRef.current.style.left = `${targetX}px`
    }

    requestRef.current = requestAnimationFrame(loop)
  }, [])

  useEffect(() => {
    requestRef.current = requestAnimationFrame(loop)

    return () => cancelAnimationFrame(requestRef.current)
  }, [loop])

  const handleMouseDown = () => {
    if (mouseRef.current) {
      mouseRef.current.style.backgroundColor = '#ea3a4b'
    }
  }

  const handleMouseUp = () => {
    if (mouseRef.current) {
      mouseRef.current.style.backgroundColor = '#000000'
    }
  }

  const handleMouseEnter = () => {
    if (mouseRef.current) {
      mouseRef.current.style.display = 'block'
    }
  }

  const handleMouseLeave = () => {
    if (mouseRef.current) {
      mouseRef.current.style.display = 'none'
    }
  }
  
  return (
    <div
      className={styles.pageContainer}
      onMouseMove={handleMouseMove}
      onMouseDown={handleMouseDown}
      onMouseUp={handleMouseUp}
      onMouseEnter={handleMouseEnter}
      onMouseLeave={handleMouseLeave}
    >
      <div className={styles.mouseMoveDiv} ref={mouseRef} />
    </div>
  )
}

References

http://megaton111.cafe24.com/2016/11/29/clientx-offsetx-pagex-screenx%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90/

https://developer.mozilla.org/ko/docs/Web/API/window/requestAnimationFrame

https://flaviocopes.com/requestanimationframe/

https://velog.io/@khy226/requestAnimationFrame으로-자연스러운-애니메이션-만들기-feat-react-spring

https://www.inflearn.com/questions/485554/requestanimationframe-%EC%9D%B4%ED%95%B4%EA%B0%80-%EC%9E%98-%EC%95%88%EA%B0%80%EC%84%9C-%EA%B7%B8%EB%9F%AC%EB%8A%94%EB%8D%B0%EC%9A%94

[TIL] 23.03.15 TS 핸드북 - Typeof Type Operator

SH_Roh — Thu, 16 Mar 2023 01:23:09 +0900

https://www.typescriptlang.org/ko/docs/handbook/2/typeof-types.html

Documentation - Typeof Type Operator

타입 컨텍스트에서 typeof 연산자 사용하기.

www.typescriptlang.org

typeof 타입 연산자

자바스크립트에 이미 typeof 연산자가 있다.

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Operators/typeof

typeof - JavaScript | MDN

typeof 연산자는 피연산자의 평가 전 자료형을 나타내는 문자열을 반환합니다.

developer.mozilla.org

타입스크립트는 타입 컨텍스트에서 변수나 프로퍼티의 타입을 추론할 수 있는 typeof 연산자를 추가한다.

let s = 'hello';
let n: typeof s; // let n: string

이는 기본 타입에서는 별로 유용하진 않지만, 다른 타입 연산자와 함께 사용해 많은 패턴을 편리하게 표현할 수 있다.

예를 들어, 미리 정의된 유틸리티 타입인 ReturnType<T>부터 살펴보면, 해당 타입은 함수 타입을 받으면서 반환되는 타입을 리턴한다.

type Predicate = (x: unknown) => boolean;
type K = ReturnType<Predicate>; // type K = boolean

ReturnType은 함수 타입을 받기 때문에 함수 이름을 넣으면, 오류가 발생한다.

function f() {
  return { x: 10, y: 3 };
}

// ERROR: 'f' refers to a value, but is being used as a type here. Did you mean 'typeof f'?
type P = ReturnType<f>;

따라서 값과 타입은 같지 않다는 것을 명심하자. 값 f의 타입을 추론하기 위해 typeof를 사용한다.

type P = ReturnType<typeof f>; // type P = { x: number; y: number; }

[TIL] 23.03.13 타입스크립트에서 효율적으로 상수 관리하기

SH_Roh — Tue, 14 Mar 2023 02:14:24 +0900

효율적으로 상수 관리하기

타입스크립트에서는 포괄적인 타입(string, number, ...) 외에도 정확한 값을 타입으로 설정하는 것이 가능하다.

let title: 'typescript';
title = 'javascript'; // Type 'javascript' is not assignable to type 'typescript'

타입스크립트에서는 컴파일러가 자동으로 타입을 추론하는 기능을 제공한다. let은 변수의 값을 언제든 바꿀 수 있기 때문에 더 포괄적인 타입으로 값을 추론하고, const의 경우는 변경이 불가능하기 때문에 리터럴 타입으로도 추론된다.

let title = 'typescript'; // let title: string
const content = 'typescript; // const content: 'typescript'

타입 단언(Type Assertion)을 활용한 상수 관리

let 변수의 경우에도 const처럼 리터럴 타입으로 추론해줄 수 있는데, 그 때 사용하는 것이 as const이다.

let title = 'typescript' as const; // let title: 'typescript'

타입 단언을 활용해서 상수를 관리하는 방법에 대해 알아보자.

const Colors = {
  red: '#FF0000',
  blue: '#0000FF',
  green: '#008000'
}

Colors 변수 내부에 추론된 값을 보면 각 속성이 원시 타입으로 추론된다. 이는 const로 객체를 선언했지만, 객체 내부의 값들은 언제든지 바꿀 수 있기 때문이다.

이 때 타입 단언을 통해 Colors 내부값의 타입을 리터럴 타입으로 변경할 수 있고, 편리하게 상수를 관리할 수 있다.

const Colors = {
  red: '#FF0000',
  blue: '#0000FF',
  green: '#008000'
} as const

enum을 통한 상수 관리

export enum Colors {   
    red="#FF0000",   
    blue="#0000FF",   
    green="#008000", 
}

타입스크립트에서는 enum이라는 객체를 통해 상수를 쉽게 관리할 수 있다.

enum은 타입스크립트에서 제공하는 문법을 아래와 같은 특징을 가진다.

enum은 js 객체이나, 내부 속성을 임의로 변경 불가
enum의 내부 key는 반드시 리터럴 타입(string or number)으로만 사용 가능
enum의 속성값도 리터럴 타입(string or number)만 사용 가능

enum vs as const

그렇다면 상수 관리에 enum, as const 중에 어떤 것을 쓰는 것이 더 좋을까?

enum과 as const는 탄생한 목적 자체가 다르다. enum은 서로 연관된 상수들을 하나의 네임스페이스로 묶어 추상화하기 위해 도입된 것이다. 이를 통해 코드만 보더라도 의도를 명확히 알 수 있어 가독성을 높일 수 있다.

반면 as const는 타입 단언의 한 종류로써 리터럴 타입의 추론 범위를 줄이고 값의 재할당을 막기 위한 목적으로 만들어졌다.

Object(or Array) 리터럴의 as const

let title = 'typescript' as const

as const를 위와 같이 쓸 수도 있지만 그럴 바에는 아예 const로 선언하는 게 좋을 것이다.

그렇지만 원시타입이 아닌 Object나 Array 타입이라면 얘기가 달라진다. 이 둘은 참조 타입이기 때문에 const로 선언해도 내부 프로퍼티의 추론 범위가 한정되지도 않고, 값을 변경할 수도 있다.

const language = {
  korean: "ko",						// "ko"로 추론, readonly 프로퍼티로 변경
  english: "en",					// "en"로 추론, readonly 프로퍼티로 변경
} as const;

// Error: Cannot assign to 'korean' because it is a read-only property
language.korean = "kkk";
// Error: Cannot assign to 'english' because it is a read-only property.
language.english = "eee";

이럴 때 as const를 사용하면 객체의 모든 프로퍼티들이 readonly로 변경되고, 각 프로퍼티의 타입이 할당된 리터럴 값으로 추론된다.

중첩 객체(배열)의 프로퍼티들도 as const를 사용하면 readonly로 변경되고 리터럴 값으로 추론된다.

const obj = {
  a: 10,
  b: [20, 30],
  c: {
    d: {
      e: {
        greeting: "Hello",
      },
    },
  },
} as const;

이렇듯 as const를 사용하면 원시 타입이든 참조 타입이든 값의 재할당을 막기 때문에 의도치않은 변경으로 인한 오류를 없앨 수 있다. 또한, 리터럴 타입의 추론 범위가 리터럴 값 자체로 한정되면서 좀 더 안전하게 코드를 작성할 수 있다.

References

https://blog.toycrane.xyz/typescript에서-효과적으로-상수-관리하기-e926db079f9

https://velog.io/@logqwerty/Enum-vs-as-const