[Javascript] Facebook History Manager 분석 (1)

요즘 SNS시대가 도래하고, 상하로 이동하는 Scroll Navigation의 형태를 지니는 사이트들이 많아지고 있습니다. Facebook/Twitter가 가장 대표적이고, me2Day, G+ 도 이와 같은 형태를 지니고 있습니다.

기존 Page Navigation에 비해서 마우스 스크롤로 간편하게 움직일 수 있는 이러한 형태는 치명적인 단점을 가지고 있는데요. 하단으로 상당히 내려간 후에, 그 페이지를 벗어난 경우 다시 돌아올 때 불편함을 가지게 될 수 있습니다.

이러한 단점을 극복하기 위해서 Facebook는 History Manager 라는 Object를 만들어 이러한 문제를 약간이나마 해결을 하였습니다. 기존에 photo 등을 클릭하면 End Page로 가던 것을 까만 배경의 Layer 형태로 바꿨었고, 이번 개편에서는 History Manager를 이용하여 Back에도 대응할 수 있도록 진행을 하였습니다. 사용자가 Url을 Copy하게 되면, 그 것이 바로 End Page로 갈 수 있게 하여 Share가 용이하게 되었다는 점에서도 상당히 좋은 선택이라고 보고 있습니다.

UX의 장단점에 대해서는 사용자들과 연구원들이 좀 더 판단 해줄 것이라 생각을 하고, 저는 기술쟁이 입장에서 History Manage에 대한 분석으로 접근하여, 이후 jQuery용 Ajax History Plugin을 제작/공개할까 합니다.(많이 써주실랑가 모르겠네요.^_^)

우선 전체 소스는 여기서 참고하시면 됩니다. (Source by jsFiddle)

첫 번째로 init에 대해서 보고 넘어갈 수 있도록 하겠습니다.

Facebook에서는 History를 위해서 pushStaus 를 이용합니다.

문서와 예제를 보시면 어떤 기능인지에 대한 이해에 도움이 될 것입니다.

현재 이 기능은 아직 널리 퍼진 기술이 아니므로 현대 Browser 외 에는 지원을 하지 않고 있습니다.

그 이전의 Browser 사용자들을 위해서 hashchange Event 와 iframe을 이용하여 history 기능을 구현 하였습니다.

pushStatus를 이용하게 되면, url이 변경 되지만 Page 가 replace되지 않으므로 간단히 List 위에 레이어를 띄울 수 있게 됩니다. 또한, 변경 된 url을 이용해 End Page link도 사용자에게 전달 할 수 있게 됩니다.

이제 지원되지 않는 Browser들을 위한 Logic을 살펴보도록 하겠습니다.

이제 IE 7 이하 의 "hashchange" 이벤트를 지원하지 않는 Browser와 지원하는 Browser 나뉘게 됩니다. (문서 참조)

일반적으로 화면이 변화 하지 않으면서도 사용자의 location 을 변경 하고 싶을 때 "#"hash를 사용하게 됩니다. 이를 이용한 방법이 제일 많이 사용되던 Ajax History 방식이였습니다.

이것이 변경 되는 것을 인지 할 수 있는 Browser들은 단순히 Event Listen을 하게 두었고, 지원하지 않는 Browser의 경우(IE 7 이하) iframe에 현재 정보를 전달 하여, onLoad Event를 사용하도록 하였습니다.

이것이 기본적인 History Manager가 동작을 하기 위한 기본 설정입니다.

다음 Post에서는 이 설정을 가지고 실제로 어떻게 진행이 되는지 살펴보도록 하겠습니다.^_^

그럼~