[6팀 김혜연] Chapter 1-1. 프레임워크 없이 SPA 만들기

[Anne-Hyeyeon]

기본과제

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) 이벤트 위임

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

과제 셀프회고

기술적 성장

1. History API와 Hash 기반 라우팅의 차이점을 실제 구현하며 이해

• History API는 실제 URL을 변경하고 브라우저 히스토리를 조작
• Hash 방식은 URL의 # 이후 부분만 변경하여 서버 요청 없이 라우팅

2. 프로젝트 구조화에 대한 고민

• 작은 프로젝트는 어떻게 설계해야 할까? components, lib, pages 등 기능별 폴더 구조 설계

3. 이벤트 처리에 대한 이해

• 이벤트 위임 방식, 이벤트 처리 방식의 차이점 이해
• 이벤트 위임 방식의 장점 이해

코드 품질

1. 긍정적인 부분

• userStore를 통한 일관된 상태 관리 구현
• Layout 컴포넌트를 통한 일관된 UI 구조 유지
• 컴포넌트별 명확한 책임 분리 (Header, Navbar, Footer)

2. 개선 필요 부분

• 아키텍처, 구조에 대한 기준이 명확하지 않음
• 에러 처리와 사용자 피드백 메커니즘 강화
• 페이지별 레이아웃 차별화 방안 고려

학습 효과 분석

• SPA 구현의 핵심 개념 이해
• 기본 자바스크립트 문법에 대한 이해

과제 피드백

1. 좋았던 점:

• SPA 동작 원리와 이벤트 리스너, 라우터를 바닐라 자바스크립트로 직접 구현하며 깨우칠 수 있었음.

2. 개선 희망사항:

• 테스트 관련 자주 일어나는 오류, 주의사항에 대해 ㄷ공지해 주시면 좋을 듯합니다.

리뷰 받고 싶은 내용

1. Layout 컴포넌트와 페이지 컴포넌트 간의 구조 개선

• 현재 구현에서 Layout이 모든 페이지의 wrapper 역할을 하고 있는데, 로그인 페이지와 404 페이지는 다른 레이아웃이 필요합니다. 이런 경우 Layout 컴포넌트를 어떻게 구성하는 것이 좋을까요? Layout 컴포넌트를 만들어 헤더와 푸터, 네비바가 필요한 컴포넌트에 감쌌는데 이런 시도가 맞는 건지 궁금합니다.

2. router.js 코드의 관심사 분리

• 현재 router.js에서 라우팅, 렌더링, 가드 로직이 모두 한 파일에 있는데, 이것들을 어떻게 분리하면 좋을까요?
• renderPage 함수가 페이지 렌더링과 라우트 가드를 모두 처리하고 있는데, 이 책임을 어떻게 나누는 것이 좋을까요?
• History API와 Hash 기반 라우팅 로직이 한 파일에 있는데, 이를 더 깔끔하게 분리할 수 있는 방법이 있을까요?

3. DOMContentLoaded
   돔 컨텐츠가 로드되면 함수를 실행하게 하도록 DOMContentLoaded를 이벤트 리스너에 추가했는데, 그렇게 하면 테스트 코드를 통과하지 못합니다. 테스트가 이벤트를 기다리지 않고 실행되기 때문으로 추측합니다. DOM 로드를 보장하면서 테스트 코드를 통과하는 방법이 있을까요?

[CodyMan0]

혜연님 안녕하세요 14팀 이주영이에요.
혹시 matches("data-link")라고 하신 이유가 따로 있을까요? 그냥 처음 보는 형태라 궁금해서 여쭤봐요

[Anne-Hyeyeon]

@CodyMan0
주영님 안녕하세요! 코드 관련 질문 주셔서 감사합니다.

1. HTML5 커스텀 속성
   HTML5에서는 data-* 접두사를 사용하여 커스텀 속성(Custom Data Attribute)을 만들 수 있습니다.
   저는 data-* 뒤에 link를 붙여 SPA 라우팅 처리를 위한 일종의 마커를 만들었습니다.

2. data-link 속성을 가진 링크는 SPA 라우팅으로 처리
   모든 링크에 이벤트 리스너를 다는 대신, SPA 라우팅으로 처리해야 하는 링크에만 적용하기 위해 data-link 마커를 이용했습니다.
   파일 다운로드나 외부 링크 이동 등의 동작이 필요할 경우 a 태그는 SPA 라우팅의 적용을 받으면 안 되기 때문입니다.

물론 저희 프로젝트는 모든 a 태그에 SPA 라우팅을 적용해야 합니다. 따라서 어떻게 보면 불필요한 기능이라고도 할 수 있지만,
프로젝트를 진행하며 알아낸 지식을 사용해 보고 싶어 일부러 적용해 본 것입니다 ㅎㅎ

결론 : SPA 라우팅이 적용되어야 하는 a 태그와 브라우저 기본 동작이 실행되어야 하는 a 태그를 구분하기 위해 마커 추가.

[CodyMan0]

크으~~ 노하우 감사합니다! 이해했습니다 감사합니다 :)