Application Development - 2 · Quiz 1 · May 2025

**1. Detect reactive changes:** Vue 2’s observed getters/setters notify dependent watchers when an existing reactive data property changes. **2. Update efficiently:** Vue queues the component’s render/update work, compares the resulting virtual DOM and patches the necessary real DOM changes rather than reloading the page. **Answer: C — The virtual DOM detects changes and updates efficiently.** **Convention note:** More precisely, reactivity detects the data mutation; virtual-DOM comparison determines the required DOM patches. A: **Incorrect:** DOM patches are normally queued and use Vue’s rendering mechanism. B: **Incorrect:** A reactive data assignment does not reload the page. C: **Correct:** This is the closest description: reactive observation schedules a virtual-DOM update and efficient patch. D: **Incorrect:** The component instance and all DOM nodes are not necessarily destroyed and recreated.

**1. Apply the button operations:** Three adds make itemCount=3 and totalCost=45. One remove changes them to 2 and 30. **2. Evaluate the status computed property:** itemCount is nonzero and below 3, so status returns Few Items. **Answer: A — Items: 2, Total Cost: $30, Status: Few Items.** A: **Correct:** It correctly combines count 2, cost 30 and the below-three status. B: **Incorrect:** It does not subtract the removed item’s 15-dollar cost. C: **Incorrect:** It does not apply the removal to the item count. D: **Incorrect:** Full Cart applies at counts of at least three. E: **Incorrect:** Only one item is removed after three additions, leaving two.

**1. Use map’s thisArg:** The second argument [10,20,30] becomes this inside the ordinary callback function. **2. Multiply matching positions:** At indices 0,1,2, the products are 10×1=10, 20×2=40 and 30×3=90. map returns these three values. **Answer: B — [10,40,90].** A: **Incorrect:** The callback multiplies each original value instead of returning it unchanged. B: **Correct:** These are the three correct elementwise products. C: **Incorrect:** It omits multiplication by the original array entries. D: **Incorrect:** The explicit thisArg supplies all three indexed values.

**1. Apply Vue 2’s array caveat:** Direct assignment to an array index is not intercepted by its observation mechanism. items[0]=10 changes the array but does not by itself notify dependents. **2. Compare the alternatives:** push is an intercepted mutation, replacing the whole reactive items property triggers its setter, and obj.a was present during initialization and is reactive. Use Vue.set(items,0,10) or splice for the index update. **Answer: B — this.items[0] = 10.** **Convention note:** The question asks which will NOT trigger reactivity. The selected statement is a valid JavaScript mutation, but not a Vue 2 change-notification mechanism. A: **Incorrect:** Reactive arrays intercept push, so this does trigger updates. B: **Correct:** This is the requested non-notifying direct index assignment. C: **Incorrect:** Replacing an existing reactive data property invokes its setter. D: **Incorrect:** The existing nested property a is observed and can notify dependents.

**1. Identify the captured variable:** var i creates one function-scoped binding shared by all three returned functions; it is not a fresh binding for each iteration. **2. Call the closures after the loop:** The loop has ended with i=3. All three functions read that same final binding, so the output is 3,3,3. **Answer: D — 3, 3, 3.** A: **Incorrect:** This would require separate per-iteration bindings, such as let. B: **Incorrect:** The closures do not retain successive post-loop values. C: **Incorrect:** The captured variable exists and has the numeric value 3. D: **Correct:** All three closures read the shared i=3 after iteration ends.

**1. Check normal computed forms:** A computed getter can use method syntax, an ordinary function value, or an object containing get and optional set. **2. Check the async version:** An async getter returns a Promise. Vue 2 does not automatically await that Promise and use its resolved value as a normal synchronous computed property. Async fetching should update reactive state through a method, lifecycle hook or watcher. **Answer: C — C — the async computed getter.** **Convention note:** C is valid JavaScript syntax and can return a Promise as its computed value. Its problem is that standard Vue 2 computed properties do not provide automatic asynchronous resolution, not that the declaration is a syntax error. A: **Incorrect:** This is a valid synchronous getter, so do not select it. B: **Incorrect:** A computed property with get and set is supported, so do not select it. C: **Correct:** This is the intended incorrect implementation for an asynchronously resolved fullName value. D: **Incorrect:** This is equivalent to the valid ordinary-function getter form.

