[항해 플러스 프론트엔드 5기] 1주차 회고

1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)

대표적으로 3가지로 분리할 수 있을 거 같다.

 

- 라우터 + 렌더 구현

직접 라우터를 구현하는 것이 예상보다 훨씬 어려웠다. 평소 프레임워크가 알아서 처리해주는 부분에 대해 새삼 감사함을 느꼈다...(따봉 Vue야 고마워!) 단순히 history.pushState()만 사용하면 될 줄 알았으나, 실제로는 화면 전환 로직을 따로 조정해야 했고... 렌더링 시점을 원하는 대로 컨트롤하기 어려웠고, 이 부분에서 큰 어려움을 겪었다.

- 배포

GitHub Pages는 프론트엔드 개발자가 쉽게 접할 수 있는 배포 서비스이자, 웹사이트를 무료로 호스팅하기도 쉬운 편이라 가볍게 생각했는데, 라우팅이 제대로 되지 않아 404 페이지에 막혀 고생길을 건넜다.

- 리팩토링

컴포넌트 단위로 분리하고 로직적인 부분을 나누면 되겠다 싶었는데 렌더 코드를 정리하는 게 너무 어려웠다. (이 부분은 아직까지 숙제라고 할 수 있지.)

2. 시도

1. Hash API 학습

• 개념이 생소해서 공식 문서와 관련 자료를 찾아보며 공부함.

2. GitHub Pages 404 오류 해결 시도

• 새로고침 시 404 페이지가 뜨는 문제를 해결하려고 다양한 방법을 시도함.
  • 404.html을 활용한 리다이렉트 방식 적용
  • 각 라우터 앞에 BASE_URL을 추가하는 방식 시도

3. 렌더 관련 코드 리팩토링

• eventHandler 파일들을 분리해 렌더와의 의존성을 줄이려고 했음.
• 하지만 렌더 함수 호출이 필요한 몇몇 함수에서 문제가 발생해 일부 코드를 다시 원래대로 되돌려놓음.

 

3. 해결

• 자료를 찾아서 완벽하게 이해하는 것보다, 직접 구현해보는 게 더 빠르다고 느낌.
• History API와 비교하면서 동작 방식을 테스트하고 차이를 경험해 봄.

// History API 방식
history.pushState(null, null, href);
render(); // 페이지를 새로 렌더링

// Hash API 방식
location.hash = href;
render(); // 페이지를 새로 렌더링

• 구글링과 함께 항해 디스코드 서버, 팀원들의 도움을 받음.
• GitHub Pages에 배포할 때 아래와 같이 설정해 경로 문제를 해결하려고 했음.
• 하지만 History API 기반 라우팅에서는 새로고침 시 서버가 해당 경로를 찾지 못해 404 오류가 발생.
• 흰 화면 뜨는 것으 막았다. (사실 완벽하게 구현했던 건 아닌 거 같다.)

base:  "/front_5th_chapter1-1/"

 

• 공통으로 사용할 수 있는 페이지와 컴포넌트는 분리했음.
• 하지만 main과 main.hash.js 파일 내 render 관련 코드에는 거의 손을 대지 못했음.

프로젝트/
├── src/
│   ├── components/
│   │   ├── Header.js
│   │   ├── Footer.js
|   |   ├── PostInput.js
│   ├── pages/
│   │   ├── ErrorPage.js
│   │   ├── MainPage.js
│   │   ├── LoginPage.js
│   │   ├── ProfilePage.js
│   ├── state/
│   │   ├── state.js
│   ├── main.js
│   ├── main.hash.js
│   ├── eventHandler.js
├── package.json
├── vite.config.js

 

4. 알게된 것

- GitHub Pages 배포를 단순하게 생각했지만, 404 오류 문제를 해결하는 여러 가지 방법이 있음을 알게 됨.

- Vanilla Javascript 문법 중에 많이 부족한 부분들을 알게 되었음. 코드를 자유자재로 구현하려면 1주차에 좋은 글들을 추천 받았는데 열심히 읽어야겠다고 생각함.

- 코드 구조를 개선할 방법을 고민하던 중, Observer 패턴을 적용하면 리팩토링할 수 있다는 걸 알게 됨. 많은 분들이 그렇게 해놨더라...

- Hash API / History API 개념을 이해했다. 뭔지는 알겠어! 근데 잘 써먹을 수 있을까?

 

---

Keep : 현재 만족하고 계속 유지할 부분

오랜만에 퇴근하고 엉덩이를 붙이고 공부에 몰입하는 나를 볼 수 있었다.

 

공부하는 습관을 계속 들이는 게 좋을 거 같다. 어느 정도의 시간을 쏟는가가 중요한 게 아니라 1시간 아니 30분이라도 집중하는 습관을 들이는 게 좋다. 내가 원해서 스스로 공부를 하는 게 오랜만이라 공부가 재밌었다.

Problem : 개선이 필요하다고 생각하는 문제점

시간관리. 객관적으로 나를 바라볼 필요가 있다. 수면시간이 부족했던 나.

 

토요일에 첫 과제를 받았을 땐, 소화 못할 분량은 아닌데? 라고 생각을 해서 월요일까지 잠을 줄여가며 기본과제 구현 + 심화과제 대부분을 처리해놓고 심화과제(해시 처리)나 배포 부분을 뒤로 미루고 리팩토링을 시도했다. 

수요일에 몸이 아파 링겔을 맞았고,,, 그 날은 지옥의 야근날이었다. (새벽 3시 퇴근)

중간에 맞이해버린 거대한 야근의 무덤에 빠져버려서 계획이 다 무너졌다. 

목요일에 허겁지겁 리팩토링 + 배포를 끝마치고 PR을 작성했다. (원하는 만큼 리팩토링을 하지 못한 나.) 😓

Try : 문제점을 해결하기 위해 시도해야 할 것

시간분배를 잘하고 체력을 조절하자!

 

과제 내는 거 물론 중요하다. 하지만 내 건강이 더 중요하다. 최소 1시 이전엔 해결하고 잠을 자야겠다. 그래야 다음날에 더 나은 컨디션으로 일과 공부를 잡을 수 있으니깐. 그리고 시간 관리!

야근을 고려해서 할 수 있는 부분은 최대한 털어내는 게 좋을 거 같다. 1주차 과제에서 얻었던 초석들을 기반으로 하여 내가 빨리 할 수 있는 부분과 빨리 하지 못하는 부분들을 구분하여 파악하여 구현하는 것이 중요할 거 같다.

대충 다음주 일정에 눈물 흘리는 나...