[FE - ConnecTo] DAY38 TIL👩🏻‍💻

22.09.01 여러 자료를 찾아보며 공부한 내용들을 정리하였습니다 😊
피드백은 언제나 환영입니다! 🍊

타이머

• setTimeout은 무슨 역할을 하는가? setTimeout은 콜백 함수를 호출하지 않음. 함수를 호출한다는 것은 태스크 큐에서 콜 스택으로 넘겨주는 것을 의미하는데, 이 과정은 브라우저의 이벤트 루프가 수행함. 브라우저에게 두 번째 인수(시간)을 전달하면서, 그 시간이 경과하면 첫 번째 인수(콜백 함수)를 호출해달라고 전달하고 종료됨
  
• 브라우저는 시간의 경과를 어떻게 판단하는가? ‘현재 시간 - setTimeout이 호출되었을 때 시간’으로 판단함.
  
• setTimeout이 지연 시간 동안 콜 스택에 들어가 있으면 지연 시간 동안 아무것도 하지 못하는 블로킹 발생 이를 해결하기 위해(비동기를 처리하기 위해) 호출을 위임하는 것
  

---

비동기

• 자바스크립트는 싱글 스레드인가? 자바스크립트 엔진의 콜 스택이 싱글 스레드 방식으로 동작하는 것이고, 자바스크립트는 자바스크립트 엔진 + Web API까지 아우르는 개념임.
  
• 그렇다면, 멀티 스레드는 무조건 좋은가? 멀티 스레드라면 각각의 콜 스택이 함수를 처리할 수는 있지만, 변수 등을 재할당할 때 처리 순서가 보장되지 않음. 그래서 이렇게 동작하면 코딩이 어려워지고, 문제가 발생할 수 있음. 그러나 동시성의 확보를 포기할 수 없었기 때문에 싱글 스레드 방식으로 동작하되, 비동기를 처리하도록 한 것임.
  
• 동시성의 확보 시간을 재는 일을(타이머) 브라우저가 도와주어야 함. 이를 위해, 브라우저 내부의 시간을 잴 수 있는 로직을 통해서 해결할 수 있음.
  

• setTimeout의 지연 시간은 우리가 눈에 보여지는 시간과 같은가? Nope! 오차가 발생함. 태스크 큐로 보내주는 시간이 또 따로 있기 때문에, 지연 시간을 1초로 설정해도 정확히 1초 후에 콜백 함수가 실행되지는 않음.
  
• 비동기 처리를 언제 하는가? 서버와의 통신 시 사용함!
  
• 서버와 브라우저의 통신 클라이언트(브라우저가)가 서버에 리소스를 요청하고 서버를 통해 응답 받는 과정으로, 이 요청에 대한 규약이 HTTP임!
  
• HTTP란? GET, POST, PUT, PATCH, DELETE와 같은 요청 메서드를 사용해서 리소스를 달라고 URL을 통해 요청하는데, 이 URL에 대한 약속이 바로 REST임!
  

• REST를 지켜야 하는 이유
  1. HTTP를 동일한 환경에서 사용하기 위해
  2. 컨벤션을 지키기 위해
• REST API를 알아야 하는 이유 서버가 언제 만들어질 때까지 기다릴 수 없기 때문에 간단한 fake 서버를 만들기 위해서!
  

• 서버와의 통신 기반 Promise, fetch 등 무엇을 써서 비동기를 처리하든 그 근본은 XMLHttpRequest임 → 현재는 JSON을 사용하여 통신을 하지만, 예전에는 XML을 사용했기 때문에 이름이 XMLHttpRequest
  인 것임.
  

• XMLHttpRequest 브라우저 환경에서만 사용 가능한 호스트 객체
  

• send 메서드가 필요한 이유? 페이로드를 전달하기 위해서
  
• GET 메서드의 특징 무엇을 조회할지 알려주어야 하며, GET 메서드는 페이로드를 전달해도 무시됨
  

• 콜백 헬이란? HTTP 요청 시 전달하는 콜백 안에서 또 HTTP 요청을 하는 경우 그 안에 또 콜백이 중첩되는 현상이 많이 발생하는 것
  
