실행은 바로 되는데 결괏값은 나중에 resolve 될 때 결괏값 사용은 더 나중 3번 째 await, 4번 째 await 은 굳이 3번 째 끝날 때까지 기다리고 4번 째를 실행할 필요가 없다. 이렇게 하면 p1 과 p2 를 거의 비슷하게 실행시킬 수 있다. 위 async/await 를 프로미스로 바꿔보자!

catch 는 앞 모든 것의 에러를 담당한다. 이렇게 then 뒤마다 catch 구문으로 에러 처리를 할 수 있다. async/await 일 때도 try/catch 구문을 나눠서 각각 에러를 처리할 수 있다. 위 async 함수를 Promise 로 바꿔보자! await 이 then 이라고 생각하면 편하다. 리턴이 a + b 라면? 이건 참고만.. 위 async/await 를 프로미스로 바꿔보자! 위를 분석해보자! a 함수에서 동기부분은 첫번 째 await 전에 끝난다!! (충격..) 그리고 바로 백그라운드에 await 3개와 then 2개가 등록된다. 프로미스가 아니면 자동으로 resolve 이다. 위의 예를 보면 1 이 프로미스가 아니므로 자동으로 resolve(1) 이 된다. ![](https://velog.velcdn.com/images/yunjwon/post/264f7cb3-a491-4ade-a5c0-b2d

Promise 는 실행은 바로 하되, 결괏값을 나중에 원할 때 쓸 수 있는 것 제일 먼저 딴짓 5 res 5 이렇게 출력된다. new Promise() 의 콜백은 동기이다.

비동기를 async/await 으로 동기로 만들었다. => X > 한번 비동기는 영원히 비동기이다. 콜백이라고 무조건 비동기가 아니다. 비동기 콜백이 비동기이고 동기 콜백은 동기이다. setTimeout 은 비동기 함수이다. backgroud: 운영체제나 JS 엔진 => JS 가 아니다 => 동시로 실행가능 M: 매크로 큐 m: 마이크로 큐 > JS 는 싱글스레드라서 동시 개념이 없다. background 에는 setTimeout의 타이머, 프로미스, 노드의 process.nextTick(), 네트워크 요청(AJAX), 이벤트리스너, 커스텀이벤트 등이 들어올 수 있다. (모두 비동기) 콜 스택에는 anonymous 먼저 바닥에 깔리고 setTimeout 이 실행되고 background에 타이

프로미스 ⇒ 실행은 됐는데 그 결괏값을 나중에 쓸 수 있음! setTimeout 안에 함수를 분리해서 필요할 때 사용할 수 없다. 이 코드는 비동기가 아니다 프로미스를 적용하면 필요할 때 코드나 함수를 사용할 수 있다. 콜백 지옥은 보기도 안좋지만 결괏값을 바로 써야 한다. 따라서 프로미스를 써서 필요할 때 써보자! Promise.all 를 통해 결과를 한번에 처리할 수 있다. Promise.all 단점은 하나라도 에러가 발생하면 캐치 구문으로 넘어간다. 성공한 것들이 의미가 없어지고 어디서 실패했는지 알 수 없다. 그리고 모두 다시 실행해야 한다. Promise.allSettled 를 사용하면 해결할 수 있다. 각각이 성공했는지를 알려주고 어떤 것이 실패했는지, 그 에러가 무엇인지를 then 에서 알려준다. > Promise.all([p1, p2, p3, p4, p5]).then((res) =>

이벤트 리스너 this 가 window로 추측하면 안된다. this를 포함하고 있는 익명함수가 호출되는 것을 확인할 수가 없기 때문에, addEventListener에서 콜백함수가 어떻게 호출되는지 모르기 때문에 this 가 무엇인지는 알 수가 없다. > 함수는 1급 객체로, 파라미터로 넘겨줄 수 있다. header 출력을 보고 내부를 추측해보자. 화살표 함수라면 화살표 함수는 부모로부터 물려받고 화살표 함수 선언이기 때문에 화살표 함수가 호출될 때 부모는 anonymous이고 따라서 this ⇒ window

js ⇒ window, globalThis 로 바뀜 > node ⇒ global, globalThis 로 바뀜 스트릭트 모드에서는 > ES2015 모듈에서는 strict 모드 자동 적용 객체에서 this는 당연히 객체를 가리킨다 => X 객체에서 this는 항상 자기 객체는 아니다. 호출이 어떻게 되는지 보아야 한다. 위 코드에서는 this ⇒ obj this ⇒ window this는 함수가 호출될 때 정해진다! 여기서 this는 객체 자기 자신이다. this ⇒ window bind, apply, call로 묶어주면 this는 괄호 뒤에 오는 객체가 된다. bind는 묶어주고 호출해 주어야 하고 apply, call은 묶어주기만 해도 호출된다. apply, call 차이 apply는 배열로 파라미터를 받고 call은 배열이 아닌 각 인자로 받는다. this ⇒ 기본적으로 window, 스트릭트 모드에서 this

var 함수 스코프 호이스팅이 일어나서 선언문이 모두 위로 올라가서 해석된다. 선언만 되었지 값은 정의 되지 않아서 undefined 상태 undefined 1 이 콘솔에 찍힐 것이다. 호이스팅이 된 이후 코드 해석은 이런 식으로 일어난다. const, let도 호이스팅이 되지만 TDZ(Temporal Dead Zone)로 인해 값을 가져올 수 없다, 즉 에러가 발생한다. (const, let도 호이스팅이 되어서 선언문이 위로 먼저 해석되지만 TDZ 때문에 그 선언된 값에 접근할 수 가 없다.)

선언을 먼저 보자(Lexical Scope) c의 부모 ⇒ anonymous a의 부모 ⇒ anonymous b의 부모 ⇒ c의 부모 ⇒ anonymous 선언 지도 anonymous ⇒ x, c, a c ⇒ y, b b ⇒ z a ⇒ x a에서 b 호출 되는지 보자, a에서 호출 불가, a의 부모를 확인하자 a의 부모는 anonymous, anonymous에서 b 접근 불가 따라서 b 호출 불가 > 자바스크립트는 메모리를 출력할 수 없다.