[회고] 노션 클론 프로젝트 회고 / 2022-04-21 / 25일차
미음제
·2022. 4. 24. 23:00
금요일 TIL은 14일부터 20일까지 진행한 노션 클론 프로젝트에 대한 회고다. 블로그에 따로 작성하려 했는데, 금요일에 팀 별 회고를 진행해달라고 해 노션으로 작성했던 내용을 적는다.
들어가기에 앞서
김태희(로토) 강사님의 바닐라 자바스크립트를 통한 기본 역량 강화 강의 내용을 바탕으로 노션 클론 프로젝트를 진행하게 되었다. 프론트엔드(자바스크립트)는 처음으로 공부해보는 것이라 강의 내용을 따라가기도 벅찼고(코로나로 강의를 제대로 듣지 못한 부분도 있었다), HTML, CSS 기본 구조도 없이 처음부터 끝까지 해야 한다는 것에 막막했던 게 사실이다.
구현 내용
순수 바닐라 자바스크립트로 노션의 기능을(일부분) 구현하는 것이다. API를 통해 데이터를 관리(새로운 데이터를 서버에 저장, 기존 데이터를 수정하고 서버에 저장)하고 요청 후 받아온 데이터를 화면에 렌더링하는 간단한(?) 프로젝트였다.
프로젝트 결과 링크
시연
구조
- App.js
- ListContainer
- EditorContainer
- route
- '/' (루트) 경로
- '/documents/id' 경로
- 그 외의 잘못된 경로 -> replaceState(루트 경로)
- 각 경로에 맞게 ListContainer와 EditorContainer 렌더링
- ListContainer.js
- fetchPosts
- 모든 Documnets 'GET' 요청 후 PostList.setState()로 넘겨주기
- fetchAddPosts
- 전달 된 id(부모 id)가 있는 경우 부모 Post의 하위 Post로 새로운 Post 'POST' 요청 || 없는 경우 새로운 Root Post 생성
- fetchDeletePosts
- 해당 Post의 id를 통해 'DELTE' 요청
- replaceState(루트 경로)
- render
- fetchPosts() 호출
- PostList
- state : 'GET' 요청으로 전달된 모든 Documnets
- onClick(id)
- 클릭된 Post의 id를 통해 pushState(documents/해당 post id)
- onAdding(id)
- 클릭된 추가 버튼의 부모 id를 가져와 fetchAddPosts(id) 호출
- onDelete
- 클릭된 Post의 id를 통해 'DELETE' 요청
- fetchPosts
- EditorContainer.js
- state : postId, 초기 값 null
- 상태가 변경될 경우
- id가 없는 경우 -> 빈 editor 렌더링, documentsLists 상태 null로 변경
- id가 있는 경우 -> 해당 Post id를 통해 'GET' 요청 후 editor와 documentsLists 상태 변경
- updatePostsList()
- title이 변경 된 경우 호출되고, listContainer.render() 호출 -> content가 변경되어도 호출되고 있어 수정 필요
- Editor
- state : Post id값에 따른 title, content
- 첫 렌더링 시 에디터 HTML 작성 후 display none
- Post id를 받은 경우, 에디터 title, content 렌더링
- onEditing(post)
- input 이벤트를 통해 title과 content 변경이 있는 경우 호출
- 2초의 디바운스 후 'PUT' 요청 / updatePostsList() 호출
- DocumentsLists
- state : Post id값에 따른 id, title, content, documents -> 수정 필요
- 넘겨받은 id의 Post가 하위 Documents를 갖고 있는 경우 하위 Documents를 렌더링
- onClick(id)
- 클릭 한 하위 문서의 id를 통해 pushState(/documents/해당 post id)
어려웠던 점
1. 컴포넌트 분리
컴포넌트 개념 자체가 어렵게 느껴졌다. 그동안 해본 것이라곤 인강을 들으며 코딩 클론을 하며 자바스크립트 맛보기와 우아한테크코스 프리코스 과제를 진행했던 것이 전부였다. 처음 컴포넌트 별로 분리를 해서 프로젝트를 진행하다 보니 어렵게 느껴졌던 게 사실이다. 컴포넌트 구조를 짜는 것, 의존성을 줄이는 것 등 많은 것이 어려웠다. 처음 과제를 진행하면서도 대략적인 생각에 기반해 컴포넌트들을 설계했었는데 얼마 못가 다 엎어버리고 말았다. 과제가 끝날 때 즈음 전체적인 구조를 도식화해서 파악했는데 순서가 반대로 진행된 것 같았다. 전체적인 흐름을 미리 설계해보고 구현을 시작하는 게 좋을 것 같다는 생각을 하게 되었다.
2. SPA
SPA에 대한 강의 내용을 들을 때 몸상태가 좋지 못해 제대로 듣지 못했었다. 과제 구현사항 중 SPA로 만들어라 라는 말이 있어 시작했는데 생각보다 많이 어려웠었다. history API로 url을 변경(스택에 쌓거나 대체하거나) 한 후 App.js 에서 라우팅을 해주면 정상적으로 동작하리라 믿었다. 실제로 루트 경로로 접속한 처음엔 잘 동작했으나 새로고침 후 동작이 먹히지 않았었다. popstate 이벤트를 전역 객체에 걸어 해결했는데 올바른 해결책인지 잘 모르겠다. 새로고침과 관련해서 원하는 데이터를 불러오고 화면에 렌더링 하는 것은 성공했는데, 삭제 후 렌더링 하는 것에도 문제가 있었다. 삭제된 상태 업데이트를 안 해서 url이 변경되고, 삭제도 되었지만 화면에 남아 있는 문제가 여기저기서 나왔다. 주먹구구식으로 해결하긴 했지만 이 덕분에 코드가 많이 더려워졌다.
3. 상태 관리
컴포넌트 분리와 직접적으로 연관된 내용이다. 컴포넌트 별로 적절한 상태가 있어야 하는데, 쓸모없는 상태를 많이 추가했었다(전혀 사용되지 않은). 구조 도식화를 통해 어느 정도 해결하긴 했지만 아직도 발견 못한 부분들이 있을 것이다. 상태 관리의 어려움 때문에 다른 곳에서도 어려움이 있었다. 이벤트가 발생하면 적절한 처리를 해주어야 하는데, 하위 컴포넌트에서 상위 컴포넌트로 올라가는 게 어려웠다. 에디터에서 title을 변경한 경우 post list의 title도 수정을 해야 했는데, “에디터 → 에디터 컨테이너(App.js에 위치) → 에디터 컨테이너 updatePostList 함수 호출”의 구조로 진행했다. 불필요한 흐름이 너무 많은 것 같다. 컴포넌트 구조와 상태 관리에 익숙했다면 더 자연스럽고 깔끔한 코드를 짤 수 있지 않을까 하는 아쉬움이 있다.
느낀 점 & 아쉬운 점
우선 아쉬운 점이 많았던 프로젝트 같다. 시작하기 전에 요구사항을 보면서 “내가 할 수 있을까?”라는 생각이 먼저 들어서(제일 안 고쳐지는 안 좋은 습관..) 기간 내에 프로젝트를 마무리하자, 기본 요구사항을 최대한 구현해보자에 포커스를 두고 진행했던 것이 아쉽다. 사실 기본 기능 구현이 겉보기에는 완성이 된 것처럼 보이지만 예외 케이스도 찾지 못하고 넘어간 터라 완벽하지 않다. 그럼에도 보너스 요구 사항을 도전해 보지 못한 점(애초에 도전할 수 없는 영역이라고 생각했던)이 가장 아쉽다.
앞서 말한 것에 대한 연장선이다. 기본 기능 구현에 급급해 깔끔하게 코드를 작성하지 못했고, 주먹구구식으로 하드 코딩한 느낌이 강하게 든다. 기능 하나하나를 추가할 때마다 다시 손보는 곳이 많았을 정도로 잘 마무리하지 못한 것 같다. 개인 프로젝트를 진행한다거나, 다른 프로젝트를 진행할 때 일정 계획을 잘 수립하고 시작하기 전에 전체적인 흐름을 먼저 생각하고 도식화한 후 작성할 수 있도록 해야겠다는 생각이 든다.
개인적으로 팀을 잘 활용하지 못한 게 아쉽다. 다른 팀원분들은 막혔던 부분이 있을 때 스크럼 때 의견 공유를 많이 하셨는데 본인은 한 번도 그러지 못해 너무 아쉽다. 이 정도면 모각코에서 혼자 코딩한 게 아닌지.. 기능을 구현하면서 막혔던 부분이 생기면 해결해야겠다는 생각에 주구장창 코드만 들여다봤던 것 같다. 어찌어찌 땜빵 느낌으로 해결하고, 다음 기능 구현을 하면서 자연스럽게 어떻게 해결했었는지, 어떤 점에서 헷갈리고 이해가 안 되었는지 잊었던 것 같다. 사소한 것 하나하나 기록하는 습관을 들여 모르는 부분, 어려웠던 부분에 대한 의견 공유를 할 수 있도록 노력해야겠다.
아쉬운 점도 많았지만 “발전했다”라는 느낌도 들었다. 개발 기한이 있고, API를 활용하고, 배포까지(찍먹이긴 하지만) 한 첫 프로젝트라 뿌듯한 느낌도 있다.
학부생 때 했던 프로젝트들은 시험 성적, 졸업을 위해 급급하게 했던 것들이라 돌아보면 기억도 잘 안 난다(내가 한 것이라고 말할 수 없을 정도로). 인턴활동을 하며 진행했던 프로젝트는 내가 짠 코드라기보다 이미 있던 코드에서 살을 붙인 정도였다. 우아한 테크코스 과제를 진행할 때는 자바스크립트에 대해 무지했던 터라 localStorage 활용, 이벤트 추가 등등 기본적인 내용도 실패했었다.
가장 최근이었던 우테코 과제를 했던 작년 12월에 비하면 많이 성장했다고 느낀다. DOM을 다루는 법, 이벤트를 추가하는 법, 동적으로 HTML을 렌더링 하는 법 등등 아주 기초적인 것들도 못했던 내가 컴포넌트를 사용하고, API를 활용하고, PR을 작성하고 많은 일들을 할 수 있게 된 것 같아 나름의 발전이 있었다고 생각한다.
다른 분들의 PR, 회고 및 블로그 등을 보면 아직도 갈길이 멀게만 느껴진다. 같은 과제를 진행했던 게 맞는지 의심이 들 정도로 수준 차이가 느껴지고 있지만, 늦게 시작한 만큼 부족한 건 사실이고 앞서 계신 분들이 나의 방향성이라고 생각하고 따라잡을 수 있도록 많은 노력을 해야겠다.
스스로에 대한 느낀 점 외에도 다른 분들을 보고 느낀 점이 많다.
일단 부족한 실력 탓에 기능 구현에 급급했던 것과 달리 다른 분들은 “어떻게 하면 좋게 코드를 작성할 수 있을까(예를 들면 tree 구조 사이드바 렌더링을 더 좋게 작성하는 법, 리팩터링을 통해 컴포넌트를 더 잘게 쪼갠다던지, 엣지 케이스 파악 후 방어 코드 작성 등)?”를 많이 고민하고 해결하려고 노력하는 게 보였다.
타입 스크립트를 활용한다거나, 리액트 구조처럼 작성한다거나, 파일 디렉터리 구조를 신경 쓴다거나, 이벤트 버스 구조(맞는지 모르겠는데..)를 사용한다거나 등등(더 많을 텐데 다 찾아보지 못했다..) 본인은 아직 고민하지 못한 부분들을 많이 신경 쓰는 게 보여서 언제쯤 다른 분들과 같은 고민들을 신경 쓸 수 있을지에 대한 많은 생각이 든다.
앞으로의 계획
1. 노션 클론 프로젝트 보완
시간이 허락하는 선에서 꾸준히 보완할 수 있도록 해야겠다. 첫 프로젝트라 완성도를 높이고 싶은 욕심이 있다. 리뷰가 달리면 적용할 수 있도록 하고, 보너스 기능 구현까지 도전해 볼 계획이다.
2. 자바스크립트에 대한 공부
“바닐라 자바스크립트”로만 과제를 구현한 이유. 다른 프레임워크나 라이브러리를 사용하기에 앞서 자바스크립트에 대한 이해도를 높이기 위함이라고 생각한다. 알고리즘, 자료구조 공부를 제외하고 가장 신경 써서 공부해야 할 내용이라고 생각한다. 이 전까지 그랬던 적이 없어 많이 헤매고 당황하고 어려워했던 것 같다. 관련 서적을 참고해서 꾸준히 공부할 수 있도록 할 예정이다(모던 자바스크립트 Deep Dive, You don’t know JS).
'프로그래머스 > 데브코스 프론트엔드' 카테고리의 다른 글
[TIL] 2022-04-28 / 28일차 (0) | 2022.04.29 |
---|---|
[TIL] 2022-04-26 / 27일차 (0) | 2022.04.26 |
[TIL] 2022-04-21 / 24일차 (0) | 2022.04.21 |
[TIL] 2022-04-19 / 22일차 (0) | 2022.04.20 |
[TIL] 2022-04-18 / 21일차 (2) | 2022.04.18 |