전통적인 콜백 패턴의 단점들([비동기 처리를 수행하는 비동기 함수는 전통적으로 콜백 패턴을 사용한다. 비동기 처리를 위한 콜백 패턴은 callback hell을 발생시켜 가독성을 나쁘게 하고, 비동기 처리 중 발생한 에러의 예외 처리가 곤란하며, 여러 개의 비동기 처리를 한 번에 처리하는 데도 한계가 있다.](https://hardy716.notion.site/callback-hell-d6b9b42e3b4a41119770695417e0b67f) - 비동기 처리를 위한 콜백 패턴)을 보완하고 비동기 처리 시점을 명확하게 표현하기 위해 ES6에서는 프로미스(Promise)를 도입했다.
비동기 함수를 호출하면 함수 내부의 비동기로 동작하는 코드가 완료되지 않았다고 해도 기다리지 않고 즉시 종료되기 때문에 비동기 함수 내부의 비동기로 동작하는 코드는 비동기 함수가 종료된 이후에 완료된다.
따라서 비동기 함수 내부의 비동기로 동작하는 코드에서 처리 결과를 외부로 반환하거나 상위 스코프의 변수에 할당하면 기대한 대로 동작하지 않는다.
<!DOCTYPE html>
<html>
<body>
<script>
function get(url) { // 비동기 함수
// XMLHttpRequest 객체 생성
const xhr = new XMLHttpRequest();
// 서버 응답 시 호출될 이벤트 핸들러
xhr.onreadystatechange = function () {
// 서버 응답 완료가 아니면 무시
if (xhr.readyState !== XMLHttpRequest.DONE) return;
if (xhr.status === 200) { // 정상 응답
console.log(xhr.response);
// 비동기 함수의 결과에 대한 처리는 반환할 수 없다.
return xhr.response; // ①
} else { // 비정상 응답
console.log('Error: ' + xhr.status);
}
};
// 비동기 방식으로 Request 오픈
xhr.open('GET', url);
// Request 전송
xhr.send();
}
// 비동기 함수 내의 readystatechange 이벤트 핸들러에서 처리 결과를 반환(①)하면 순서가 보장되지 않는다.
const res = get('<http://jsonplaceholder.typicode.com/posts/1>');
console.log(res); // ② undefined (get 함수가 반환한 값을 참조할 수 없다.)
</script>
</body>
</html>
②에서 get 함수가 반환한 값을 참조할 수 없는 이유
get 함수가 호출되면 get 함수의 실행 컨텍스트가 생성되고 호출 스택(실행 컨텍스트 스택)에서 실행된다.
get 함수가 반환하는 xhr.response는 readystatechange 이벤트 핸들러가 반환한다. 이때 readystatechange 이벤트의 발생 시점을 명확히 알 순 없지만 항상 get 함수가 종료한 이후 발생한다.
get 함수가 종료하면 곧바로 console.log(②)가 호출되어 호출 스택에 들어가 실행된다. (만약 console.log가 호출되기 직전에 readystatechange 이벤트가 이미 발생했다고해도 이벤트 핸들러는 console.log 보다 먼저 실행되지 않는다)
readystatechange 이벤트의 이벤트 핸들러는 이벤트가 발생하면 즉시 실행되는 것이 아니라 이벤트가 발생하면 일단 태스크 큐로 들어가고 호출 스택이 비면 그때 이벤트 루프에 의해 호출 스택으로 들어가 실행된다. (만약 console.log 호출 시점 이전에 readystatechange 이벤트가 이미 발생했다하더라도 get 함수가 종료하면 곧바로 console.log가 호출되어 호출 스택에 들어가기 때문에 readystatechange 이벤트의 이벤트 핸들러는 console.log가 종료되어 호출 스택에서 빠진 이후 실행된다)
위 예제 코드에서 알 수 있듯이, 비동기 함수의 처리 결과를 반환하는 경우에는 순서가 보장되지 않기 때문에 그 반환 결과를 가지고 후속 처리를 할 수 없다. 즉, 비동기 함수의 처리 결과에 대한 처리는 비동기 함수의 콜백 함수 내에서 처리해야 한다.
비동기 함수의 처리 결과를 가지고 다른 비동기 함수를 호출해야 하는 경우, 함수의 호출이 중첩(nesting)되어 복잡도가 높아지는 콜백 헬(Callback Hell) 현상이 발생한다.
https://medium.com/dsc-srm/javascript-callback-hell-or-pyramid-of-doom-4f786d14b997 JavaScript Pyramid of Doom - How To Spot and Fix by Aphinya Dechalert
콜백 방식의 비동기 처리가 갖는 문제점 중에서 가장 심각한 것은 에러 처리가 곤란하다는 점이다.
try {
setTimeout(() => { throw new Error('Error!'); }, 1000);
} catch (e) {
console.log('에러를 캐치하지 못한다..');
console.log(e);
}
에러는 **호출자(caller) 방향 : 콜 스택의 아래 방향(실행 중인 실행 컨텍스트가 푸시되기 전에 푸시된 실행 컨텍스트 방향)**으로 전파된다. 하지만 앞에서 살펴본 바와 같이 setTimeout 함수의 콜백 함수를 호출한 것은 setTimeout 함수가 아니기 때문에 콜백 함수가 발생시킨 에러는 catch 블록에서 캐치되지 않아 프로세스는 종료된다.
ES6에서 도입된 Promise는 호스트 객체가 아닌 ECMAScript 사양에 정의된 표준 빌트인 객체이다.
프로미스(Promise 객체)는 Promise 생성자 함수를 new 연산자와 함께 호출하여 생성한다.
[new Promise(executor)](<https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Promise/Promise#매개변수>)
// Promise 객체의 생성
const promise = new Promise((resolve, reject) => {
// 비동기 작업을 수행한다.
if (/* 비동기 작업 수행 성공 */) {
resolve('result');
}
else { /* 비동기 작업 수행 실패 */
reject('failure reason');
}
});
프로미스는 아래와 같이 현재 비동기 처리가 어떻게 진행되고 있는지를 나타내는 상태 정보를 가진다.
| 프로미스의 상태 정보 | 의미 | 상태 변경 조건 |
|---|---|---|
| pending | 비동기 처리가 아직 수행되지 않은 상태 | 프로미스가 생성된 직후 기본 상태 |
| fulfilled | 비동기 처리가 수행된 상태(성공) | resolve 함수 호출 |
| rejected | 비동기 처리가 수행된 상태(실패) | reject 함수 호출 |
모던 자바스크립트 Deep Dive, p.851, 그림 45-1 참조
fulfilled 또는 rejected 상태는 모두 비동기 처리가 수행된 상태(settled 상태)이다.
pending 상태에서 settled 상태로 변화할 수는 있지만, settled 상태에선 더는 다른 상태로 변화할 수 없다.
프로미스는 비동기 처리 상태와 더불어 비동기 처리 결과도 상태로 갖는다. 즉, 프로미스는 비동기 처리 상태와 처리 결과를 관리하는 객체이다.
모던 자바스크립트 Deep Dive, p.852, 그림 45-2
모던 자바스크립트 Deep Dive, p.852, 그림 45-3 참조