• 비동기 함수의 콜백 패턴의 문제점? 함수의 반환 값은 Caller가 받을 수 있음, 즉 명시적으로 호출하지 않으면 받을 수 없음. 이벤트 핸들러는 우리가 명시적으로 호출할 수 없고, 브라우저가 호출하기 때문에 반환 값을 받을 수 없음
  

• 가독성 측면에서, 비동기를 동기처럼 사용하고자 함.

---

프로미스

비동기 처리의 상태 정보와 결과 정보를 가지고 있는 객체로서, 콜백 헬을 해결하기 위한 보완 수단으로 사용함.

생성자 함수로 프로미스 객체를 만들고, 그 안의 함수 로직에다 비동기를 사용함!

• resolve 함수가 하는 일 프로미스 객체의 상태 정보를 fullfilled, 내부 슬롯인 value에 전달받은 인수 할당함
  
• reject 함수가 하는 일 프로미스 객체의 상태 정보를 rejected, 내부 슬롯인 value에 전달받은 인수 할당함
  
• resolve와 reject 사용하여 콜백 함수 사용하지 않고, 프로미스 객체를 반환할 수 있음 원래 리턴하고 싶었던 것은 HTTP 요청의 데이터인 response 값임
  
• 후속 처리 메서드 반환하는 response 값을 처리하기 위한 메서드로, then, catch, finally 사용할 수 있음
  
• then의 역할? 프로미스 객체의 내부 상태가 fullfilled 되었을 때 인수로 전달한 콜백 함수 호출, 호출할 때 resolve의 인수로 전달한 값이 넘어옴(프로미스 객체의 value 값)
  
• catch의 역할? 프로미스 객체의 내부 상태가 rejected 되었을 때 인수로 전달한 콜백 함수 호출, 호출할 때 reject의 인수로 전달한 값이 넘어옴! 그래서 항상 에러를 전달할 수 있게끔 에러를 생성하여 전달하는 것이 바람직함
  (문자열, 숫자 등으로 일관성 없게 사용하지 말 것)
  

💡 프로미스 사용의 궁극적 의의

순차적으로 메서드를 체이닝할 수 있다는 장점이 있음.

즉, 에러 처리를 할 수 있다는 장점이 있지만, 프로미스도 가독성이 좋지만은 않음

---

제너레이터

이터러블의 구현을 간소화하기 위한 용도이며, 많이 쓰이지 않음!

---

async/await

• async 함수에서는 await 키워드를 통해 반환 값만 반환해야 함
• async 함수가 외부 상태와 상호작용하려면 제너레이터를 사용하는 것이 바람직함
• await 키워드 뒤에는 항상 프로미스 객체가 위치해야 함
• 모듈인 경우, await는 항상 async 내부에서만 사용해야 함 밖에서도 사용할 수 있는 것처럼 만들려면 즉시 실행 함수로 감싸서  async 내부에서 사용해야 함
  
• await를 사용하면 전통적인 코딩 방식에서 크게 벗어나지 않기 때문에 가독성이 좋음 await 뒤에는 resolve 처리했을 때의 결과 값이 프로미스 객체로서 전달되는 것이고, catch 구문의 매개변수로 reject 처리했을 때의 결과 값(에러)이 전달됨!
  

---

에러 처리의 중요성

에러는 어떻게든 발생할 수밖에 없고, 이를 빨리 고치는 것이 해결책임. 그러기 위해서는 에러를 빨리 감지해야 함!

발견한 에러는 서버의 로그 파일에 적어두어야 함. 실무에서 에러 처리는 굉장히 신경써야 하는 부분임.

• 에러를 어디서 처리할 것인가? (1) 에러가 발생하는 지점(발생 원인)에서 처리 에러가 발생하는 지점에서 처리하려면 그 발생 지점마다 에러 처리 로직을 작성해야 한다는 단점이 있음. (2) 호출된 지점(상위 레벨)에서 에러 처리 발생 원인에서 처리하면 발생하는 단점을 해결하기 위해 보편적으로 상위 레벨에서 에러를 처리함.
  

상위 레벨에서 에러를 처리하기 위해서는 Caller(호출자)로 에러가 전파되어야 함

우리가 호출했으면 우리가 호출한 쪽으로 에러가 전파되지만, 우리가 호출하지 않는 비동기 함수 같은 경우는 에러가 소실됨!