23.03.21 Vue

Introduction

vue의 특성

• Declarative Rendering
• Reactivity

Single-File Components

• JS(<script>), HTML(<template>), CSS(<style>) 소스들이 하나의 파일에 저장되어있는 양식

Vue components can be authored in two different API styles

1. Options API

   • data, methods, mounted와 같은 options의 객체들을 사용해서 컴포넌트의 로직을 정의하는 스타일이다.
   • options에 의해 정의된 속성들은 함수들 안에서 this 접근자(컴포넌트 인스턴트를 가리키게 해주는)로 접근 가능하다.

   <script>
   export default {
     // data()로 리턴된 값은 reactive 상태가 된다.
     // 그리고 'this' 접근자로 접근 가능하다.
     data() {
       return {
         count: 0
       }
     },
   
     // methods는 상태를 변경하고 업데이트를 발생시키는 함수들이다.
     // templates(html)에서 이벤트 리스너로 바인딩할 수 있다.
     methods: {
       increment() {
         this.count++
       }
     },
   
     // Lifecycle hooks는 컴포넌트의 생명주기의 각 스테이지에 따라 호출된다. 아래 예시와 같은 경우엔 컴포넌트가 mounted된 후에 호출될 것이다..
     mounted() {
       console.log(`The initial count is ${this.count}.`)
     }
   }
   </script>
   
   <template>
     <button @click="increment">Count is: {{ count }}</button>
   </template>

2. Composition API.

   • import한 API 함수들을 사용해서 컴포넌트의 로직을 정의하는 스타일이다. SFC에서는 <script setup> ~ </script> 안에 해당 스타일을 구현한다. setup 속성은 보다 적은 코드량과 컴파일 하는데 걸리는 시간으로 Composition API를 사용할 수 있게 해준다. 예를 들어, <script setup>에서 선언된 imports와 상위 레벨 변수들, 함수들은 template에서 바로 사용이 가능하다.

   <script setup>
   import { ref, onMounted } from 'vue'
   
   // reactive state
   const count = ref(0)
   
   // functions that mutate state and trigger updates
   function increment() {
   count.value++
   }
   
   // lifecycle hooks
   onMounted(() => {
   console.log(`The initial count is ${count.value}.`)
   })
   </script>
   
   <template>
   	<button @click="increment">Count is: {{ count }}</button>
   </template>

둘 중 어떤 스타일을 골라야 하는가?

사실 Options API는 Composition API의 최상위 계층에서 구현된 방식이다. 결국 기본적인 개념과 컨셉은 공유한다는 의미이다. 실제로 composition의 방식을 살펴보자. vue로부터 ref, onMounted를 import한다고 선언했으며 이 덕분에 위에서 설명한 장점대로 'directly usable'해졌다. 그리고 const타입의 count를 ref(0)으로 선언함으로서 reactive 상태로 만들었다. 아직 onMounted가 vue의 라이프사이클에서 어떤 주기를 차지하는지 모르지만 이 시기를 거칠때마다 console창에는 초기 카운트가 얼마라는 문자열이 찍힐 것이다.

Count is: ~~ 라는 버튼을 클릭할 때마다 Increment 함수가 실행될 것이며(Composition API의 장점) reactive state가 된 count가 increment 함수에 의해 1씩 증가되고, 이는 {{ count }} 에 반영되어 나타나진다. 개발자도구를 통해 onMounted()의 역할을 살펴보면, 콘솔창에는 "The initial count is 0" 라고 한번만 나타나진다. 즉, onMounted는 컴포넌트의 완전한 초기 구성이 이루어지고난 후에는 이미 끝난 상태임을 추측해볼 수 있다.

결론적으로, Options API는 조금 더 객체지향적인 느낌이 난다. 그야말로 options들의 구성 요소들을 중점적으로 챙기는 느낌이다. Composition API는 그야말로 '대체'라는 성격에 초점을 둔 느낌이다. setup 초반부에 필요한 속성들을 가져온 후 이를 순서 상관 없이(?) 선언하는 것 같다. 결국 객체지향과 절차지향의 느낌...이 강한데... 객체지향이 절차지향 이후에 나온 클린코드를 위한 스텝인 것을 생각해보면, 왜 vue 홈페이지에서 Options API를 Composition API의 top에서 구현된 것이며, 기본 컨셉과 지식은 같다고 하는지 이해가 대충 간다.

바로 다음 문단에 관련 글이 나온다.

"Options API는 컴포넌트 인스턴스의 개념에 초점을 맞췄다. 주로 객체지향 프로그래밍과 밀접한 관련이 있다." 라고 한다.

Composition API는 함수 스코프에서 reactive state 변수들을 직접적으로 선언하고, 복잡도를 컨트롤하기 위해 다중 변수들로부터 단계를 묶어 형성하는 것에 초점을 맞춘다. 이는 더 자유로운 작업을 할 수 있도록 해주기 때문에 reactivity가 어떻게 작동하는지 잘 이해하는지 알아야 더욱 효과적인 vue작업이 가능하다. 또한, 이러한 융통성덕에 로직의 설계와 재사용에 더욱 강력한 장점을 가진다.

• Introduction fin -

⚠️해당 글은 개발 입문 초보자의 시점에서 작성한 글이며, 잘못된 지식이 들어있을 수도 있습니다. 각종 견해와 조언, 반박 모두 환영합니다!⚠️