도입 목적지난번에 이어 Rich한 에디터를 만들어야하지만 그 전에 테스트 코드를 도입하기로 했습니다. 🎉이유는 Rich 에디터를 만들면서 코드도 너무 복잡하게 꼬이고, 버그 하나를 고치면 버그가 새로운 곳에서 생기는 문제가 자주 발생했기 때문입니다. 버그를 고치고 일일히 모든 기능을 테스트하기엔 자원의 낭비가 심했고 이에 따라 리팩토링을 하는데 엄두도 나지 않았습니다.하지만 테스트 코드를 적용한다면? 오류가 나도 테스트에서 알려주기 때문에 안심하며 리팩토링이 가능합니다!이런 목적으로 도입하게 되었고 연습삼아 Component 템플릿의 테스트 코드를 작성해보았습니다. 제가 Jest를 선택 한 이유와 테스트 코드의 장점, 환경 구축하는 법은 Jest를 Vite 프로젝트에 적용하기에 자세히 설명했습니다. C..
지난번에 이어 Rich 한 에디터를 만들어 보겠습니다.Toolbar 만들기이번에는 글에 Bold, Italic, underline, strikethrough를 적용할 수 있는 툴바를 만드려 하는데, 해야 하는 작업은 다음과 같습니다.툴바 노드 만들기텍스트에 드래그했을 때 툴바 활성화, 드래그 해제 시 툴바 비활성 이벤트 추가Toolbar 노드 만들기툴바 노드를 만들 때 한 번만 만들어 놓고 불러오는 위치만 달라지기 때문에 setup에 호출해 줄 툴바를 만드는 함수 하나를 만듭니다.const setToolbar = () => { const toolbar = document.createElement("div"); toolbar.className = "editor__toolbar"; toolbar.inn..
노션의 화려한 기능의 에디터를 그나마 비슷하게 따라 하기 위해 여러 가지 도전을 해보려 합니다. 다음과 같은 순서로 진행합니다.enter로 다른 DOM으로 분리하기 & shift+enter로 줄 바꿈 하기Drag&Drop으로 위치 변경하기 enter로 다른 DOM으로 분리하기 & shift +enter로 줄 바꿈 하기먼저, contentEditable div를 만들어 해당 div안에서 enter를 입력하게 되면 새로운 contentEditable div를 만들 도록하겠습니다. export default class EditorTotalContents extends Component {... template() { return ` ..
프로젝트를 진행하던 중 사이드바에서의 동작이 에디터를 제어하거나 그 반대의 상황일 때 porps로 상태를 전달하기엔 적어도 3depth의 컴포넌트를 거쳐야 합니다. 이때 코드가 복잡해지면 상태를 관리하기 힘들어지는 props drilling 문제가 생기는데 이를 해결하기 위해 중앙 집중식 상태 관리를 적용했습니다. 이전에 작성한 Vanilla JS로 중앙 집중식 상태 관리 구현하기를 이용했습니다. 저는 총 2개의 store를 만들어 관리했습니다. 1. 사이드바의 전체 페이지들을 저장하는 store2. 현재 편집하려는 페이지의 Id를 저장하는 store 사이드바의 전체 페이지들을 저장하는 store store_pages.store.js store는 다음과 같이 만들어주었습니다.import { create..
[Vanilla JS 문서편집기 설명 및 개선] 3. 사이드바 렌더링 최적화 및 성능 비용 절감 글을 작성했지만 이는 가독성이 매우 매우 좋지 않고 다른 부분의 렌더링을 최적화하려면 코드를 새로 작성해야 한다는 문제가 있습니다. 기능을 추가할 때마다 새로운 문제에 직면하는 사이드 이펙트도 있어 정말 딱 그 부분만을 위한 최적화였던 것입니다. 저는 렌더링 최적화 방식을 개선해야 할 필요성을 느꼈고 일관성 있도록 최적화하고 싶었습니다. 따라서, 리액트에서 렌더링 하는 방식인 VirtualDOM처럼 기존 DOM과 새로 만들어질 DOM을 비교해 변경된 부분만 업데이트해 주는 방식을 적용해보려 합니다. VirtualDOM이란?실제 DOM을 조작하는 방식이 아닌, 실제 DOM을 모방한 가상의 DOM을 만들어 실..
컴포넌트 템플릿이전에 리액트나 뷰를 이용할 때는 정해져 있는 형식이 있었기 때문에 편리했습니다. 반면에, Vanilla JS는 제가 자유롭게 작성할 수 있는 구조입니다. 기존 코드는 규칙도 이전에 작성한 코드를 보며 ctrl+c, v 방식으로 비슷하게 만들었습니다. 하지만 이는 비효율적인 방법으로 컴포넌트가 늘어날 수록 부담되는 방법입니다. 또, 가독성이 좋지 않기 때문에 다른 사람이 봤을 때 어떤 기능을 하는지, 어떤 방식으로 작성했는지 알 수 없는 문제가 있습니다. 그렇기 때문에 편리하게 형식을 항상 동일하게 가져갈 수 있도록 작성해야 할 필요성을 느껴 컴포넌트 템플릿을 만들어 사용했습니다. export default class Component { $target; props; state; ..