[5팀 박소미] [Chapter 1-1] 프레임워크 없이 SPA 만들기

[confidential-nt]

과제 체크포인트

기본과제

1) 라우팅 구현:

• History API를 사용하여 SPA 라우터 구현
  • '/' (홈 페이지)
  • '/login' (로그인 페이지)
  • '/profile' (프로필 페이지)
• 각 라우트에 해당하는 컴포넌트 렌더링 함수 작성
• 네비게이션 이벤트 처리 (링크 클릭 시 페이지 전환)
• 주소가 변경되어도 새로고침이 발생하지 않아야 한다.

2) 사용자 관리 기능:

• LocalStorage를 사용한 간단한 사용자 데이터 관리
  • 사용자 정보 저장 (이름, 간단한 소개)
  • 로그인 상태 관리 (로그인/로그아웃 토글)
• 로그인 폼 구현
  • 사용자 이름 입력 및 검증
  • 로그인 버튼 클릭 시 LocalStorage에 사용자 정보 저장
• 로그아웃 기능 구현
  • 로그아웃 버튼 클릭 시 LocalStorage에서 사용자 정보 제거

3) 프로필 페이지 구현:

• 현재 로그인한 사용자의 정보 표시
  • 사용자 이름
  • 간단한 소개
• 프로필 수정 기능
  • 사용자 소개 텍스트 수정 가능
  • 수정된 정보 LocalStorage에 저장

4) 컴포넌트 기반 구조 설계:

• 재사용 가능한 컴포넌트 작성
  • Header 컴포넌트
  • Footer 컴포넌트
• 페이지별 컴포넌트 작성
  • HomePage 컴포넌트
  • ProfilePage 컴포넌트
  • NotFoundPage 컴포넌트

5) 상태 관리 초기 구현:

• 간단한 상태 관리 시스템 설계
  • 전역 상태 객체 생성 (예: 현재 로그인한 사용자 정보)
• 상태 변경 함수 구현
  • 상태 업데이트 시 관련 컴포넌트 리렌더링

6) 이벤트 처리 및 DOM 조작:

• 사용자 입력 처리 (로그인 폼, 프로필 수정 등)
• 동적 컨텐츠 렌더링 (사용자 정보 표시, 페이지 전환 등)

7) 라우팅 예외 처리:

• 잘못된 라우트 접근 시 404 페이지 표시

심화과제

1) 해시 라우터 구현

• location.hash를 이용하여 SPA 라우터 구현
  • '/#/' (홈 페이지)
  • '/#/login' (로그인 페이지)
  • '/#/profile' (프로필 페이지)

2) 라우트 가드 구현

• 로그인 상태에 따른 접근 제어
• 비로그인 사용자의 특정 페이지 접근 시 로그인 페이지로 리다이렉션

3) 이벤트 위임

• 이벤트 위임 방식으로 이벤트를 관리하고 있다.

과제 셀프회고

기술적 성장

• hash router의 개념 및 사용 이유에 대해 학습
• 앞으로 가기, 뒤로 가기의 구현을 위해서는 'popstate'와 History API의 push를 사용하면 된다는 것을 학습
• 이벤트 위임 방법에 대해 다시금 상기

코드 품질

• html에 id를 설정할 때 하드코딩된 값을 사용함으로써 발생하는 힘듦을 피하고자 이들을 상수로 설정하여 사용한 부분은 만족.
• main.js와 profile.js에 반복되는 코드가 있으며, innerHTML에 직접적으로 스트링 형태의 ui를 집어넣고 있다. 이 경우, 좀 더 ui를 구성하고 나중에 돔에 반영하고 싶은 경우에 대한 처리를 하지 못한다.

  export default function renderMain() {
  const root = document.querySelector("#root");
  const targetElement = root ? root : document.body;

  targetElement.innerHTML = `
  ${MainPage()}
`;

// 이와 같은 코드가 profile에서도 반복된다.
  document.body
    .querySelector(`#${GLOBAL_NAVIGATION_ID}`)
    .addEventListener("click", (e) => {
      if (e.target.tagName === "A") {
        e.preventDefault();

        if (e.target.id === LOGOUT_BTN_ID) {
          localStorage.removeItem(USER_INFO_LOCALSTORAGE_KEY);
          browserRouter("/login");
          return;
        }

        browserRouter(e.target.pathname);
      }
    });
}

• 반복되는 부분은 따로 함수로 빼든지 해야할 것 같다.
• 두번째 문제에 관해서는, template 요소나 cloneNode의 동작 방식에 대해 이해를 해봐야할 것 같다.
• 이러한 반복을 줄이고 안정성을 높이는 방안을 통해, 코드를 조금 더 깔끔하게 개선해볼 수 있지 않을까 생각한다.
• 함수로 코드를 구현하고 있기 때문에 함수형을 잘 활용해보고싶다.
• 더 괜찮은 방법이 있는지 궁금하다.
• 코드 구조를 보강할 때 리액트 라우터를 참고하면 좀 더 도움이 될까…

학습 효과 분석

• hashRouter를 사용할 때 일관적으로 작동하지 않는데 이에 대한 해결법을 학습해야할 것 같다. 처음 index 페이지를 띄웠을 때는 해시로 동작하는데, 글로벌 네비게이션으로 페이지를 이동할 경우, 해당 네비게이션의 링크는 해시가 아닌 일반 pathname으로 걸려있기 때문이다. 현재 떠오르는 것은 hash 값이 있는지 먼저 판별하고 그에 따라 링크를 다르게 걸어주는 방법이 떠오른다. 또한 라우팅을 시킬 때도 이러한 경로 설정에 유의를 해줘야할 것 같다. 더 괜찮은 방법이 있는지 궁금하다.
• 아직 history api, popstate, hashchange 이벤트 이들이 엮여서 어떻게 정확히 작동하는지 파악하지 못한 상태. 아무튼 구현하긴 했는데 ‘어, 이게 왜 되지?’ 라는 의문을 가지고 있는 상태. 추가적인 학습이 필요하다.

과제 피드백

리뷰 받고 싶은 내용

• main.js에서 저렇게 전역으로 이벤트 핸들러를 설정하는 것이 안전할까요? 더 나은 방법이 없을지 궁금합니다.
• 일단 돌아가는 걸 만들기 위해 어떻게됐든 구현을 하긴 했는데, 해시 라우터를 만드는 과정에서 제 코드가 확장성이 좋지 않다는 것을 알게 되었습니다. 사용자가 해시라우터를 쓸거냐, 브라우저 라우터를 쓸거냐를 선언적으로 정의하게 한다음, 그에 따라 알맞는 ui를 설정하여 불러오게 하고 싶은데 지금은 이 일련의 과정들이 끊겨있다는 느낌을 받습니다. '학습 효과 분석'의 첫번째 줄에 이러한 제 고민이 잘 드러나 있는데, 저렇게해서 네비게이션 링크를 조정해서, 즉, ui 단에서 문제를 해결하면 될지, 아니면 조금 더 큰 관점으로 바라봐서 문제를 해결할 수 있을지 고민이 됩니다.
• 클래스 대신 함수를 통해 코드를 작성하고 있습니다. 일종의 함수형 도전인데요, 관련된 원칙들을 위반한 코드나 개선해보면 좋을 부분들을 제안해주실 수 있을까요?
• 단일 책임 원칙을 어기고 있거나 나중에 매우 확장이 힘들어보이는 코드에 대한 피드백을 받을 수 있을까요?