해시(#)이전까지의 url을 브라우저에서는 호스팅서버에서 데이터 또는 문서를 GET 받아오는 것으로 인식
그래서 왜 Hashed Url Path가 SPA에 적용되야 하는지?
- Hashed url path vs. Non-hashed url path
https://example.com/abc/#def 해시(#)이전까지의 url을 브라우저에서는 호스팅서버에서 데이터 또는 문서를 GET 받아오는 것으로 인식 그래서 왜 Hashed Url Path가 SPA에 적용되야 하는지?
- url에 해시(#)가 붙는 이유 (Hash Routing 사용 이유)
- 브라우저는 url에 #가 있으면 #포함 그 이후부터 페이지로 받아들이지 않는다.
- “http://example.com/#about”로 첫 랜딩 또는 새로고침이 되어도 브라우저는 역시 index.html 이라는 하나의 파일만을 로드한다.
- “http://exmaple.com/about”로 첫 랜딩 또는 새로고침이 되면 브라우저는 호스팅서버에 “/about”에 해당하는 별도의 페이지를 요청할 것이다. (404 Not Found)
SPA를 구현할 것이므로, 호스팅서버는 오직 index.html 라는 하나의 파일만을 로드한다.
브라우저가 html, css, js 순서로 다운로드를 마치면 js/router.js 파일 내부의 로직이 시작된다.
브라우저가 index.html 파일을 완전히 다운 및 분석을 끝내면 handleLocation 함수가 실행된다.
브라우저가 index.html 파일을 완전히 다운 및 분석을 끝내면 handleLocation 함수가 실행된다.
Nav Bar나 Button 클릭을 통해서 다른 화면으로 이동할 때 마다 “hashchange 이벤트리스너”에 감지되어 다시 한번 handeLocation함수가 실행되어 #main-page의 자식 html의 내용이 변경된다.
1. 자연스러운 사용자 경험
a. 깜빡임 현상 X
b. 네이티브 앱에 가까운 자연스러운 페이지 이동(웹앱)2. 웹 성능 향상
a. 필요한 리소스만 부분적으로 로딩
b. 서버 템플릿 연산 클라이언트로 분산3. 생산성 향상
a. 컴포넌트별 개발 용이(협업 업부 분담, 유지보수)
1. 첫 랜딩 속도가 느림(한번에 모든 파일 다운 -> Code Splitting 고려 필요)
2. 검색엔진최적화(SEO)에 취약함
3. 보안 이슈
a. 핵심 비즈니스로 로직 최소화 필요(노출 위험)