[메모 트리 프로젝트] 6. 나머지 프론트엔드 작업

프로젝트 글 목차

2021.03.13 - [메모 트리 프로젝트] 1. 기획

2021.03.13 - [메모 트리 프로젝트] 2. 설계 - 와이어프레임, 요구 사항

2021.03.14 - [메모 트리 프로젝트] 3. 설계 - 객체 모델링

2021.03.18 - [메모 트리 프로젝트] 4. UI 구현 - 1

2021.03.19 - [메모 트리 프로젝트] 5. UI 구현 - 2

2021.03.20 - [메모 트리 프로젝트] 6. 나머지 프론트엔드 작업

2021.03.20 - [메모 트리 프로젝트] 7. 배포 및 후기

---

나머지 프론트엔드 작업

나머지라고 뭉뚱그리기에는 여러 작업이 있었지만 최대한 간략하게 정리했다.

먼저 메모 트리 프로젝트에서 클래스로 분리할만한 기능은 다음과 같았다.

여기서 가장 고민했던 점은 contextmenu와 contentview과 item의 관계.

컨텍스트메뉴와 컨텐트뷰는 main의 init() 함수에서 한 번만 생성한 이후 item의 root 객체에 인자로 전달하는 구조다.

조금 아쉬운 부분은 컨텍스트메뉴와 컨텐트뷰에서 일어난 이벤트로 인해 item의 값이 변경될 수 있다는 부분.

컨텍스트메뉴는 폴더와 파일을 생성하며, 선택된 아이템의 색상 변경 및 삭제까지 담당한다.

그리고 컨텐트뷰는 타입이 파일인 아이템의 내용 변경을 담당한다.

 

- Item
 > createEvent()
  > 우클릭, 더블클릭에 따라 컨텍스트메뉴와 컨텐트뷰의 open() 함수를 호출
  
- Contextmenu
 > addFolder(), addFile(), handleColor(), deleteItem()
  > item의 delete(), setStyles() 함수 호출 및 프로퍼티의 직접적인 변경
  
- Contentview
 > updateText()
  > item의 프로퍼티를 직접적으로 변경

 

open 이후 메뉴와 뷰에서 기존에 선언한 이벤트로 제어하는 것보다 item이 직접 정의하여 전달하는 방향으로 바꾸는게 더 나은 구조가 아닐까 싶은 생각이 들었지만 현재 구조를 유지하게 됐다.

현재 구조에서는 Item에 작은 변경이 생겨도 메뉴와 뷰에 수정이 필요하다. 그러므로 재사용이 매우 불편한 구조!

예를 들어 content라는 프로퍼티 키 값이 text로 바뀌면 따라 바뀌어야 하는 부분들?

 

하지만 현재 프로젝트의 구현이 우선이기에 당장 변경하지는 않았다.

기능 구현에서 많은 고민이 있었지만 다 적자니 끝이 없을 거 같다.

캔버스를 파일 영역의 크기에 비례해서 수정한다거나 하는 다양한 이슈가 있었지만 결과적으로 구현 자체에 큰 문제는 없었다.

 

현재 스크롤이 발생한 상황에서 스크롤이 top이 아닌 상황에 아이템을 삭제했을 때, 선을 새로 그려주는 부분에서의 문제와 최하단 아이템의 컨텍스트 메뉴가 정상적으로 출력되지 않는 문제가 있다.

후자는 body의 영역의 하단 마진이 존재하지 않아서 생기는 부분이고 전자는 확실하지는 않지만 getBoundingClientRect가 원인이 아닐까 생각된다. 

 

최대한 빨리 수정해야겠다 :(

 

memotree.herokuapp.com/60540dede23f660015bd703c