[2팀 이도원] [Chapter 1-1] 프레임워크 없이 SPA 만들기

[2dowon]

과제 체크포인트

✅ 기본 과제

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

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

과제 셀프회고

기술적 성장

React 없이 SPA를 만들어 본 적이 없다보니 이번에 새롭게 알게 된 개념이 많았습니다!

• historyApi, hashRouter를 이용해 router 직접 구현하기

코드 품질

• useRouter에서 router는 historyRouter, hashRouter로 분리했지만, ROUTE_PAGE_MAP와 routeGuard는 동일한 코드를 재사용할 수 있도록 작성해서 맘에 듭니다!
• 상태 관리하는 useUserStore 부분도 기존에 상태관리를 zustand를 사용하다보니 비슷한 방식으로 구현해봤습니다
• 다만 Class가 익숙하지 않아 일단 function으로 구현했는데, class로 구현했을 때 장점이 무엇일지 고민중이고 추후 리팩토링해보고 싶습니다

학습 효과 분석

• SPA에 대한 이해, router의 동작 원리 등에 대해 이해할 수 있었습니다!
• 이번 과제 참고 자료에 디자인 패턴 관련 내용도 많았는데, 디자인 패턴을 적용해보지 못해 아쉽습니다...!

과제 피드백

스타트업에서 일하다보니 기획도 자주 바뀌고, 빠르게 구현하는게 더 급해 'TDD는 이상적이야' 라는 생각과 '테스트 코드'의 중요성에 대해 잘 실감하지 못했습니다. 근데 이번에 과제할 때 테스트 코드가 제공되어 TDD 방식으로 작업해보기도 하고, 리팩토링할 때도 테스트 코드를 돌리면서 작업하니 훨씬 생산성이 증가함을 느낄 수 있었습니다!

리뷰 받고 싶은 내용

평소 디자인 패턴에 대해 약하다 생각하고 잘 적용해본 적이 없다보니 이번 과제에 디자인 패턴을 적용해보지 못한 점이 제일 아쉬웠습니다.
다른 분들 코드도 보다보니 상태 관리(제 코드 기준 useUserStore.js)나 router(제 코드 기준 useRouter.js)에서 디자인 패턴을 적용한 경우가 많았던 것 같은데, 코치님이 생각하셨을 때 이번 과제에 적용했으면 좋았을 법한 '디자인 패턴'이 있으실까요?
추후 리팩토링해볼 때 참고해보려고 합니다!

[melroh629]

화면이 그려진 이후에 이벤트 리스너 달려고 따로 렌더 함수 안에 추가하신거죠~?

[2dowon]

넵 맞아요! 뭔가 render 함수도 페이지 별로 만드는게 아니라 하나로 합치고 싶었는데 이 부분 때문에 render 함수를 여러개 만들어서 조금 찝찝합니다...ㅎㅎ

[melroh629]

저는 클라이언트 쪽 상태 관리를 직접 사용할 일이 없어서 Zustand 같은 라이브러리는 사용법만 알고 있었는데, 도원님의 코드를 보면서 "아, 이렇게 활용하는 거구나!" 하고 배울 수 있었어요:)

[2dowon]

저는 클라이언트 쪽 상태 관리를 직접 사용할 일이 없어서 Zustand 같은 라이브러리는 사용법만 알고 있었는데, 도원님의 코드를 보면서 "아, 이렇게 활용하는 거구나!" 하고 배울 수 있었어요:)

앗 근데 지금와서 다시 코드 보다보니 zustand라는 구조는 비슷해보이기도 하는데, 결국은 클로저를 이용해서 상태관리를 했다고 보는게 더 정확할 것 같아요!! 저도 zustand의 내부 구현을 정확히 아는 것은 아니다보니 혹시라도 오해하실까봐 급하게 덧붙여봅니다..!!