(1/12) If your Vue 3 app uses <script setup> and you need to watch two different refs in the same callback, how do you accomplish that?

---

• Use watchers in separate components only
• Use watch([refA, refB], ([newA, newB], [oldA, oldB]) => { ... })
• You cannot watch two refs at once
• You must define two separate watch calls

(2/12) How can you define watchers if your code is a library built with defineCustomElement in Vue 3, turning a Vue SFC into a web component?

---

• No watchers in defineCustomElement
• Use defineExpose for concurrency watchers
• Within the defineCustomElement options or setup, watchers still work the same as a normal Vue component, though it’s compiled to a custom element
• Use watchers in main.js for concurrency watchers only

(3/12) What advantage does the defineCustomElement API provide for Vue 3 developers?

---

• It is only used to create Node.js server modules
• It allows building native Web Components from Vue SFCs, usable outside Vue contexts
• It transforms Vue components into Angular directives
• It automatically wraps watchers for SSR

(4/12) If your large Vue 3 application uses multiple entry points or micro-frontends, how might you share a single store across them?

---

• Use watchers for all references globally
• Impossible to share data across multiple apps
• Export a reactive or Pinia store from a shared module, import it in each entry so it references the same data in memory
• Use defineExpose for each sub-application

(5/12) Which advanced scenario might you have if you define watchers in a custom createApp extension that tries to manage user session reactivity across multiple sub-apps in Vue 3?

---

• Use watchers in main.js for concurrency watchers only
• Use defineProps for concurrency watchers
• You can create watchers at a global level using an effect scope that is shared by all sub-apps. This is an advanced pattern for micro-frontends or multi-mount scenarios
• Vue 3 does not allow multiple sub-apps

(6/12) Which statement about watchers is correct if you define watchers for concurrency using watchEffect in a large form component in Vue 3?

---

• Use defineProps for concurrency watchers
• watchEffect is not recommended for forms
• No approach to watch forms in Vue 3
• You can easily end up with performance overhead if watchEffect references many fields. A better approach might be computed or selectively watch needed fields

(7/12) How can you watch the length of a reactive array in Vue 3 without triggering for every item push/splice?

---

• Use watch(myArray, ..., { lengthOnly: true })
• Watch(() => myArray.length, (newLen, oldLen) => { ... })
• Vue 3 does not allow partial watchers on arrays
• You must convert the array to a shallowRef

(8/12) When using watchEffect, how do you handle cleanup if the effect triggers multiple times quickly (e.g. for canceling an async request)?

---

• Use defineEmits for concurrency control
• Use watchers in main.js
• No cleanup approach is provided in watchEffect
• Pass an onInvalidate callback inside watchEffect(() => { onInvalidate(() => { ... }) })

(9/12) Which statement is true if you use watchEffect in a Vue 3 SSR environment for concurrency logic?

---

• Use watchers in main.js for concurrency watchers only
• No approach for watchers in SSR
• It always re-runs multiple times on the server
• SSR is a single-pass, so watchEffect might only run once if the data is set up. Typically, watchers or watchEffect are not the main pattern for SSR logic (onServerPrefetch is). No continuous reactivity is expected on the server

(10/12) Which statement about watchers is correct if you define them for concurrency referencing both route.query and a local search field in a single callback in Vue 3?

---

• Pass an array of getters or references, watch([() => route.query, () => searchField.value], callback). If changes happen simultaneously, the callback sees final values of both. Concurrency can be handled with onInvalidate
• Use defineProps for concurrency watchers
• Use watchers in main.js for concurrency watchers only
• Impossible to watch route and local field together

(11/12) How do watchers behave if you define watch(() => user.address.street, callback) in Vue 3, referencing concurrency logic, and user.address is replaced entirely with a new object?

---

• Use watchers in main.js for concurrency watchers only
• Impossible to watch nested fields in Vue 3
• They only trigger if the street field changes in the new address object. If user.address reference changes, the watch sees a new street reference if the street is different, so callback triggers
• No concurrency approach for nested fields

(12/12) Which statement about watchers referencing shallowReactive objects in Vue 3 is true if you mutate nested properties deeply?

---

• They only run if the top-level reference changes, ignoring deeper property modifications unless you reassign. For concurrency watchers, you might set objectRef.value = structuredClone(objectRef.value) after changes to trigger watchers
• Use watchers in main.js for concurrency watchers only
• Impossible to define watchers for shallowReactive
• They always re-run on nested changes

Submit