바닐라 JS로 SPA 만들기

• 바닐라 js로 spa router를 만들던 중 서버를 구축하는 걸 봤다.

• 왜 서버를 구축하지? koa에 router를 쓰던데 이것때문인가 했다.

• 하지만 알고보니 html, js 파일을 띄우려면 서버란 건 반드시 필요한 존재였다.

• 브라우저의 요청은 무조건 서버로 들어온다.

• 사용자가 주소창을 클릭하고 엔터치거나 새로고침 하는경우 브라우저는 그 url을 바탕으로 서버요청을 날리는 것이다.

• 그 경로로 오는 요청은 서버에서 index.html을 다시 던져주고 그 url을 받아서 js가 다시 라우팅을 하는 방식이다.

• live server와 node server의 차이
• HTML preview를 보고 싶은거라면 차이가 없다.
• 하지만 production으로 사용할 수 없듯이 node 패키지를 설치하면 더 많은 기능을 사용할 수 있다.
• url 공유
• 동기화
• 번들링 도구를 브라우저 친화적으로 분석

• 서버는 html로 화면을 표시하는데 부족함이 없는 완전한 리소스를 클라이언트에 응답한다.

• 브라우저는 서버가 응답한 html을 응답받아 렌더링한다(서버 사이드 렌더링SSR).

• 이때 응답받은 html로 전체 페이지를 다시 렌더링하게 되므로 새로고침이 발생한다.

라우팅 만들기

const { pathname } = location
if(pathname === '/') {
	//home page render
}
else if (pathname.indexOf('/products/') === 0) {
	const [, , productId] = pathname.split('/')
}
else if (pathname === '/cart') {
	//cart page render
}

• 이동할 페이지 URL을 histroy.pushState를 통해 변경한다.
• 커스텀 이벤트를 사용해 router를 제작한다.

• App.js의 this.route 함수를 실행시킨다.

const ROUTE_CHANGE_EVENT = 'ROUTE_CHANGE';
const { addEventListener, dispatchEvent } = window;

export const init = (onRouteChange) => {
  addEventListener(ROUTE_CHANGE_EVENT, () => {
    onRouteChange();
  });
};

export const routeChange = (url) => {
  history.pushState(null, null, url);
  dispatchEvent(new CustomEvent(ROUTE_CHANGE_EVENT));
};

• routeChange 가 발생하면 pushState로 url을 이동시킨 후 custom event를 발생시킨다.

• init 함수는 ROUTE_CHANGE 이벤트 발생 시 this.route 함수를 호출한다.

import { routeChange } from '../router.js';

export default function nav({ $target }) {
  const $page = document.createElement('div');
  $page.className = 'nav';
  $page.innerHTML = `
    <button id='/'>home</button>
    <button id='/album'>album</button>
    <button id='/search'>search</button>
  `;

  this.render = () => {
    $target.appendChild($page);
  };

  $page.addEventListener('click', (e) => {
    const { id } = e.target;
    if (id) {
      routeChange(id);
    }
  });
}

window.addEventListener('popstate', this.route)

• initialState를 사용하는 이유 특정 컴포넌트에서 initialState를 사용하는 이유는, `해당 컴포넌트의 동작에 필요한 데이터가 다른 컴포넌트에서 영향을 받아 변경될 수 있을 때, 그 변경사항을 추적할 수 있도록 하기 위함`이라고 생각합니다.예전에 지은 멘토님께서는 컴포넌트가 다루는 데이터의 범위를 생각해보면 그 데이터의 관리에 책임이 있는 컴포넌트의 위치를 알 수 있다고 말씀하셨습니다. 이 말씀을 좀 더 생각해 보니, 저는 컴포넌트를 만들 때 컴포넌트에서 다루는 데이터가 순수하게 컴포넌트 내부에서만 생성되고 유지되는 것이 아니라, 다른 컴포넌트들에 의해 조작될 수 있는 데이터라면 공통의 부모컴포넌트가 해당 데이터에 대한 책임이 있다고 생각이 들더라구요.그래서 만약에 내가 구현하려는 컴포넌트가 다른 컴포넌트에서도 사용되는 데이터에 영향을 준다, 또는 해당 데이터가 다른 컴포넌트에서 영향을 받을 수 있다라고 한다면 해당 데이터의 관리 책임을 지니고 있는 상위 컴포넌트에서 업데이트된 데이터를 받아야 하기 때문에 initialState를 사용하는 것 같아요.

• 내부에서만 필요한 상태를 App.js 에서 관리할 필요가 있을까요?  App.js 에서 업데이트 된 데이터를 컴포넌트에 내려주어야 하는 상황이 아니라 컴포넌트의 자체 상태만으로 충분하다면 굳이 헤더 컴포넌트의 내부 상태를 App.js에서 관리할 필요는 없다고 생각합니다.