[데브코스] TIL-112 fetch API, history API

fetch API 란?

 

  1. 비동기 HTTP 요청을 좀 더 쓰기 편하게 해주는 API이다. XMLHTTPRequest를 대체하며, Promise기반으로 동작한다.

  2. fetch는 HTTP 에러가 발생하더라도 reject되지 않는다.

  3. 네트워크 에러나 요청이 완료되지 못한 경우에만 reject 된다. 따라서 실제로 fetch가 성공했는지 확인을 해야한다. response의 status code나 ok를 체크하는 것이 좋다.

  4. 참고로 ok는 status가 200-299 사이인 경우만 true가 되기 때문에, 300대 status에도 처리를 해야한다면 사용이 어려울 수 있다.

---

fetch API 사용하기

 

  1. fetch의 기본 응답 결과는 Response 객체이다. 따라서 json()이나 text()로 변환해서 사용해야 한다.

fetch('<https://kdt.roto.codes/todos>')
	.then(res => res.json())
	.then(todos => {
		console.log(todos)
	})

 

  2. blob()은 이미지 처리하는데 사용할 수 있다.

fetch(imageUrl) // imageUrl에는 실제 url이 들어가면 된다.
	.then(res => res.blob())
	.then(data => {
		const url = URL.createObjectURL(data)
		$image.src = url // $image는 img 태그가 들어가 있다고 가정한다.
		document.querySelector('body').appendChild($image)
	})

 

  3. fetch의 두번째 인자로 옵션을 줄 수 있다. 옵션을 주지 않는 경우의 method는 기본 값으로 GET을 넘긴다.

const headers = new Headers()
headers.append('x-auth-token', 'TOKEN')

fetch('<https://kdt.roto.codes/product>', {
	method: 'POST',
	headers,
	body: JSON.stringify(product)
})

---

history API 란? 

 

  1. 브라우저에서 페이지 로딩을 하면, 세션 히스토리라는 것을 갖는다. 세션 히스토리는 페이지를 이동할 때마다 쌓이게 된다. 이를 통해, 뒤로가기 버튼을 눌렀을 때 이전 페이지로 가거나 다시 앞으로 가는 등의 이동이 가능하다. 실제로 페이지가 이동하는 것은 아니고 url을 업데이트하는 식이기 때문에 SPA가 가능해지게 된다.

---

pushState

  세션 히스토리에 새 url 상태를 쌓는 함수이다.

history.pushState(state, title, url)

• state: history.state에서 꺼내쓸 수 있는 값이다. 보통은 null값을 보낸다.
• title: 변경될 페이지의 title을 가리키는 값인 것 같지만 거의 대부분의 브라우저에서 지원하지 않는다. 그래서 보통 null이나 빈 string을 넣는다.
• url: 세션 히스토리에 새로 넣을 url이다. 해당 함수에서 제일 중요한 파라미터이다. a 태그를 클릭하거나 location.href로 url을 변경하는 것과는 다르게 url이 변경된다고 해서 화면이 리로드 되지는 않는다.

---

replaceState

 

  세션 히스토리에 새 url 상태를 쌓지 않고, 현재 url을 대체하는 함수이다. 보통 뒤로가기를 막아야 하는 경우에 사용한다. 예를 들면, 게시글 작성 완료 후에 뒤로가기를 했을 때 다시 게시글 작성 페이지로 이동하지 않도록 해야하기 때문에 이 url을 다른 url로 대체하여 이동을 막는다.

history.replaceState(state, title, url)

• state, title: pushState와 같은 설명이다.
• url: 세션 히스토리에서 현재 url을 대체할 url이다. 나머지는 pushState와 같다.

---

  history API를 이용하면 화면 이동을 일으키지 않고도 브라우저의 url을 바꿀 수 있다. history API로 url을 변경한 후 새로고침하면, 변경된 url의 실제 파일을 찾으려고 하기 때문에 404 에러가 난다. 그러므로 404 에러가 났을 경우, root의 index.html로 요청을 돌려주는 처리가 필요하다.

 

오늘을 마무리 하며

 

  fetch API를 통해서 통신하는 방법과 history API를 통해서 SPA를 구현하는 방법에 대해서 공부했다. fetch API의 경우 브라우저에 내장되어 있는 API이기 때문에 별도의 설치 없이 사용이 가능하다는 점을 알고 있다. 하지만 위에서도 언급했듯이 HTTP 에러가 발생해도 reject되지 않기 때문에 별도의 확인 작업이 필요하다는 점이 조금은 불편하다고 느껴졌다. 물론 코드를 몇 줄 추가하여 확인하는 작업은 그리 어려운 점이 아닐 수 있겠지만, try catch 문에서 바로 잡아낼 수 있다면 더 직관적인 코드들을 작성할 수 있지 않을까 생각이 들었다. history API의 경우 강의를 통해 처음 듣게 되었는데 SPA를 구현할 수 있는 다양한 수단이 많이 있구나 정도로 받아 들인 것 같다. 다만 약간의 속임수(?)가 섞인 방법이라는 느낌이 들긴 한다. ㅎㅎ