Antigravity Agent
33 lines
4.5 KiB
Markdown
33 lines
4.5 KiB
Markdown
---
|
|
category: Other
|
|
tags: [auto-wikified, technical-documentation, other]
|
|
title: Reactivity API
|
|
description: "Reactivity API(반응성 API)는 Vue."
|
|
last_updated: 2026-05-04
|
|
---
|
|
|
|
# Reactivity API
|
|
|
|
## 📌 Brief Summary
|
|
Reactivity API(반응성 API)는 Vue.js 애플리케이션에서 상태(State)와 로직을 캡슐화하고 관리하기 위해 제공되는 핵심 함수들이다 [1, 2]. `ref()`, `reactive()`, `computed()`, `watch` 등의 도구를 활용하여 반응형 데이터를 선언하며, 단일 소스(Single source of truth)를 여러 컴포넌트 간에 손쉽게 공유할 수 있게 한다 [2-4]. 이를 통해 개발자는 단방향 데이터 흐름의 한계를 극복하고 컴포넌트 외부에서 전역 상태를 단순하게 관리하거나 유연한 로직 모듈(Composables)을 구성할 수 있다 [2, 5, 6].
|
|
|
|
## 📖 Core Content
|
|
* **`ref()`와 `reactive()`를 통한 로컬 상태 관리**
|
|
`ref()` 함수는 문자열, 숫자, 불리언, 객체 등 다양한 데이터 타입을 지원하는 다목적 상태 관리 도구로, `.value` 속성을 통해 데이터에 접근하거나 업데이트하는 명확한 구문을 제공한다 [1, 4]. 반면 `reactive()` 함수는 객체, 배열 및 컬렉션 처리에 특화되어 있으며, `.value`를 사용하지 않고 속성에 직접 접근할 수 있어 복잡한 데이터 구조를 직관적으로 다룰 수 있게 돕는다 [7].
|
|
* **파생 상태 생성 및 사이드 이펙트 처리**
|
|
`computed()` API는 다른 반응형 데이터를 기반으로 파생된 상태를 생성하며, 결과값을 캐싱하고 의존성이 변경될 때만 재계산된다 [4, 8]. `watch` API는 반응형 값의 변경을 관찰하고 API 호출과 같은 사이드 이펙트(비동기 작업 등)를 트리거하는 데 사용된다 [4, 9].
|
|
* **Reactivity API를 활용한 단순한 전역 상태 관리**
|
|
Reactivity API는 Vue의 컴포넌트 모델과 분리되어 있어 매우 유연하다 [3]. 옵션 API(Options API)의 `data()`가 내부적으로 `reactive()`를 사용하듯, 개발자는 `reactive()`나 `ref()`를 사용해 반응형 객체를 생성한 후 여러 컴포넌트에서 이를 임포트하여 전역 상태(Global State)처럼 공유할 수 있다 [2].
|
|
* **Composition API와의 통합 및 Vue 3.5 성능 최적화**
|
|
Reactivity API는 재사용 가능한 상태 저장 로직을 함수형태로 캡슐화하는 Composable을 구축하는 근간이 된다 [6, 9]. 또한 Vue 3.5 릴리스에서는 반응성 시스템이 크게 리팩토링되어 메모리 사용량이 56% 감소하였으며, 크고 깊은 반응형 배열(Deeply reactive arrays)에 대한 작업 속도가 최대 10배까지 빨라지는 등 대규모 애플리케이션을 위한 성능 향상이 이루어졌다 [10].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
* **타입 적용의 한계와 반응성 연결 단절 문제**
|
|
`reactive()`를 원시 값(Primitive values: 문자열, 숫자 등)에 잘못 사용하면 반응성이 깨질 수 있으므로, 원시 값에는 반드시 `ref()`를 사용해야 한다 [11]. 또한 `reactive()`로 생성된 반응형 객체를 직접 구조 분해 할당(Destructuring)할 경우 반응형 연결이 끊어지는 부작용이 발생한다 [11]. 이를 방지하려면 속성에 직접 접근하거나 `toRefs()` 함수를 활용하여 반응성을 유지해야 한다 [11].
|
|
* **무분별한 상태 변이로 인한 유지보수성 저하**
|
|
Reactivity API로 생성한 객체를 직접 공유할 경우, 임포트한 어떤 컴포넌트에서든 상태를 임의로 변이(Mutate)시킬 수 있다 [12]. 이러한 방식은 단기적으로는 편리하지만 장기적으로는 추적이 어려워 유지보수성을 해친다 [12]. 따라서 상태를 직접 수정하기보다는 명확한 의도를 표현하는 메서드(Action)를 상태 객체와 함께 정의하여 중앙 집중식으로 상태를 변경하도록 강제하는 것이 권장된다 [12].
|
|
* **서버 사이드 렌더링(SSR) 환경에서의 싱글톤 상태 유출**
|
|
서버 사이드 렌더링(SSR)을 사용하는 애플리케이션에서 단순한 Reactivity API로 전역 상태를 구현하면, 해당 스토어가 싱글톤으로 작동하여 여러 요청(Request) 간에 상태가 공유되거나 데이터가 유출되는 심각한 문제가 발생할 수 있다 [3]. 따라서 대규모 프로덕션 수준의 앱이나 SSR 환경에서는 Pinia와 같은 공식 상태 관리 라이브러리의 도입이 필수적으로 요구된다 [13].
|
|
|
|
---
|
|
*Last updated: 2026-05-03* |