ref() recommended over reactive() for state
Due to limitations of reactive() (cannot hold primitives, cannot replace entire object, not destructure-friendly), ref() is recommended as the primary API for declaring reactive state.
composition api
19 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
ref() wraps values in a reactive wrapper with .value
The ref() function takes an argument and returns it wrapped in a ref object with a .value property. To access or mutate the value in JavaScript, you use the .value property. Example: const count = ref(0); count.value++ accesses the wrapped value.
Refs are automatically unwrapped in templates
When using refs inside a component's template, you do not need to append .value. Vue automatically unwraps refs for convenience when used inside templates, with some caveats.
setup() function exposes refs and methods to template
In Composition API, the setup() function is a special hook where you declare refs and methods. Whatever is returned from setup() becomes available in the template.
<script setup> simplifies Composition API usage
When using Single-File Components with <script setup>, top-level imports, variables and functions declared in the script are automatically usable in the template of the same component. The template has access to everything declared in the same scope.
Why refs use .value instead of plain variables
Refs use .value to allow Vue's dependency-tracking based reactivity system to detect when a ref has been accessed or mutated. Vue tracks ref access in the getter and triggers updates in the setter. In standard JavaScript, there is no way to detect access or mutation of plain variables, but we can intercept get and set operations on object properties.
Refs enable retaining reactivity when passing to functions
Unlike plain variables, refs can be passed into functions while retaining access to the latest value and the reactivity connection. This is particularly useful when refactoring complex logic into reusable code.
ref() makes values deeply reactive
A ref will make its value deeply reactive, including nested objects and arrays. Changes to nested objects or arrays will be detected and trigger updates. Non-primitive values are turned into reactive proxies via reactive().
shallowRef() opts out of deep reactivity
For shallow refs, only .value access is tracked for reactivity. Shallow refs can be used for optimizing performance by avoiding the observation cost of large objects or when inner state is managed by an external library.
reactive() makes objects deeply reactive
The reactive() API makes an object itself reactive, unlike ref which wraps the value. reactive() converts objects deeply, meaning nested objects are also wrapped with reactive() when accessed. It returns a JavaScript Proxy of the original object.
reactive() returns a Proxy not equal to original
The value returned from reactive() is a Proxy of the original object and is not equal to the original object (proxy === raw is false). Only the proxy is reactive; mutating the original object will not trigger updates. Always use the proxied version of state.
reactive() on same object returns same proxy
Calling reactive() on the same object always returns the same proxy. Calling reactive() on an existing proxy also returns that same proxy. This rule applies to nested objects as well.
reactive() limitations: value types
reactive() only works for object types including objects, arrays, and collection types like Map and Set. It cannot hold primitive types such as string, number, or boolean.
reactive() limitation: cannot replace entire object
Since Vue's reactivity tracking works over property access, you must always keep the same reference to a reactive object. You cannot easily replace a reactive object because the reactivity connection to the first reference is lost when reassigning.
reactive() limitation: destructuring breaks reactivity
When you destructure a reactive object's primitive type property into local variables or pass it into a function, you lose the reactivity connection. You must pass the entire object to retain reactivity.
Ref unwrapping as reactive object property
A ref is automatically unwrapped when accessed or mutated as a property of a reactive object. It behaves like a normal property. If a new ref is assigned to a property linked to an existing ref, it replaces the old ref and the original ref becomes disconnected.
No ref unwrapping in arrays and collections
Unlike reactive objects, there is no unwrapping performed when a ref is accessed as an element of a reactive array or native collection type like Map. You must use .value to access the ref's value in these cases.
Ref unwrapping in templates only for top-level properties
Ref unwrapping in templates only applies if the ref is a top-level property in the template render context. A nested ref like object.id is not unwrapped. However, if a ref is the final evaluated value of a text interpolation {{ }}, it does get unwrapped.
useSlots and useAttrs in script setup
Usage of slots and attrs inside <script setup> should be rare, since you can access them directly as $slots and $attrs in the template. In rare cases where needed, use useSlots and useAttrs helpers imported from 'vue'. These are actual runtime functions that return the equivalent of setupContext.slots and setupContext.attrs and can be used in normal composition API functions.