공부한 내용 📘

• fetch API
• History API

fetch API

XMLHTTPRequest 객체와 마찬가지로 HTTP 요청 전송 기능을 제공하는 클라이언트 사이드 Web API

프로미스를 지원하여 비동기 처리를 위한 콜백 패턴의 단점에서 자유로운 fetch.

fetch 함수에는 HTTP 요청을 전송할 URL과 HTTP 요청 메서드, HTTP 요청 헤더, 페이로드 등을 설정한 객체를 전달한다.

이러한 fetch 함수는 HTTP 응답을 나타내는 Response 객체를 래핑한 Promise 객체를 반환한다.

HTTP 응답을 나타내는 Response 객체를 래핑한 프로미스를 반환하므로 후속 처리 메서드(then, catch, finally)를 통해 프로미스가 resolve한 Response 객체를 전달 받을 수 있다. 이 Response 객체를 Response.prototype.json 메서드를 이용하여 역직렬화 하여 사용할 수 있다.

fetch 함수에서 중요한 것은 fetch 함수가 반환하는 프로미스는 기본적으로 HTTP 에러가 발생해도 에러를 reject 하지 않고 불리언 타입의 ok를 false로 설정한 Response 객체를 resolve 한다. 오프라인 등의 네트워크 장애나 CORS 에러에 의해 요청이 완료되지 못한 경우에만 프로미스를 reject 한다.

다음과 같은 상황을 예방하기 위해 아래 코드처럼 ok 상태를 확인해줄 수 있다.

const URL = 'https://~~~~~~~~'

fetch(URL) {
	.then(res => {
      // res는 HTTP 응답을 나타내는 Response 객체임.
    	if (!res.ok) throw new Error(res.statusText);
      
      // 응답 객체 역직렬화
      	return res.json();
    })
}

다음의 예제 코드로 GET, POST, PATCH, DELETE 등 각각의 상황에 맞게 HTTP 요청을 전송 할 수 있다.

const request = {
  get(url) {
	return fetch(url);  
  },
  post(url, payload) {
  	return fetch(url, {
    	method: 'POST',
        headers: {'content-Type': 'application/json'}
		body: JSON.stringify(payload)
    });
  },
  patch(url, payload) {
  	return fetch(url, {
    	method: 'PATCH',
        headers: {'content-Type': 'application/json'}
		body: JSON.stringify(payload)
    });
  },
  delete(url) {
  	return fetch(url, { method: 'DELETE'});
  },
}

이후 요청 코드에서 get, delete는 URL만 넣어줘도 실행이 되고, post, patch는 페이로드 부분까지 넣어주면 HTTP 요청이 진행된다.

History API

History API는 브라우저의 세션 기록을 조작할 수 있는 메소드를 담고 있는 객체로 기본적으로 뒤로가기, 앞으로 가기, 페이지 이동 등을 조작할 수 있다.

history.pushState() 를 통해 새로운 주소 목록을 추가하고 이전 url의 주소가 남아 브라우저의 뒤로가기 버튼이 활성화 됨.

history.replaceState() 위와 동일한 기능을 하지만 주소 목록에 추가하지 않기 때문에 뒤로가기 버튼이 활성화 되지 않음.

두 함수는 세 가지의 인자를 가지는데 앞의 두 인자는 보통 null을 전달하고 마지막 세 번째 인자에 변경할 url 주소를 넣어주면 된다.

History API에 대해 정확히 알고 넘어가야 할 점은, 화면 이동 없이 브라우저 url만 변경이 가능하고, 그에 맞는 데이터를 새로고침 없이 렌더링 하여 보여줄 수 있다. 중요한 것은 history API로 url 변경 후 새로고침 하면 변경된 url의 실제 파일을 찾으려 하기에 404에러가 발생한다. 이 상황에서 root의 index.html로 요청을 돌려주는 처리가 필요하다(안하면 로컬에서는 잘 작동하지만, 배포 했을 때에는 잘 작동하지 않을 수 있다).

이러한 원리를 잘 적용하기 위해서는 렌더링이 언제 어떻게 되느냐에 대한 완벽한 이해가 필요해 보인다.