컴포넌트 템플릿이전에 리액트나 뷰를 이용할 때는 정해져 있는 형식이 있었기 때문에 편리했습니다. 반면에, Vanilla JS는 제가 자유롭게 작성할 수 있는 구조입니다. 기존 코드는 규칙도 이전에 작성한 코드를 보며 ctrl+c, v 방식으로 비슷하게 만들었습니다. 하지만 이는 비효율적인 방법으로 컴포넌트가 늘어날 수록 부담되는 방법입니다. 또, 가독성이 좋지 않기 때문에 다른 사람이 봤을 때 어떤 기능을 하는지, 어떤 방식으로 작성했는지 알 수 없는 문제가 있습니다. 그렇기 때문에 편리하게 형식을 항상 동일하게 가져갈 수 있도록 작성해야 할 필요성을 느껴 컴포넌트 템플릿을 만들어 사용했습니다. export default class Component { $target; props; state; ..
사이드바 렌더링 최적화기본적으로 사이드바의 동작은 페이지를 눌렀을 때 하위 항목을 보여주도록 되어있습니다. 이때, 기존 코드에선 사이드바 전체를 렌더링하고 있고 이 방식은 이미 존재하는 노드를 반복해서 그리기 때문에 자원을 낭비하게 됩니다. 따라서 렌더링을 최적화하기 위해 변경되는 부분만 추가&삭제하는 방식으로 렌더링 최적화를 하려 합니다. 사이드바 렌더링을 최적화하기 위해 다음과 같은 순서로 진행하였습니다. 1. 페이지의 열림 닫힘 여부 판단set을 이용해 열린 페이지의 id를 저장해 놓습니다. 만약 닫혀있는 페이지를 누르면 set에 해당 id가 입력되고, 열려있는 페이지를 누르면 set에 존재하는 해당 id가 삭제되는 방식으로 동작하게 합니다. (set의 시간복잡도는 O(1)이기 때문에 효율적이라 ..
서버 요청 로직제가 만든 문서 편집기의 API 요청은 다음과 같이 정리됩니다.사이드바전체 문서 구조 불러오기 - GET문서 생성하기 - POST문서 삭제하기 - DELETE문서 편집기특정 문서의 조회하기 - GET특정 문서 수정하기 - PUTAPI를 요청하기 위해 request 함수를 만들어 API_END_POINT에 url, options를 이용해 그때그때 필요한 상황에 맞춰 사용할 수 있게 했고, 만약 API 처리 중 이상이 생기면 홈으로 돌아가도록 했습니다. export const request = async (url = "", options = {}) => { try { const res = await fetch(`${API_END_POINT}${url}`, { ...option..
목적 기존 프로젝트에선 번들러를 따로 사용하지 않고 vscode의 Live Server를 이용해 페이지가 잘 동작하는지 확인했습니다. 하지만 프로젝트를 다시 다듬게 되었을 때 제가 여러가지를 놓치고 있다는 생각이 들었고, 해당 부분을 vite 번들러를 이용한다면 많은 부분을 해소할 수 있다고 생각했기 때문에 이번 기회에 추가해봤습니다. 제가 얻을 수 있는 장점은 다음과 같습니다.오류 사전 탐지 : 빌드했을 때 오류가 발생하는지코드 최적화의존성 관리 용이CSS, 이미지, 폰트 등 자산 관리호환성 : babel 등 트랜스파일러를 이용해 최신 JS 문법을 구형 브라우저에서도 동작할 수 있도록 변환 추후 github action을 이용해 main으로 merge시 build에 오류가 존재하지 않을 때만 merg..
이번 23.06.27~23.07.06 약 2주간 노션 클로닝 프로젝트를 진행했습니다.먼저,기본 요구사항바닐라 JS만을 이용해 노션을 클로닝화면 좌측에 Root Documents를 불러오는 API를 통해 루트 Documents를 렌더링Root Document를 클릭하면 오른쪽 편집기 영역에 해당 Document의 Content를 렌더링해당 Root Document에 하위 Document가 있는 경우, 해당 Document 아래에 트리 형태로 렌더링각 Document 우측 + 클릭시 클릭한 Document의 하위 Document로 새 Document 생성 & 편집 화면으로 이동Document Save API를 이용해 지속적으로 서버에 저장History API를 이용해 SPA 형태로 제작보너스 요구사항div와..