파이딧 개발기

일반적으로 사이트에서 글을 작성할 때, HTML 기반의 에디터를 많이 사용한다. 하지만 개발과 관련된 사이트라면, 마크다운 기반의 에디터를 사용하는 것을 심심치않게 볼 수 있다.

내 블로그 또한 웹에서 작성하진 않지만, 마크다운을 기반으로 게시글을 작성하고 있다. 글을 직관적으로 작성할 수 있으면서도, HTML과의 호환이 뛰어나서 웹으로 표현하는데도 무리가 없다. 이를 보조하는 다양한 플러그인은 덤.

블로그 컨텐츠의 미려한 디자인을 위해 렌더링 코드를 추가하여 사용하고 있다. 예를들면, 코드블럭 같은 것들이 그렇다.

JAVASCRIPT
1
console.log('이런 기능');

너무 불편해!

마크다운과 HTML의 호환성 덕분에, 웹 사이트나 IDE의 플러그인 등 다양한 형태로 마크다운 변환 및 미리보기가 제공된다. 하지만, 대부분의 변환 서비스는 기본적인 변환 기능만을 제공해준다. 즉, 나처럼 조금이라도 커스터마이징 코드가 들어갈 경우, 보편적인 방식으로 변환 혹은 미리보기를 하기 어렵다.

때문에 블로그 글을 쓰고 확인하기 위해선, 반드시 블로그 프론트서버를 실행하여 직접 확인해야하는 번거로움이 있다. 여기까진 그려려니 할 수 있지만, 컴퓨터가 바뀔 경우, 블로그 개발환경을 일일히 세팅해줘야한다. 어차피 형상관리는 GitHub가 해주긴 하지만, 그 과정조차 번거로운건 사실이다.

이번에 블로그 개편을 하면서, react-markdown 디펜던시를 활용하여 리액트 기반의 컴포넌트를 적용한 마크다운 변환기를 만들어 적용했다.

TSX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<ReactMarkdown
    components={{
        a: A,
        blockquote: Blockquote,
        code: Code,
        h1: H1,
        h2: H2,
        h3: H3,
        h4: H4,
        h5: H5,
        h6: H6,
        img: Img,
        table: Table,
        td: Td,
        th: Th,
        tr: Tr
    }}
>
    {markdown}
</ReactMarkdown>

위와 같은 방식으로 원하는 태그에 원하는 컴포넌트를 적용할 수 있었다. 이 컴포넌트를 활용하면 실시간으로 블로그의 디자인이 입혀진 마크다운 결과물을 확인할 수 있을 것이란 생각이 들었다.

구현

서비스의 기능은 명확하다. 웹에서 사용자가 입력하는 마크다운 텍스트를 받아, 실시간으로 HTML로 변환하여 보여준다. 즉, 입력부와 변환부 두 영역으로 구분할 수 있다.

여기서 변환부는 블로그 코드를 가져다 쓰면 되므로, 신경 쓸 필요 없다. 문제는 입력부인데, 사용자의 입력을 받을 영역이 필요하다. 일반적인 textarea를 사용한다면 그리 어렵지않게 구현할수는 있을것이다. 하지만, 원래 VSCode에서 작성하던 마크다운을 textarea로 바꾼다면, 디자인이나 기능 측면에서 많은 손해를 보게 될 것이다.

Monaco Editor

예전에 우연히 Monaco Editor라는 걸 듣게 된 적이 있다. VSCode의 에디터와 동일했는데, VSCode를 기반으로 만들어진건지, VSCode가 Monaco Editor를 내부적으로 쓰는건진 잘 모르겠다. 아무튼 중요한 건, Monaco Editor를 적용하면 VSCode와 유사한 UX를 제공할 수 있는 셈이다.

@monaco-editor/react 디펜던시를 활용하여 입력부를 설계할 수 있었다. 왠만한 설정은 옵션 코드로 적용이 가능해서, 생각보다 간단하게 구현할 수 있었다. 아마 이걸 모르고 그냥 textarea를 붙잡고 있었으면 어마어마한 삽질은 물론, 지저분한 컴포넌트를 만들어서 사용해야 했을 것은 자명하다.

입력부와 변환부가 모두 구현된 이후, 나머진 간단했다. 에디터에 입력된 값을 상태값으로 저장하고, 이를 변환부 컴포넌트에 전달하는 것으로 구현이 완료됐다.

결과

파이딧

불현듯 생각나서 급하게 만든 것 치고는 그리 나쁘지 않았다. VSCode에 비해 사용성은 조금 떨어지긴 하다. 하지만 이제 앞으로 어디서든, 어떤 기기로든 인터넷만 접속 가능하다면 블로그 게시글을 작성할 수 있다.

가끔 다른 디바이스나 타지에서 글을 쓰고 싶을 때가 간간히 있었는데, 이젠 생각만 하지 않아도 되는 것이다.

이름은 뭘로할까 고민하다가, 내가 개발한 사이트에 자주 사용하는 𝝅에 에디터의 edit을 더해 파이딧으로 지었다. 마음에 쏙 들진 않는데, 딱히 나쁘지도 않다.

문제점

실제로 사용하면서 보이는 몇 가지 문제점이 있었다.

1. 글이 길어질수록 나타나는 렉

처음 만들어서 잠깐 테스트했을 땐 몰랐는데, 글이 길어지면 렉이 발생한다. 상태값을 활용하기도 하고, 무엇보다 마크다운을 복잡한 커스터마이징을 거쳐 실시간으로 변환해야한다. 글이 길어질수록 변환 시간이 증가하는 것은 당연한 일.

기본 변환이였다면 꽤 긴 글도 감당이 가능했을지 몰라도, 크고 작은 컴포넌트가 연관된 지금. 글이 길어질수록 렉이 눈에 띄게 증가한다.

한 가지 다행인점은, 미리보기 패널을 온/오프하는 것으로 이를 어느정도 해소할 수 있다. 우연한 계기긴 한데, DOM에 숨겨지는 태그들은 특별한 사유가 없는 한 숨김처리를 하는 것이 아니라 아예 없애버리는 걸 좋아한다.

TSX
1
2
3
4
5
6
7
8
9
10
11
12
13
// isActive에 따라 숨김처리할 경우
function A(): JSX.Element
{
    return <Component style={{ display: isActive ? 'block' : 'none' }} />;
}

// isActive에 따라 DOM을 아예 제거할 경우
function B(): JSX.Element
{
    return isActive ? (
        <Component />
    ) : null;
}