TIL 13 | SPA & routing

grighth12·2021년 8월 23일

TIL history API

TIL

목록 보기

13/15

배운 것

SPA

SPA 이전의 역사로, SPA가 왜 등장했는지 알아보았다.

1. 일반적인 정적인 웹페이지

html파일 여러개가 a 태그로 연결되어 있다.
url(href)이 파일 경로가 된다.
페이지 이동 시 새로고침이되면서 서버로부터 전체 파일을 다시 내려받는다.
웹 어플리케이션이라기 보다는 웹페이지의 구성이다.
만약, 게시판을 만든다고 생각하면 모든 게시글 마다 하나의 html이 필요하다.

2. 웹 어플리케이션

웹 페이지의 단점을 보완한다.
정적인 파일을 웹 서버로 제공하는 방식 뿐만 아니라, PHP, Java, Node.js 등을 이용해 동적으로 HTML을 생성해서 제공한다.
정적 웹 페이지와는 서버에서 존재하는 HTML을 물리적으로 내려주느냐, 서버에서 어떤 로직을 통해서 HTML 뭉치를 만들어 내려주느냐의 차이가 있다.
단점
DOM 조작 시점이 중요해진다. index.js로 DOM을 한 번에 조작하는 게 아니라, 스크립트 로딩 때 DOM을 조작하는 작업을 각각하게 된다.
똑같은 페이지가 서버에서도 렌더링 되고, 클라이언트에서도 렌더링 돼야 하면 복잡하다.
- 서버와 클라이언트에서 쓰는 언어가 다를 경우 같은 로직이지만 다른 언어로 반복하여 작성해야 하고, 똑같은 로직이더라도 버그가 발생할 수 있는 문제점이 있다.
- UI를 생성하는 부분을 템플릿화하여 서버와 클라이언트에서 동일하게 쓸 수 있게끔 했지만 환경에 따라 동작이 100% 일치하지 않았다.
- 또, 궁극적으로 유저 인터랙션 처리(JS 이벤트 바인딩)은 클라이언트 사이드에서 해야하므로 결국 모든 처리를 서버에서 하는 것은 불가능하다.

3. SPA(Single Page Application)

서버는 API만 처리하고, 모든 렌더링을 클라이언트 사이드에서 한다.
서버와 클라이언트가 완전히 분리된다.
서버에서는 요청에 따른 JSON만 내려주고, 별도의 클라이언트 어플리케이션을 구성한다.
클라이언트에서 html 파일은 index.html 하나만 존재하기 때문에 Single Page Application이라고 한다.
- 클라이언트에서 url을 보고 어떤 페이지를 그릴지 동적으로 처리한다.
이전 방식에서는 페이지를 이동할 때마다 페이지의 모든 내용을 새로 불러와야 하지만, SPA는 처음에 필요한 html, css, javascript를 모두 불러온다. 이후에는 렌더링만 동적으로 하므로 처음 로딩 이후에는 네트워크 부담이 줄어드는 효과가 있다.

SPA는 처음에 모든 파일을 다 불러오므로 초기 로딩 속도가 느릴 수 있다. 초기 로딩 속도 개선을 위해 비동기 로딩(페이지로 이동하거나, 마우스를 올리는 등 필요한 시점에 파일을 로딩)을 이용하여 해결할 수 있다.

hashbang과 history api

hashbang

url 맨 뒤에 #을 이용해서, #뒤의 값을 보고 어떤 페이지로 갈지 처리하는 방식이다.
(같은 페이지 내의 요소를 태그의 id의 위치로 이동할 때 사용하기도 합니다.)

https://localhost:5500/#detail -> detail 페이지로 이동
https://localhost:5500/#qna -> qna 페이지로 이동

locatin.hash를 통해서 어떤 페이지를 렌더링할지 정하는 로직을 이용한다.

cosnt { hash } = location;

if( hash === "" ) {
  // 홈 페이지 렌더링
} else if (hash === "qna") {
 // qna 페이지 렌더링 
}
...

단점

url querystirng을 쓰기가 까다롭다.

https://localhost:5500/#detail/?id=1
-> hash 값을 제대로 읽어오지 못하게 됨

https://localhost:5500/?id=1/#detail
-> 이상한 형태로 쓸 수 있음

일반적인 보통의 애플리케이션 url과 다르다.

history api를 제대로 지원하지 않는 옛날 HTML5 이전 브라우저에서도 돌아간다는 장점 때문에 예전에 많이 사용했지만, 최근에는 거의 쓰이지 않는다.

history api

브라우저에서 페이지 로디을 하면, 세션 히스토리를 갖는다.
세션 히스토리는 페이지를 이동할 때마다 pushState를 통해 쌓이게 되며, 뒤로 가거나 앞으로 갈 때 참고하여 이동한다.
pushState, replaceState 두 개의 함수로 화면 이동없이 현재 url을 업데이트 할 수 있다.
- pushState: 세션 히스토리에 새 url 상태를 쌓는다.
- replaceState: 세션 히스토리에 새 url 상태를 쌓지 않고, 현재 url을 대체한다. 즉, 현재 url은 세션 히스토리에서 사라진다. (ex. 뒤로가기 하면 안되는 상황, form 처리 이후)
hashbang과 달리 일반적인 url 형식을 따르기 때문에, query string, parameter도 자유롭게 붙일 수 있다.

	/#detail-1 -> /detail/1

location.pathname을 통해서 어떤 페이지를 렌더링할지 정하는 로직을 사용한다.

cosnt { pathname } = location;

if( pathname === "/" ) {
  // 홈 페이지 렌더링
} else if (pathname === "/qna") {
 // qna 페이지 렌더링 
}
...

함수들

pushState(state, title, url)
state: 다음으로 이동할 url에 전달할 값, history.state로 가져올 수 있다.
title: 브라우저의 타이틀을 변경할 수 있지만 대부분의 브라우저에서 지원하지 않아 빈 문자열을 넣는다.
url: a 태그를 클릭하거나, location.href로 url을 변경하는 것과 다르게, 이 url이 변경된다고 해서 화면이 리로드되지 않는다.
replaceState(state, title, url)
- 매개변수는 위와 동일하다.
- 뒤로 가기를 방지하기 위해 현재 url을 대체할 때 쓴다.

주의 사항
만약 페이지를 새로고침(리로딩)하게 되면 서버가 해당하는 html 파일을 찾고, 404 Not Found를 뱉을 수 있다. 따라서 어떤 url을 요청하든 서버가 index.html을 주도록 해야한다. 이러한 옵션은 아마존에도 있고, 로컬에서는 npx serve -s로 가능하다.