프로그래머스 데브코스에서 진행했던 개인 과제. Notion의 Todo List에 중점을 두고 만든 프로젝트입니다.
- terminal에서
npx server -s로 로컬 서버 설정 - 깃허브 페이지 로 접속
위 방법 중 편하신 방법대로 열람해주세요 (라우팅 문제로 로컬서버와 깃허브페이지와 코드가 조금 다릅니다)
- 페이지 렌더링
session storage를 통해 접속 기록 확인
최초 접속 시 웰컴페이지 표시
사이드 페이지의 목록 클릭을 통해 각 페이지 렌더링 및 세션 스토리지 기록
- 페이지, 포스트 관리(생성, 수정)
최상위 문서로 페이지를 지정, 페이지의 하위 문서로 포스트를 관리
title은 제목으로, content는 map형태로 관리하여 속성과 내용을 저장
(모든 생성, 수정, 삭제에 해당되는 내용으로, api 내용 변경 시 toast를 작동시켜서 가시화)
- 페이지, 포스트 관리(삭제)
삭제 버튼x을 통해 문서 삭제
하위 포스트 존재 시, 재귀를 사용한 removeChained( )함수를 통해 하위 포스트 탐색 후 전부 삭제
사이드 페이지에서 페이지 삭제 시에도 동일한 로직으로, 해당 페이지의 포스트 전부 삭제
- 페이지, 포스트 관리의 공통 사항
생성, 수정 시 마다 api의 데이터를 전송하고, 데이터를 다시 받아서 페이지를 재렌더링 -> 이유 : 생성, 수정는 에디터를 띄우고 페이지(포스트) 목록은 뒷편에 가려져 있기에 사용자의 포커스 밖에 있다고 생각
삭제 시에는 낙관적 업데이트를 통해, 데이터를 다시 받지 않고 html만 수정 -> 이유 : 삭제는 페이지(포스트) 목록을 보면서 이루어지는 행위이기에 재렌더링 되는 과정에서 나타나는 깜빡임, 로딩현상이 눈에 거슬린다고 생각
생성, 수정, 삭제 시 마다 toast를 통해 가시적 표시
(스크럼 중 팀원인 조민철님의 아이디어를 채용 👍)
API에서 사용할 수 있는 것이 title과 content 뿐이었기에,
content에 자료형를 담아서 속성을 구현해 보았습니다.
이 과정에서 두 가지 함수를 만들어서 사용했습니다(api.js에 담아서 이용)
- API에 요청을 보낼 때 option 객체에 담을 자료형을 정제하는
stringfyBody() - API에서 응답을 받았을 때, 자료형으로 파싱해주는
parseRes(){ title: Object, content: Map }의 형태로 API를 사용했기에 이러한 함수들이 필요했습니다.
처음 계획에서는 중복을 막기 위해, 중복 확인이 비교적 쉬운 map자료형을 사용했습니다.
하지만 시간에 쫓겨 결국 중복 체크 기능은 구현하지 못했습니다
또한 제가 생각한 Notion의 Todo List에서는 무한히 하위문서를 만들어낼 필요는 없다고 생각하고, 하위문서를 일정 수준 이상으로 만들어내는 기능을 제한했습니다.
최상위 배열 [0] : Notion의 페이지 이름에 해당한다. 사이드 페이지의 최상단(창 좌상단)의 정보를 담은 객체로, 프로젝트 전체의 정보를 담고 있다.
그 외 최상위 배열 : 여기선 페이지로 명명했으며, Notion의 workspace에 해당한다.
하위 documents 첫번째 하위문서(깊이 1): 해당 페이지에서 포스트 목록의 대표가 됩니다.
두번째 하위문서(깊이 2): 포스트 목록의 세부 사항을 기록합니다
계획했던 것만큼을 이루지 못한 것은 주어진 시간 내에 처리하지 못하는 역량의 한계라 어쩔 수 없지만...
예상치 못한 오류의 난립으로 이곳저곳 기워내는 바람에, 의미 없는 코드나 의미가 모호한 변수, 파라미터 등이 눈에 밟힙니다.
계속해서 수정하고는 있지만, 그 동안 피드백 받은 내용인데 실천하지 못해 아쉽습니다.
