SPA의 히스토리 관리
기본적인 SPA는 CSR(Client Side Rendering, 클라이언트 사이드 렌더링) 방식을 채택한다.
필요한 부분만 렌더링하며 새로고침이 없고 변하는 부분만 새로 그리는 것인데,
URL이 바뀌지 않기에 히스토리 관리가 어려워질 수 있다. 특히 ajax 같은 경우
히스토리가 없어서 사용자가 폼 데이터를 전송한 페이지를 북마크해도
다음에 재접속했을 때 그 페이지가 아니라 초기 페이지를 보게 된다.
SPA를 구현하는 다른 방식인
Hash 방식의 경우 URL는 똑같고
URI의 차이가 생겨서 히스토리 관리가 가능해진다.
해시는 변경돼도 서버에 페이지가 갱신되지 않는다.
해시는 URI에서 #로 시작하는 문자열이다.
(문서 내의 참조이기 때문이다. 문서의 특정 부분에 id를 줘서 a 링크를 거기 거는 방식과 똑같음)
URI(Uniform Resources Identifier)는 자원을 식별할 수 있는 문자열이며 가장 큰 개념이다.
URI는 URL(Uniform Resource Locator)를 포함하는 큰 개념이다.
순수 자원(html, 이미지 파일, css 등)을 가리키는 것만 URL이면서 URI이다.
가령 내가 구글에 'uri'라고 검색했더니 주소창에 http://www.google.co.kr/search?q=uri 라고 나온다고 가정해보자.
이 때 URL은 google.co.kr/search 까지이다. 물음표(?) 뒤의 q=uri는 쿼리문 식별자이다.
그래서 이 부분은 URI이긴 하지만 URL은 아니다(쿼리문 자체가 자원은 아니기에).
URL과 URI의 차이에 대한 더 자세한 설명은 여기서 볼 수 있다.
현재 많은 SPA들은 해시 방식을 쓰거나 SPA 라우터와 함께 history API를
사용해 페이지를 분리해 히스토리를 관리하고 있다.
ajax 요청은 주소창의 URL을 변경시키지 않는다.
이는 브라우저의 뒤로가기,
앞으로가기 등의 history 관리가 동작하지 않음을 의미한다.
따라서 history.back(), history.go(n) 등도 동작하지 않는다.
주소창의 URL이 변경되지 않기 때문에 새로고침을 해도 언제나 첫페이지가 다시 로딩된다.
동일한 하나의 URL로 동작하는 ajax 방식은 SEO 이슈에서도 자유로울 수 없다.
ajax 방식은
불필요한 리소스 중복 요청을 방지할 수 있고
새로고침이 없는 사용자 경험을 구현할 수 있다는 장점이 있지만
history 관리가 되지 않는 단점이 있다.
이를 보완한 방법이 Hash 방식이다.
Hash 방식은 URI의 fragment identifier(#service)의 고유 기능인 앵커(anchor)를 사용한다.
fragment identifier는 hash mark 또는 hash라고 부르기도 한다.
hash 방식의 단점은 url에 불필요한 #이 들어간다는 것이다.
일반적으로 hash 방식을 사용할 때 #!을 사용하기도 하는데 이를 해시뱅(Hash-bang)이라고 부른다.
hash 방식은 과도기적 기술이다.
HTML5의 History API인 pushState가 모든 브라우저에서 지원이 된다면
해시뱅은 사용하지 않아도 되지만 현재 pushState는 일부의 브라우저(IE 10 이상)에서만 지원이 가능하다.
또 다른 문제는 SEO 이슈이다.
웹 크롤러는 검색 엔진이 웹사이트의 콘텐츠를 수집하기 위해
HTTP와 URL 스펙(RFC-2396같은)을 따른다.
이러한 크롤러는 JavaScript를 실행시키지 않기 때문에 hash 방식으로 만들어진 사이트의 콘텐츠를 수집할 수 없다.
구글은 해시뱅을 일반적인 URL로 변경시켜 이 문제를 해결한 것으로 알려져 있지만 다른 검색 엔진은
hash 방식으로 만들어진 사이트의 콘텐츠를 수집할 수 없을 수도 있다.
hash 방식의 가장 큰 단점은 SEO 이슈이다.
이를 보완한 방법이 HTML5의 History API인 pushState와 popstate 이벤트를 사용한
pjax(pushState + ajax) 방식이다. pushState와 popstate은 IE 10 이상에서 동작한다.
전통적 링크 방식에서 pjax 방식까지 SPA의 발전 과정을 살펴보았다.
지금까지 살펴본 4가지 방식을 History 관리, SEO 대응, 사용자 경험 등의 관점에서 정리하면 다음과 같다.
구분 History 관리 SEO 대응 사용자 경험 서버 렌더링 구현 난이도 IE 대응
전통적 링크 방식 ◯ ◯ ✗ ◯ 간단
ajax 방식 ✗ ✗ ◯ ✗ 보통 7 이상
hash 방식 ◯ ✗ ◯ ✗ 보통 8 이상
pjax 방식 ◯ ◯ ◯ △ 복잡 10 이상
모든 소프트웨어 아키텍처에는 트레이드오프(trade-off)가 존재한다.
SPA 또한 모든 애플리케이션에 적합한 은탄환(Silver bullet)은 아니다.
애플리케이션의 상황을 고려하여 적절한 방법을 선택할 필요가 있다.
