History Type - Browser, Hash

히스토리 타입

• 브라우저 히스토리
• 해시 히스토리
• 메모리 히스토리

브라우저 히스토리와 해시 히스토리는 둘 다 브라우저 환경에서 사용된다. 브라우저 히스토리와 해시 히스토리는 현재 location이 브라우저의 주소창에 띄워져있는 것과 일치하도록 한다.

const browserHistory = createBrowserHistory()
const hashHistory = createHashHistory()

이 두 개의 가장 큰 차이는 url의 어떤 부분으로부터 로케이션 객체를 생성하느냐이다.

브라우저 히스토리는 전체 url을 사용하는 반면, 해시 히스토리는 url에서 첫번째 해시 심볼 이후에 나타난 부분만 사용한다.

url = 'http://www.example./com/path/name?key=value#hash'

// 브라우저 히스토리가 만드는 location 객체
{
  pathname: '/path/name',
  search: '?key=value',
  hash: '#hash'
}

// 해시 히스토리가 만드는 location 객체
{
  pathname: 'hash',
  search: '',
  hash: ''
}

(단 브라우저 히스토리는 basename을 주어서 ignore할 path를 정할 수 있다. createBrowserHistory({basename: '/path'}) 이렇게 브라우저 히스토리를 만들면 location 객체에서 basename부분은 무시되고, pathname 필드의 값은 '/name' 이 된다.)

그러면 자연스럽게 이런 질문이 나온다. 그럼 해시 히스토리는 언제 왜 쓸까...🙉?

해시 히스토리가 필요한 순간 - static file server를 사용할 때

만약 Single Page Application을 만들고 있고 앱을 호스팅하는데 스태틱 파일 서버를 사용하고 있다면, 문제가 생기는 부분이 있다.

스태틱 파일 서버는 다이나믹 리퀘스트에 반응하지 못하는 서버다. 예시로 깃허브 페이지나 아마존 S3가 있다. 요청 url이 들어오면 정확히 그 위치에 원하는 파일이 디스크에 있어야 한다. 만약 없다면 404를 리턴한다.

하지만 SPA의 경우 실제로는 index.html 파일이 하나일 수도 있고, url이 주소창에서 바뀌는 것은 그 주소로 서버에 실제 요청을 하는 것이 아니라 단지 index.html에서 렌더링할 부분을 바꿔서 보여주는 것뿐이다.

예를 들어 base url이 http://www.example.com인데 http://www.example.com/go.html 로 서버에 요청을 한다면 (주소창에서 이 주소를 바로 쳤을 때) 실제로 이 위치에 go.html이라는 파일은 없으므로 404가 리턴될 것이다. (다만 많은 스태틱 파일 호스트들이 fallback 페이지를 설정할 수 있도록 하므로, 이런 경우 404 에러가 콘솔에는 찍히지만 유저 눈에 보일 일은 없을 수 있다.)

html 파일이 하나인 SPA에서는 실제 url은 단 하나다. (애초에 url은 리소스의 위치를 가리키는 것인데 리소스가 딱 한군데밖에 없는 것이니까) 하지만 유저가 navigate하려면 주소창에 보여지는 여러 개의 url은 필요하다. 이 때 hash history를 사용하면 이 문제를 해결할 수 있다.

서버는 hash 심볼 이후의 url, 즉 프래그먼트는 무시한다. 일반적으로 HTTP 서버는 객체의 일부가 아닌 전체만 다루기 때문에 프래그먼트 필드는 서버에 전달되지 않으며 클라이언트에서만 사용된다. (참고 - URL의 기초)

/*
http://www.example.com/#/hash
위 url은 해시 이후는 무시하고 /index.html을 서버로 요청한다. 그러나 해시 히스토리를 쓸 때 location 객체는 해시 섹션을 사용해서 만들어지므로 { pathname: '/history' } 가 된다.
*/

이렇게 하면 루트의 index.html만 서버로 요청을 보내게 되므로 404가 뜰 일은 없다. 다만 문제는 못생긴 url이다.

못생긴 url이 싫다면 모든 페이지마다 html 파일을 생성해두는 방법이 있다. SPA를 위한 패키지 중 스태틱 페이지를 만들어 주는 것들이 있다.

회사에서의 유스케이스는, 아마존 S3를 사용해서 SPA를 호스팅하고 있는데 유저가 루트 페이지가 아닌 /promotion 이라는 페이지로 랜딩하면 서버 응답은 404지만 fallback page가 설정되어 있어 유저가 화면 상 보는 데에는 문제가 없었는데, 구글 광고를 집행하면서 문제가 생긴 것이었다. 광고의 랜딩 링크를 루트 페이지가 아닌 /promotion 페이지로 설정해두었는데, 404 응답이 온다는 이유로 구글 광고가 계속 리젝되었다. 이는 s3 설정에 해시를 포함한 url로 리다이렉트하게 하면서 해결되었다.

(메모리 히스토리 관련 내용은 나중에 추가하기로...👀)

Ref

• https://medium.com/@pshrmn/a-little-bit-of-history-f245306f48dd
• https://blog.pshrmn.com/single-page-applications-and-the-server/