[14팀 박휘정] Chapter 1-1. 프레임워크 없이 SPA 만들기

[gnlwjd231]

과제 체크포인트

기본과제

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

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

과제 셀프회고

기술적 성장

• MPA 방식으로 일해와서 그동안 페이지 별로 디렉토리를 짜왔다. 그래서 그런지 �리엑트의 프로젝트 구조가 낯설었는데, 컴포넌트와 라우터를 만들고 각자 역할에 맞게 코드를 쪼게다 보니 ( 비록 성공적으로 나누지는 못했지만.. ) 리엑트 프로젝트의 폴더 구조가 어떤 근거로 나누어져있는지 깨닫게 되는 시간이였다.

• observer를 처음으로 사용해봤다. ( 테스트 코드 통과를 자꾸 실패해서 PR 코드에는 없음 ) 그동안 값을 변경하고 이후에 이벤트를 등록하기 위해 비동기 통신을 쓰기도 하고 함수에 함수를 체인처럼 이어서 얼마나 많은 삽질을 했던가.. observer를 사용하니 값이 변하면 리렌더링 시키는 코드를 작성할 수 있었다. 리엑트의 useState를 질투하기만 했던 지난 날을 반성하며, 회사에서도 observer를 사용해보았다. 대박이다. 기본기를 좀 더 다져야겠다는 결심이 선다. javaScript는 내 생각보다 훨씬 파워풀했다.

코드 품질

공개하고 싶지 않을 정도의 코드 품질이라고 생각한다. 테스트 코드가 통과하는지 확인하면서 리팩토링을 하는 것이 굉장히 간편하게 느껴지기도 했지만, 막판엔 모든 걸 포기하고 돌아가기는 했던 코드로 되돌린 다음 PR을 날렸다.(근데도 테스트 코드 통과를 못했..) [작동하지 않는 이쁜 코드 === 이쁜 쓰레기] 라는 학습메이트의 말이 위로가 되었다. 이미 과제는 제출했고 기한은 지났지만, 여유가 있는 금요일 다시 한번 내 코드를 천천히 보고 고쳐봐야겠다.

학습 효과 분석

내가 이해한 MPA 방식의 프로젝트에서 사용하는 디렉토리 구조

내가 이해한 SPA 방식의 프로젝트에서 흔히 사용하는 디렉토리 구조

MPA 방식에서는 html 파일 ( 페이지별 ) 로 나눠서 디렉토리 구조를 짜는 반면, SPA 방식에서는 관심사 별로 디렉토리 구조가 나뉘어있다는 것을 알았다. 공통적으로 사용하는 함수를 어떤 방식으로 사용하느냐의 문제 같은데, SPA 방식이 재사용성이 높아 보인다.

현재 회사에서는 정적 리소스를 관리하는 폴더가 따로 있는데, 이 폴더의 구조를 SPA 디렉토리 구조에 영감을 받아서 리팩토링 해보고 싶다는 생각이 들었다. 프로젝트를 리엑트로 점진적 마이그레이션을 하고자 하는 마음도 있었는데 스택을 바꾸지 않더라도, CSR과 SSR이 적절하게 융합된 형태의 서비스를 만들 수 있을 것 같다는 �생각이 든다.

끝으로, 주말시간을 좀 더 투자했어야한다는 생각이 들었다. 주중에는 야근이니 회식이니하는 변수가 많았다. 다음 발제부터는 일요일을 최대한 투자해서 과제 통과에 급급한 상황을 만들지 말아야겠다.

과제 피드백

테스트 코드 내용과 제공 받은 코드 내용이 상이한 것이 있어, 테스트 통과가 되지않아 조금 햇갈렸습니다만, 덕분에 팀원들과 테스트 코드를 뜯어보는 좋은 계기가 되었습니다.

리뷰 받고 싶은 내용

1. 페이지 전환 후에도 initEventLoginPage()나 initEventProfilePage()에서 등록한 이벤트 리스너들이 남아있을 수 있는데, 이벤트 정리나 메모리 누수를 방지하기 위한 패턴이나 기법이 있을까요?
2. 현재 라우트 가드에서 requireLogin과 requireLogout 조건을 직접 하드코딩한 뒤, isLogin 상태와 문자열 비교를 통해 접근을 제어하고 있습니다. 이후 인증 조건이 늘어나거나 구조가 복잡해질 경우를 대비해, 이런 조건 처리를 좀 더 확장 가능하고 유연하게 관리할 수 있는 방법이 있을까요?
3. [학습 효과 분석]에도 작성한 내용입니다만, 이번 과제를 통해 기술스택을 꼭 바꾸지 않더라도 모던 웹 작동 방식을 표방할 수 있다는 생각이 들었습니다. 모던 웹 패턴을 프로젝트에 도입할 때, 기존 환경에 SPA나 라우팅 등의 기능을 하나씩 추가해나가는 방식과, 코드를 점진적으로 React로 마이그레이션하는 방식 중 어떤 접근법이 실용성과 유지보수성 면에서 더 유리하다고 생각하시나요 ?

[gihwan-dev]

고생하셨습니다 휘정님!! 새벽까지 고생 하셨어요:) 다음번 과제는 심화 패스를 목표로 가보시죠!