We are excited to announce the release of CoreUI for Vue v5.8.0. This update introduces two powerful new components - Chip and Chip Input - bringing modern, compact UI elements for tags, labels, and multi-value inputs to your Vue.js applications.

We are excited to announce the release of CoreUI PRO for Vue v5.18.0. This update introduces powerful new Chip and Chip Input components, plus all exclusive PRO components for building sophisticated enterprise Vue.js applications with Vue 3 compatibility.

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.