Vue3 Composition API에 대해 알아보기

Vue2와 Vue3의 가장 큰 차이점은 Composition API가 추가되었다는 것입니다. Composition API는 기존의 Options API의 단점들을 보완하였으며, Vue 컴포넌트를 작성하는 방식을 완전히 뒤바꾸었습니다. 오늘은 Composition API에 대해 알아보겠습니다.

Composition API란?

Composition API는 Vue 컴포넌트 작성시 사용하는 여러 API들의 모음입니다. Composition API는 크게 3가지로 나눌 수 있습니다.

1. Reactivity API: 기존 Options API의 data, computed, watch에 해당하는 상태들을 생성하도록 도와주는 API
2. Lifecycle Hooks: 기존 Options API의 mounted, destroyed 등 Lifecycle hook과 동일
3. Dependency Injection: 의존성 주입을 도와주는 API

그렇다면 왜 Composition이 탄생했고, 어떻게 Options API를 대체하고자 하는걸까요?

왜 Composition API?

로직 재사용 용이성

기존에 Options API에선 mixin을 사용하여 동일한 로직들을 여러 컴포넌트에서 재사용할 수 있었습니다. 다만 mixin은 여러 단점들이 있었습니다. 우선 특정 속성이 어떤 mixin에서 주입이 되었는지 파악하기 어려우며, 어떻게 구현되어있는지 혹은 어떻게 동작하는지 알기 어려웠니다. 또한 여러 mixin을 동시에 가져와 사용하는 경우 namespace가 충돌하는 경우가 발생하거나, 여러 mixin이 서로 상호작용하는 경우 이를 쉽게 파악하기 어려웠습니다.

 

이를 해결하기 위해, Composition API에서는 동일한 로직들을 Composable 함수로 분리하여 재사용할 수 있도록 하였습니다. Composable 함수는 Vue의 Compositon API를 사용하여 stateful한 로직을 재사용할 수 있도록 도와줍니다.

 

예를 들어 컴포넌트에서 마우스의 위치를 트래킹하는 로직이 있다면, 이를 useMouse 함수로 분리하여 사용할 수 있습니다.

import { ref, onMounted, onUnmounted } from 'vue'

// 네이밍 컨벤션: use로 시작해야합니다.
export function useMouse() {
  // 캡슐화된 상태값
  const x = ref(0)
  const y = ref(0)

  // 상태 업데이트
  function update(event) {
    x.value = event.pageX
    y.value = event.pageY
  }
  
  // 해당 Composable 컴포넌트의 라이프사이클에 hook
  onMounted(() => window.addEventListener('mousemove', update))
  onUnmounted(() => window.removeEventListener('mousemove', update))

  return { x, y }
}

 

유연한 코드 구조

Options API는 정해진 구조로 코드를 작성해야했습니다. data, computed, methods, watch 등 정해진 옵션들이 있었고 해당하는 자리에 코드를 작성해야 했습니다. 구조가 명확하기에 코드 작성시 비교적 덜 고민하고 작성할 수 있었지만, 컴포넌트 로직이 커지고 복잡성이 높아질수록 코드 가독성이 떨어졌습니다. 특히 하나의 컴포넌트에 여러 로직들이 존재하게되면 특정 로직에 관련된 코드가 여러 위치에 분산되어 작성되어야하기 때문에 한눈에 파악하기 어려웠습니다. Composition API를 사용하면 코드 구조에 대한 엄격한 규칙이 없어지므로 특정 로직 관련 코드를 한 곳에 모아 가독성을 높일 수 있습니다.

 

더 나은 타입 추론

Options API가 처음 탄생했을때는 타입스크립트가 많이 사용되지 않았으며, 따라서 타입 추론에 대한 고민없이 처음 작성되었습니다. 그래서인지 타입 추론을 위해 여러 비효율적이고 복잡한 방법들을 사용하였습니다. 그럼에도 불구하고, mixin이나 의존성 주입시 타입 추론이 정상적으로 동작하지 않는등 이슈가 있었습니다. 이에 반해 Composition API는 주로 plain 변수와 함수를을 사용하기 때문에 타입 추론이 올바르게 동작합니다.

 

그렇다면 Composition API를 꼭 사용해야 하는가?

지금까지 봤을 땐 Composition API가 Options API보다 좋아보입니다. 그럼에도 불구하고 항상 Composition API를 사용해야 할까요? Composition API의 단점 혹은 한계점은 없을까요? 정답은 '가능하면 Composition API를 사용하는 것이 좋다'입니다.

 

우선 Composition API의 가장 큰 단점은 코드 구조가 너무 유연하다는 것입니다. Options API의 경우 코드 구조가 명확하게 정해져 있어서 코드 작성시 비교적 덜 고민하고 작성할 수 있습니다(less mental overhead). 반대로 Composition API는 컴포넌트 로직을 원하는 위치에 작성하게되고, 코드를 읽을때 정해진 구조가 없다보니 가독성이 떨어진다고 생각이 들게 될 수 있습니다. 그러나 실제로 Composition API는 로직을 명확하게 분리할 수 있습니다. 또한, 컴포넌트 옵션들간의 결합도가 감소되어 가독성이 향상됩니다. 따라서 규모가 큰 프로젝트에서 Composition API는 더 나은 확장성을 제공합니다. 

 

그럼에도 Options API를 아예 사용하지 말아야되는 것은 아닙니다. 규모가 작은 프로젝트에서는 Options API로도 충분히 가독성이 높은 코드를 작성할 수 있으며, Vue2에서 마이그레이션시 기존 Options API를 사용하고 있는 컴포넌트들을 한번에 Composition API를 변경하기 어렵다는 점에서 Vue 개발팀에선 Options API를 제거할 계획이 없다고 발표하였기에, Options API도 여전히 사용가능합니다. 따라서 두 API 중 어떤 것을 선택할지는 프로젝트의 규모, 팀의 선호도 및 기술적 요구사항에 따라서 선택하면 됩니다. Composition API는 더 나은 확장성을 제공하지만, 작은 프로젝트에서는 Options API도 충분히 유효할 수 있습니다.

 

Summary

• Composition API의 주요 특징
  • Vue3에서 도입된 주요 기능 중 하나로, 컴포넌트의 로직을 보다 모듈화된 구조로 관리할 수 있게 해줍니다.
  • 기존의 Options API보다 유연하고 재사용 가능한 코드를 작성할 수 있도록 지원합니다.
• 장점
  • 재사용성 향상: 컴포넌트 로직을 Composable 함수로 분리하여 여러 컴포넌트에서 쉽게 재사용할 수 있습니다.
  • 가독성 향상: 관련된 로직들을 그룹화하여 코드의 가독성을 향상시킵니다.
  • 타입 추론 개선: 타입 추론이 개선되어 코드 안정성을 높여줍니다.
• 단점
  • 유연성에 따른 가독성 저하: 코드 구조가 유연해져 가독성이 저하될 수 있습니다.
  • 기존 사용자의 적응 시간: 기존의 Options API를 사용하던 개발자들이 새로운 방식에 적응하는 시간이 필요합니다.
• 선택적 사용
  • 프로젝트의 규모와 요구 사항에 따라 Composition API를 선택적으로 사용할 수 있습니다.
  • 작은 규모의 프로젝트에서는 Options API로도 충분히 코드를 작성할 수 있습니다.