Notion prettier 개발기

프로젝트를 시작하게 된 계기 Notion prettier는 현재 진행하고 있는 오픈소스 프로젝트 팀원이 노션에 코드를 작성하면서 텝이나 스페이스바를 연타하는 것을 보면서, 노션에 프리티어를 적용하면 어떨까요? 라고 내가 팀원에게 물어보면서 그런게 있으면 당장 쓸 것 같아요 라는 이야기를 듣고나서 시작했다. 프로젝트 이름 정하기 Markdown helper 처음에는 이름이 Markdown helper라는 이름으로 프로젝트를 만들었는데, 다른 사람에게 프로젝트를 설명할 때 프로젝트 이름만으로는 프로젝트를 설명하는 것이 어려워서, 이름으로 프로젝트를 쉽게 설명하는 이름이 없을까 고민하다가 Notion에서 Prettier를 사용하니 Notion Prettier로 하는게 어떨까 하고 변경했다. (지은게 아니라 그냥.. 붙인건가.. 싶기도 하다) 프로젝트 명을 바꾼 후 프로젝트 명을 바꾸니 프로젝트 이름만으로 설명이 가능해져서 사람들에게 프로젝트 설명이 쉬워졌고, 이로 인해서, 이전에 만들었던 크롬 익스텐션과는 다르게 외국인들도 다운받는 경우가 생겼다. 아이디어 1. VS코드에서 저장을 하면, 프리티어가 적용되는 것 처럼, 원하는 코드를 선택해서 Ctrl(Cmd) + S를 누르면, 코드에 프리티어가 적용되도록 만들자. 2. Alt + Shift를 누르면 노션에 있는 자주쓰는 단축키를 보이도록 만들자 문제점 그리고 해결책 문제점 : 코드 변경이 안되는 현상 노션 처음에 코드를 insert하였더니 눈으로만 코드가 변경되고 노션에는 실질적으로 프리티어가 적용이 안되는 현상이 있었다. 해결책 : 노션은 contenteditable으로 작성되었기 때문에 execcommand를 이용하여 원하는 코드를 붙여넣어야 했다. 이를 해결하기 위해 execcommand copy와 paste를 이용하였다. 문제 : copy를 이용하였더니, 원하지 않게 클립보드를 사용해야하는 현상이 있었다 해결책 : copy paste가 아닌 execcommand의 insertText를 이용하였다. 문제 : prettier를 적용한 코드에 두줄은 한줄이 되고, 한줄은 모두 붙어버리는 현상이 있었다. 해결책 : \n을 기준으로 split을 하여 배열로 만들고 text인 경우 insertText를, \n 인 경우 insertParagraph를 적용하였다. 문제 : insertParagraph를 사용하였더니 짧은 코드에서는 문제가 없었지만, 긴 코드에 prettier를 적용할 때는 브라우저가 잠시 멈추고 적용되었다. 해결책 : 처음에는 worker를 사용하여 다른 곳으로 보내서 처리를 할까 고민을 했었다. worker를 사용하기전에 프리티어를 적용하는 것이 시간이 오래 걸리는지, 아니면 붙여 넣는 과정이 오래 걸리는지 확인을 하였다. 시간을 확인해본 결과, 프리티어를 적용하는 시간은 얼마 걸리지 않지만 코드를 붙여넣는 과정에서 시간이 오래걸린다는 것을 알 수 있었다. 따라서, 코드를 붙여넣는 insertText와 insertParagraph가 아닌 다른방법을 선택하기로 하였다. 다양한 코드를 이용하여 insertText를 하면서 발견한 것은 notion에 insertText를 적용하면서 \n\n은 \n으로 변하고 \n\n\n은 \n\n으로 변하는 현상을 볼 수 있었다. 그래서 정규식을 이용하여 \n이 1개 이상이면 \n을 1개 추가해주도록 바꾸어 주었다. 개발 후기 이전의 프로젝트와는 다르게, 구현할 기능도 많지 않았기에, 개발 기간을 짧게 잡고 진행하였다. 하지만, 이 프로젝트를 하면서, 이전 프로젝트(리액트 웨이)를 만들면서 고민했었던, 번들러를 고르는 과정이라던가, package.json의 script를 어떤 식으로 사용해야할지에 대한 것을 복습할 수 있는 기회가 되어서 좋았다. prettier를 적용하는 것은 npm에 있는 prettier를 이용하여 처리하였는데, 사실 prettier에 있는 npm을 직접 호출하여 사용하기보다는 남들이 만들어둔 설정을 그대로 쓰는 것을 많이 사용하였기 때문에 prettier를 import를 하고 사용할 필요가 있었다. 이때, prettier에 작성된 코드들을 보면서 다른 오픈 소스들이 어떻게 작성되었는지를 볼 수 있었다. 잘작성된 오픈 소스코드를 보니 함수에 대한 주석과 props에 대한 주석을 이용하여 그 함수를 언제 사용하는지 어떤 props를 언제 사용하는지를 볼 수 있어서, 그 주석들을 이용하여 기능들을 유추할 수 있었다. 당장 이 프로젝트에서 적용을 할 필요는 없었지만 지금 팀원들과 만들고 있는 오픈소스 프로젝트에는 적용할 수 있어서, 주석을 사용하는 방법에 대해서 공부를 할 수 있어서 좋았다. 이번에 프로젝트 이름을 변경하면서, 함수나 변수의 이름도 중요하지만 프로젝트 명(혹은, 웹서비스나 어플리케이션의 이름..?)을 잘지으면 다른 사람들에게 쉽게 프로젝트에 대해 어필할 수 있구나를 느낄 수 있었다.