**1. Filter products by price:** price>50 retains laptop(800), keyboard(60), monitor(300) and removes mouse(25). **2. Attach and sort priorities:** Their priority values are laptop=3, keyboard=4 and monitor=2. Ascending priority order is monitor,laptop,keyboard. **3. Print each name:** forEach logs those three names in the sorted order. **Answer: B — monitor, laptop, keyboard.** A: **Incorrect:** It leaves the retained products in their original order rather than sorting. B: **Correct:** It sorts priorities 2,3,4 correctly after filtering. C: **Incorrect:** Mouse fails the price filter. D: **Incorrect:** It both includes mouse and omits the required priority sorting. E: **Incorrect:** All required lookups and array operations are valid.

**1. Evaluate ordinary method receivers:** grandParent.getName(), grandParent.parent.getName() and the child’s getNameFunc() each read the username of the object directly before the method call: GrandParent, Parent and Child. **2. Evaluate the arrow method:** getNameArrow captures the enclosing global this; object-literal nesting does not create a new this binding. In a fresh browser classic script, window.username is absent, so it returns undefined. **Answer: D — A: GrandParent; B: Parent; C: Child; D: undefined.** **Convention note:** The last value assumes a browser classic script and no pre-existing window.username property. In an ES module, lexical top-level this is undefined and that access would throw. A: **Incorrect:** Reading an absent window.username yields undefined, not ReferenceError. B: **Incorrect:** The child ordinary function correctly uses child, while the arrow does not. C: **Incorrect:** Nested ordinary method calls do not all use grandParent as receiver. D: **Correct:** It gives GrandParent,Parent,Child and the arrow’s undefined global property.

**1. Read the prop expression:** :start="5" passes the number 5 directly. It does not read the root’s start=10, because the bound expression is the literal 5. **2. Initialize and increment child-local state:** The child data factory copies this.start into count, so the display begins at 5. Each button click increments count by one. **Answer: B — The counter starts at 5 and increments by 1 per click.** A: **Incorrect:** The parent’s separate start property is not the literal expression passed here. B: **Correct:** The child receives 5 and increments its own numeric count. C: **Incorrect:** A compiler-inclusive Vue 2 CDN build supports this component template. D: **Incorrect:** The shown template and prop binding do not cause the claimed compilation failure.

**1. Create independent captured bindings:** math1 captures multiplier=3 and math2 captures multiplier=5. The first calculations return 4×3=12 and 2×5=10. **2. Update only math1’s binding:** math1.update(7) stores and returns 7; math1.calculate(4) now returns 28. **3. Inspect the independent closures:** math2.getMultiplier() still returns 5, while math1.getMultiplier() returns 7. **Answer: B — 12, 10, 7, 28, 5, 7.** A: **Incorrect:** It fails to use math1’s updated multiplier for its second calculation. B: **Correct:** It tracks both separate bindings and the update correctly. C: **Incorrect:** update returns the newly stored 7, not the old 3. D: **Incorrect:** It incorrectly shares the two factory invocations’ state. E: **Incorrect:** Four times the updated multiplier 7 is 28, not 21.

**1. Call the detached ordinary method:** method1() is not called through player1. In the stated classic-script context it reads window.score, which is undefined. The unrelated globalScore=25 is a different property name. **2. Invoke bound functions:** method2 is permanently bound to player2, returning 200. method3 is bound to player3, so method3(50)=75+50=125. **3. Attempt rebinding with call:** method3.call(player1,25) cannot replace the bound this. It still uses player3 and returns 75+25=100. **Answer: E — undefined, 200, 125, 100.** **Convention note:** This uses a fresh non-module browser script without an existing window.score value. An ordinary strict plain call would instead have undefined this and throw at the first method. A: **Incorrect:** The last bound receiver cannot be changed by call, so the final value is 100. B: **Incorrect:** globalScore is not a property named score, so the first value is not 25. C: **Incorrect:** The detached method has not retained player1 as receiver. D: **Incorrect:** It still mistakes globalScore for window.score. E: **Correct:** It gives the detached undefined value and respects both bound receivers.

