전통적인 웹사이트에서는 사용자가 웹사이트 내의 다른 페이지로 이동하면, 브라우저가 페이지를 보여주기 위해 매번 HTML 파일로 된 "페이지 전체"를 불러와야만 했다. 웹사이트가 복잡해지고 사용자와의 서비스에서 상호작용이 많아질수록 서버와의 불필요한 트래픽을 발생시켰다.
한편, 사용자 입장에서는 매번 모든 페이지를 불러옴에 따라 더 느린 반응성을 갖게 됐고, 이는 애플리케이션과 같은 사용자 경험을 제공하기 어렵게 만들었다.
1990년대 후반에 HTML 문서 전체가 아닌, 업데이트에 필요한 데이터만 서버에서 전달받아 이 데이터를 JavaScript가 동적으로 HTML 요소를 생성해서 화면에 보여주는 방식이 개발되어 사용되기 시작했다.
2000년대 중반부터 이러한 개발 방식을 이용한 웹 애플리케이션이 보편화 됐으며, 이것이 우리가 지금 배우고 있는 싱글 페이지 애플리케이션, 즉 SPA이다.
애플리케이션과 사용자 사이에 수시로 상호작용이 발생하는데, 이때 페이지 전체를 렌더링하는 것이 아니라 필요한 부분만 업데이트하기 때문에 SPA는 사용자의 행동에 빠르게 반응한다.
서버 입장에서는 요청받은 데이터만 넘겨주면 되기 때문에 과거와 같은 과부하 문제도 현저히 줄일 수 있다.
화면 전체를 새로 렌더링할 필요가 없기 때문에 보다 나은 사용자 경험을 제공한다.
브라우저는 첫 화면 로딩 시에 HTML 파일을 읽어들인 후 그 안의 script tag
안에 있는 JavaScript 파일을 다시 받아오는 과정을 거친다. 이때 첫 화면 로딩 시 읽어들인 HTML 파일은 거의 비어있고, 대부분의 코드는 JavaScript 파일안에 들어있다보니 자연스럽게 JavaScript 파일이 무거워진다. 때문에 이 JavaScript 파일을 기다리는 시간으로 인해 첫 화면의 로딩 시간이 길어진다.
검색 엔진 최적화가 좋지 않다. 검색엔진 최적화란 구글이나 네이버같은 검색엔진이 자료를 수집하기 좋도록 웹 페이지를 구성하는 것을 뜻한다.
만약 youtube를 만든다고 생각하면 화면 상단의 경우, 상단 전체를 아우르는 Header
라는 컴포넌트가 있고, 그의 자식으로 Search
와 Setting
이라는 컴포넌트를 만들기로 한다.
Header
컴포넌트는 애플리케이션 내의 어떤 페이지에 가더라도 늘 상단에 위치하니 이 부분을 감안해서 설계 로직을 작성해야겠다고 생각한다.
화면 중앙에는 크리에이터들이 올린 영상을 담고 있는 ContentList
라는 컴포넌트가 있고, 그 안에는 동일한 형태를 가진 영상물들이 반복적인 형태로 화면을 구성하고 있기 때문에 Content
라는 컴포넌트를 한 번만 만들어 재사용하기로 했다.
가장 작은 단위의 컴포넌트를 한번 분석해 보기로 했다. 그 중 한눈에도 다양한 정보를 담고있는 Content
컴포넌트를 한번 살펴봤다. Content
컴포넌트는 상단에는 썸네일, 중앙에는 아바타와 영상 소개글, 하단에는 채널 이름과 조회수, 업로드 한 날짜가 기재돼 있다. 이처럼 많은 정보들을 가지고 있기 때문에 컴포넌트들끼리 보다 유기적으로 주고 받을 수 있도록 설계해야한다.