Composition API를 올바르게 사용하는 방법

소개

이 기사에서는 Composition API를 사용해야 하는 이유와 올바르게 수행하는 방법을 살펴보겠습니다.

이전 옵션 API 방식이 아닌 이유는 무엇입니까?

우선, 옵션 API가 더 이상 사용되지 않더라도 문서를 읽어보면 이것이 권장되지 않으며 새로운 권장 방법은 Composition API 및 스크립트 설정이라는 것을 알 수 있습니다.

문서에서:

• Go with Options API if you are not using build tools, or plan to use Vue primarily in low-complexity scenarios, e.g. progressive enhancement.

• Go with Composition API + Single-File Components if you plan to build full applications with Vue.

If you intend to exclusively use Composition API (along with the options listed above), you can shave a few kbs off your production bundle via a compile-time flag that drops Options API related code from Vue

Options API does allow you to "think less" when writing component code, which is why many users love it. However, in reducing the mental overhead, it also locks you into the prescribed code organization pattern with no escape hatch, which can make it difficult to refactor or improve code quality in larger scale projects. In this regard, Composition API provides better long term scalability.

즉, Options API 대신 Composition API를 사용하면 성능이 향상되고 장기적인 확장성이 향상되며 전체 애플리케이션을 구축하려는 경우 권장되는 방법입니다.

Composition API가 실제로 더 나은 이유는 무엇입니까?

이제 Composition API가 더 좋고 구성 요소를 작성하는 데 권장되는 방법임을 이해했으므로 그 이유를 이해해 보겠습니다.

Options API를 사용하면 다음과 같은 코드를 가질 수 있습니다.

export default {
    data: () => ({
        count: 0,
        newUser: ''
        newTodo: ''
    }),

    computed: {
        filteredTodos(){ /*...*/ },
        filteredUsers(){ /*...*/ }
    },

    methods: {
        doubleCount(){ /*...*/ },
        addAndClearUser(){ /*...*/ },
        addAndClearTodo(){ /*...*/ }
    }
}

이 구성 요소는 개수, 사용자 및 할 일의 세 가지 논리적 문제를 처리합니다. 언뜻 보기에는 구성 요소가 매우 작기 때문에 문제가 보이지 않지만 해당 구성 요소에 더 많은 것을 추가하면 파일의 다른 부분에 있는 다른 옵션으로 논리적 문제가 강제로 분할되는 것을 볼 수 있습니다.

이제 문제를 알았으니 Composition API로 문제를 해결하는 방법을 살펴보겠습니다.

import { ref, computed } from 'vue'

// Count
const count = ref(0)
function doubleCount(){ /*...*/ }

// User
const newUser = ref('')
const filteredUsers = computed(() => { /*...*/ })
function addAndClearUser(){ /*...*/ }

// Todo
const newTodo = ref('')
const filteredTodos = computed(() => { /*...*/ })
function addAndClearTodo(){ /*...*/ }

이제 동일한 논리적 문제와 관련된 코드를 함께 그룹화할 수 있는 방법에 주목하십시오. 더 이상 특정 논리적 문제에 대해 작업하는 동안 다른 옵션 블록 사이를 이동할 필요가 없습니다.

이제 Composition API를 사용하면 특정 논리적 문제와 관련된 코드를 찾기 위해 위아래로 스크롤할 필요가 없습니다.

더욱 흥미로운 점은 코드를 추출하기 위해 더 이상 코드를 섞을 필요가 없기 때문에(옵션 API와 같이) 코드 그룹을 최소한의 노력으로 외부 파일로 옮길 수 있다는 것입니다. 따라서 구성 요소는 다음과 같이 표시됩니다.

import { useCount, useUser, useTodo } from './composables'

const { count, doubleCount } = useCount()
const { newUser, filteredUsers, addAndClearUser } = useUser()
const { newTodo, filteredTodos, addAndClearTodo } = useTodo()

놀랍지 않나요? 😎🆒

논리적 관심사를 어떻게 구조화할 것인가?

따라서 Composition API의 주요 이점은 특정 논리적 문제와 관련된 코드를 함께 그룹화해야 한다는 것이지만 일관성이 없으면 코드를 읽고 이해하기 어려울 수 있음을 경험했습니다.

그래서 논리적인 고민을 일관되게 정리해야 합니다.
개인적으로는 Options API로 작성하듯이 논리적 고민을 정리합니다. 따라서 다음 순서로:

<script setup>
// Props (defineProps)
// Emits (defineEmits)
// Reactive variables (inc composables)
// Computed
// Methods
// Watchers
// Lifecycle Hooks
// Expose (defineExpose)
</script>

논리적 문제를 구성하는 다른 방법을 사용하는 경우 의견에 알려주세요.

논리적 문제를 구성하는 이 일관된 방법을 사용하면 코드를 더 쉽게 읽고 이해할 수 있습니다.

내가 본 또 다른 패턴은 각각의 논리적 관심사 앞에 주석을 추가하여 그것들을 구별하는 것입니다. 개인적으로 이 패턴을 사용하는데 코드를 더 쉽게 읽을 수 있어서 적극 추천합니다.

예를 들어:

<script setup>
import { ref } from 'vue'

// Count 👈 this
const count = ref(0)
function doubleCount(){ /*...*/ }

// User 👈 this
const newUser = ref('')
function addAndClearUser(){ /*...*/ }
</script>

마지막으로 저는 항상 함수에 대해 function(화살표 함수)보다 const 선언을 선호합니다. 그 결과 좋은 패턴을 얻었고 한 가지 이유는 Uncaught ReferenceError: Cannot access '<variable>' before initialization 😉를 얻지 못할 것이라는 것입니다.

결론

이 기사가 Composition API가 구성 요소를 작성하는 더 좋은 방법인 이유와 이를 올바르게 사용하는 방법을 이해하는 데 도움이 되었기를 바랍니다. 처음에는 이점을 즉시 확인하지 못할 수도 있지만 응용 프로그램이 커짐에 따라 응용 프로그램을 사용해 주셔서 감사합니다.

Composition API는 많은 가능성을 열었으며 깨끗하고 효율적인 로직 재사용을 가능하게 합니다. 사랑에 빠지는 것은 시간 문제일 뿐이지만 올바른 방법으로 사용해야 하며 지금까지 내 경험상 많은 개발자가 잘못된 방법으로 사용하는 것을 보았습니다.

이 기사를 읽어 주셔서 감사합니다. 좋아요를 남겨주시고 마음에 드셨다면 네트워크와 공유하세요. 🎉