**1. Compare ordinary and arrow receivers:** objj.normalMethod() uses objj, whose constructor name is Object. arrowFunc captures global this in a classic browser script, so its constructor name is Window. **2. Follow the inner arrow:** objj.outer() is an ordinary method called on objj. Its returned arrow retains that receiver, so inner() prints Test. **3. Attempt construction:** Arrow functions do not implement the constructor operation, so new arrowFunc() throws TypeError. **Answer: A, B, C, D — A, B, C and D.** **Convention note:** The option’s “strict mode” qualification is imprecise: a top-level arrow in a classic script still captures window even if that script is strict. ES-module top-level this is undefined and would cause the property access to throw. A: **Correct:** The receiver is the object literal, whose constructor name is Object. B: **Correct:** In the stated browser classic-script setting the captured global receiver yields Window. C: **Correct:** The returned arrow retains outer’s receiver objj and reads its name Test. D: **Correct:** An arrow is not constructible, so using new throws TypeError.

**1. Check the three Vue bindings:** v-model synchronizes username, the inline @click assignment sets loggedIn=true, and v-if displays the welcome paragraph when loggedIn is true. **2. Conclude:** With the compiler-inclusive Vue 2 CDN loaded, these are all valid. No listed change is required for the stated behavior. **Answer: D — No change is required.** A: **Incorrect:** Replacing v-model with that v-bind expression would not preserve two-way input binding. B: **Incorrect:** The inline assignment is valid; the replacement also requires defining a missing login method. C: **Incorrect:** v-if already performs the intended conditional rendering. D: **Correct:** The shown code is valid for the requested simple login-display behavior.

**1. Identify the behavior to extract:** The login state change currently appears inline in @click as loggedIn=true. **2. Move it into a method:** Change the handler to @click="login" and define login() { this.loggedIn=true }. This centralizes the action while preserving v-model and the existing conditional display. **Answer: A — Replace the inline click assignment with a login method.** A: **Correct:** It moves the inline login action into a named method. B: **Incorrect:** The existing v-model already supplies the correct input synchronization. C: **Incorrect:** v-else must follow a corresponding v-if and does not take this condition as a replacement. D: **Incorrect:** The code works, but this option does not perform the requested method extraction.

**1. Evaluate the unconditional class:** baseClass is a data expression with value "btn", so btn is included. **2. Evaluate object conditions initially:** isHighlighted=false excludes highlighted; isPrimary=true includes btn-primary; !isEnabled=false excludes btn-disabled. Initial classes are btn and btn-primary. **Answer: B — btn, btn-primary.** A: **Incorrect:** highlighted is excluded because its condition is false. B: **Correct:** It includes exactly the unconditional and true conditional classes. C: **Incorrect:** The expression value btn is used, not the identifier text baseClass. D: **Incorrect:** Both highlighted and btn-disabled initially have false conditions.

**1. Toggle all three booleans once:** isHighlighted becomes true, isPrimary becomes false, and isEnabled becomes false. **2. Re-evaluate class bindings:** baseClass still contributes btn; highlighted is now included; btn-primary is removed; !isEnabled is now true and includes btn-disabled. **Answer: C — btn, highlighted, btn-disabled.** A: **Incorrect:** It omits btn-disabled, whose negated enabled condition is now true. B: **Incorrect:** It omits highlighted, which was toggled true. C: **Correct:** These are exactly the three resulting classes. D: **Incorrect:** The value btn is used rather than the identifier baseClass.