defineEmits is the <script setup> macro for declaring custom events that a component can emit, replacing the emits option and giving you type-safe emit functions with IDE autocompletion. As the creator of CoreUI with Vue development experience since 2014, I use defineEmits in every component that communicates with its parent through events, from simple click callbacks to complex form submission payloads. Declaring emits explicitly serves two purposes: it documents the component’s event API, and it enables Vue to distinguish between custom events and native DOM events on the root element. The TypeScript generic syntax provides the best developer experience with full type inference on the emitted payload.

defineProps is the <script setup> compiler macro for declaring component props in Vue 3, replacing the props option from the Options API with a more concise and TypeScript-friendly syntax. As the creator of CoreUI with Vue development experience since 2014, I use defineProps in every <script setup> component because it gives both runtime validation and full TypeScript type inference without any extra configuration. Choosing between the runtime syntax and the TypeScript generic syntax depends on whether you need complex default values — the TypeScript syntax offers better type safety but requires withDefaults for defaults. Both approaches are idiomatic and supported — choose the one that fits your project’s TypeScript configuration.

In Vue 3 <script setup>, all bindings are private by default — parent components cannot access child component methods or data using template refs unless you explicitly expose them with defineExpose. As the creator of CoreUI with Vue development experience since 2014, I use defineExpose in CoreUI Vue components that need to provide imperative APIs, such as dialog open() and close() methods or form reset() and validate() methods. Without defineExpose, a parent’s childRef.value.open() call fails silently because the method is not exposed. This is intentional — <script setup> components are encapsulated by default, and defineExpose is an explicit contract of the public API.

watchEffect() automatically tracks all reactive dependencies used inside it and re-runs whenever any of them change — without you having to specify which values to watch. As the creator of CoreUI with Vue development experience since 2014, I use watchEffect() when a side effect depends on several reactive values and I don’t want to manually maintain a list of dependencies. The key difference from watch() is that watchEffect runs immediately on first call and doesn’t provide old values — it’s ideal for synchronization effects rather than reactive comparisons. Understanding when to choose watchEffect vs watch makes your Vue code cleaner and more maintainable.

watch() in Vue 3 runs a side effect in response to reactive state changes — fetching data when a filter changes, saving state to localStorage, or triggering animations when a value updates. As the creator of CoreUI with Vue development experience since 2014, I use watch() whenever I need to react to a change with a side effect, and computed() when I just need a derived value. The key difference from watchEffect() is that watch() is explicit — you declare exactly what to watch and receive the old and new values in the callback. This makes it easier to understand what triggers the watcher and to compare values before and after.

computed() creates a cached reactive value derived from other reactive state — it recalculates only when its dependencies change, making it more efficient than calling a method in the template on every render. As the creator of CoreUI with Vue development experience since 2014, I use computed() extensively in CoreUI Vue components for filtering, sorting, and formatting data that depends on reactive state. The most important distinction from a regular method is caching — if the dependencies haven’t changed, Vue returns the cached result instantly without re-running the function. This makes computed the right choice for any derived value accessed in a template.

ref() is the foundational reactivity primitive in Vue 3’s Composition API, wrapping any value — string, number, boolean, object, or array — in a reactive container that Vue can track. As the creator of CoreUI with Vue development experience since 2014, I use ref() as the default choice for reactive state in every Vue 3 component because it works consistently with all value types. The one thing to remember is that ref values must be accessed with .value in JavaScript, while Vue templates automatically unwrap refs so you write {{ count }} not {{ count.value }}. This distinction catches new Vue 3 developers by surprise but becomes second nature quickly.

reactive() creates a deeply reactive proxy of a plain object, making Vue track all nested property changes automatically — unlike ref() which wraps a single value. As the creator of CoreUI with Vue development experience since 2014, I use reactive() when managing objects with multiple related properties that should be kept together, such as form state or a user profile. The key difference from ref() is that reactive() returns the object directly — no .value wrapper — making it feel more natural for complex objects. Understanding when to use reactive() vs ref() is one of the most important decisions in Vue 3 Composition API code.

The setup() function is the entry point for the Composition API in Vue 3, replacing the scattered data, computed, methods, and lifecycle options of the Options API with a single, cohesive function. As the creator of CoreUI with Vue development experience since 2014, I’ve migrated dozens of complex components from Options API to setup() and the result is consistently more readable and testable code. Everything you return from setup() becomes available in the template — reactive references, computed properties, and methods alike. Understanding setup() is the foundation for all other Composition API features.

defineComponent is a Vue 3 utility function that enables full TypeScript support by providing proper type inference for component options and the setup function. As the creator of CoreUI with Vue development experience since 2014, I use defineComponent in every TypeScript Vue component because it makes IDEs correctly infer prop types, emitted events, and the return value of setup. Without it, TypeScript treats the component object as a plain object and loses the Vue-specific type information. For <script setup> components you don’t need it — it’s most valuable when writing components with explicit setup functions or Options API in TypeScript files.