Front-Vue-SCSS) WriteView

devQra·2023년 8월 17일

목표

UI 구성 및 배치

미리보기



전체코드

<script setup lang="ts">
import { computed, ref } from 'vue'
import { marked } from 'marked'

const inputContents = ref('')
const inputTitle = ref('')
const outputContents = computed(() => marked(inputContents.value))
const outputTitle = computed(() => marked(inputTitle.value))
const updateTitle = (e: any) => {
  inputTitle.value = e.target.value
}
const updateContents = (e: any) => {
  inputContents.value = e.target.value
  console.log(marked(e.target.value))
}
</script>

<template>
  <div class="writeview-container">
    <div class="edit-container">
      <input
        class="title"
        placeholder="제목을 입력하세요"
        :value="inputTitle"
        @input="updateTitle"
      />
      <textarea
        class="editor"
        :value="inputContents"
        @input="updateContents"
        placeholder="내용을 입력해주세요."
        v-html="inputContents"
      />
    </div>
    <div class="preview-container">
      <div class="preview-title" v-html="outputTitle" />
      <div class="preview-text" v-html="outputContents" />
    </div>
  </div>
</template>

<style lang="scss">
@import '@/assets/View/WriteView.scss';
</style>

후기

Front에서 기능적으로 제일 중요한 페이지다. 글을 작성할 수 있어야 컨텐츠가 만들어지고, 이로 인해 나머지 모든 기능이 원활하게 동작할 수 있다.

졸업작품으로 개발할 때는 TOAST-UI의 에디터를 가져다가 사용했는데, 모든게 잘 갖춰져 있어서 가져다 쓰기만 하면 되니까 간편하긴 했다. 다만, velog와 같이 깔끔한 ui로 만들고 싶기도 했고, 직접 만들어보는 것도 재밌을 것 같았다. 결과적으로는 많은 사람들이 왜 만들어진걸 갖다 쓰는지 다시 한 번 느낀 계기가 된 것 같다. 이유는 세 가지가 있었다.

이슈1 - 미리보기의 css

첫 번째는 우측 미리보기 컴포넌트였다. v-html 속성을 이용해 텍스트를 띄우는 것은 비교적 간단하게 끝났다. 너무 쉬웠다. 하지만 문제는 그 이후였는데, # 과 같은 markdown 문법이 동작하지 않았다. 작성한 텍스트를 markdown 문법으로 parsing하고, html 형식으로 변환하는 중간 과정에 로그를 찍어봤지만 모든 부분이 정상적으로 동작하고 있었다. 결국 문제는 css가 정상적으로 적용되지 않고 있었다.

열심히 구글링 해보니 style 코드를 작성할 때 scope 옵션을 빼야한다고 했다. 빼고 나니 잘 작동은 했지만, 프로젝트를 셋업하면서 루트 부분이나 * 로 선언한 스타일 코드들이 기본 옵션을 덮어쓰면서 미리보기에 태그들의 스타일이 뒤죽박죽 섞여있었다. 좌우 간격이 이상하다던가, h1과 같은 제목 태그들은 볼드가 안먹고 글씨 크기도 일반 크기라던가.. 기본 스타일로 다 되돌릴까 했지만, 전체적으로 마음에 들지 않아서 태그 하나 하나 직접 스타일을 만져가면서 만들어보았다. 굉장한 노가다였다. 아직 다 마무리하지 못 하고 대체적으로 많이 쓰이는 것들만 우선적으로 작업하였다. 나머지는... 나중에...ㅎ

이슈2 - code block 스타일

문제1에서 노가다를 통해 하나씩 만들어가다가 code block에서 굉장히 당황했다. 테스트를 하다가 뭔가 밋밋하다는 생각이 들었는데 아니나 다를까 code high-lighting이 없다는걸 깨달았다. 구글링을 해보니 code block은 앞 뒤로 back quote 3개를 통해 구분하는데, 첫 back quote 옆에 사용한 언어를 적어주면 된다고 했다. C언어 테스트해보니 class에 c-language가 적용되는 것을 확인했지만 나는 더욱 더 당황스러울 뿐이었다. 이 말은 곧, 언어별로 하이라이팅을 내가 수작업으로 지원해줘야 한다는건데.. 어디서 모듈을 가져오는 것이 아닌 이상 수작업은 말도 안된다고 생각했다. 애초에 어떻게 접근해야 하는지 감도 안왔다. toast editor의 git repository를 아무리 뒤져도 찾을 수가 없었다. 결국 얘도 나중에 하기로 결정했다..

이슈3 - 에디터에 markdown 스타일 적용하기(?)

velog로 예를 들자면, 글 작성 시에 좌측에 markdown 문법으로 입력하면 우측 미리보기에 문법이 적용되어 보여주기도 하지만, 작성 중인 좌측에도 적용이 되는 것을 알 수 있다. pc 화면에서는 가로가 넓어 미리보기를 보면서 작업할 수 있지만, 태블릿이나 모바일 환경에서나 화면 분할로 작업하는 경우에는 미리보기를 보는 것이 불가능하다. 따라서 에디터에 스타일이 동일하게 반영된다면 사용성이 더욱 직관적으로 변할 것이라고 생각했기에 도전해보았지만 무참히 무너졌다. 며칠을 매달려서 작업했지만 도무지 방법을 못 찾았다. velog를 클론코딩한 사람들이나 toast-ui, textarea의 속성 등을 찾아보거나 css로 해결할 수 있는지 찾아보거나, velog에서 개발자 도구를 열고 하나씩 뜯어봤지만... 아직 내 수준으로는 이해하기 어려운 것인지 방법을 알아내기 어려웠다. 직접 만들어보자는 생각에 로직 구상에도 많은 시간을 투자한 것 같다. 하지만 결국은 실패... 핵심 기능이라기 보단 편의성에 가까운 부분이었기 때문에 이것도 결국 이슈로 남기고 나중에 해결하려고 한다.

결론

어쩌다보니 모든 이슈가 해결은 못 한 채로 유야무야 넘어가게 되었지만.. 장애를 일으키는 심각한 이슈는 아니기에 일단락했다. 아직 할 게 산더미기에 시간을 많이 할애할 수 없었다. 더군다나 곧 개강이기에..

깃 허브 링크

Github

profile
백엔드 개발자가 되고 싶은 취준생

0개의 댓글