Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[9팀 김동한] Chapter 1-1. 프레임워크 없이 SPA 만들기 #65

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

LESANF
Copy link

@LESANF LESANF commented Dec 19, 2024

과제 체크포인트

기본과제

1) 라우팅 구현:

  • [�x] 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) 이벤트 위임

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

과제 셀프회고

프레임워크 없이 SPA만들기는 많은 포스팅글을 보면서 도전해봐야지 생각한 주제 중 하나였습니다.

항해를 통하여 이번 과제를 할 수 있어서 좋은 경험을 한 것 같아요

개인적으로 반성을 많이하는 과제였던것같습니다

제가 알던 패턴, 모듈화 등이 많이 부족한 것을 알게된 과제였던 것 같습니다

기술적 성장

사실 기술적으로 성장을 했는지는 잘 와닿지 않는것 같아요

하지만 1주차 과제를 진행하면서 퇴근 후 새벽까지 공부하는 원동력을 많이 얻었어요

코드 품질

이번 과제를 진행하면서 정말 좋은 결과물을 내보려고 노력했어요

하지만 하루이틀만에 성장할 수 없는건 누구보다 잘알고있었기에 결과물이 만족스럽지 않습니다

목요일 밤을 새면서 만들어놨던 구조들이 너무많았고 개발을 진행할 수 록 테스트 기준에서 멀어갔습니다

그러기에 라우터 모듈을 분리하기전인 history API 가 완성했던 시점(basic, e2e 통과)으로 강제 리셋을하여

과제 통과를 위한 코드로 마무리를 했어요

로컬 스토리지의 키값과 중복되는 단어를 constants 폴더아래 Barrel 패턴을 사용해가며 되게 많이 만들었는데

하면서도 조금 애매했어요 개발이 진행될 수록 어떤식으로 구조를 잡으며 안정화를 시킬 수 있을까요 ?

학습 효과 분석

개념적으로 잘안다고 생각했었지만 실제로 구현이 잘안된다는건 개념도 많이 부족하다 생각해요

문서와 GPT를 통하여 개념을 계속 복기해도 내가 확실하게 정복한 느낌을 받기 힘들었어요

글로 읽는것보다 계속해서 이번과제를 만들어보는게 제일 현명한 방법일까요 ?

클래스 형으로도 만들어서 비교를 해봐야겠다는 생각이 들었습니다

과제 피드백

결정적으로 만들면서 꼬인 부분은 브라우저 라우터와 해쉬라우터를 만들면서

공통인 부분을 정의해두는 과정에서 실패했던것 같습니다

테스트코드를 좀더 공부해야겠다는 생각이 많이들었어요

과제 자체에 애매했던 부분은 없었던 것 같습니다.

리뷰 받고 싶은 내용

[1]
https://github.com/LESANF/front_4th_chapter1-1/blob/main/src/store/auth/index.js

이런식으로 팩토리 함수를 자주사용하는데 사실 장단점을 알고 쓴다기보단

실무에서 제가 자주쓰는거라 이번 과제에서도 적용을 해봤어요

이 외에도 혹시 무슨 패턴, 구조로 만들어봐라 하고 추천해주실게 있을까요 ?

[2]
너무 지나친 분할은 독인걸 알고 있지만 어떤식으로 묶어야할지 애매한 부분에 대한 질문입니다

예를들어 자주사용하는 값들은 상수화시켜 constatns 폴더로 관리하며 그아래에도 서비스별로 폴더를 만들어서 관리한다고 가정할때

이렇게 시작해버리면 해당 프로젝트가 끝날때까지 너무 많은 하위 구조들이 만들어지는데

적당한 분할이라는게 있는지 궁금합니다

재사용성이 하나라도 있으면 무조건 따로 빼서 관리하는게 맞을까요 ?

);

return { success: true, message: "계정 생성 성공" };
} catch (error) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

오호.... try...catch를 로컬 블록에서 잡아서 다시 던진다면 차라리 try catch문을 제거하고 에러 처리를 호출하는 측에 위임 하는것도 좋은거 같아요!

},
};

function renderPage() {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

renderPage나 guard가 조금 더 유연한 구조였으면 좋겠다는 생각이 드는거 같습니다! 지금은 path별 컴포넌트의 라우팅을 추가하거나 수정하려면 renderPage의 세부 구현을 수정해야 할 거 같아요!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants