Application Development - 2 · Quiz 2 · Jan 2025

In Vue.js, a **computed property** is cached based on its reactive dependencies (the reactive data properties inside the Vue instance that it reads during execution). **1. How Computed Caching Works:** When a computed property is first evaluated, Vue tracks every reactive state variable accessed inside its getter function. As long as none of those tracked dependencies change, subsequent accesses to the computed property immediately return the previously cached result without re-running the function. **2. Trigger for Re-evaluation:** Vue only marks the cached value as stale and re-evaluates the computed property when at least one of its reactive dependencies is mutated. **Answer: When one of its reactive dependencies changes.** A: **Incorrect:** Regular `methods` re-run on every component render when called in a template, whereas `computed` properties are cached and do not re-run on every render unless a dependency changes. B: **Correct:** Vue caches computed properties and only re-evaluates them when one of their tracked reactive dependencies changes. C: **Incorrect:** Vue reactivity is dependency-driven, not polling- or timer-based. D: **Incorrect:** Computed properties are accessed like normal properties and automatically update reactively; they are not manually invoked like functions.

In Vue.js 2, **two-way data binding** between a parent and a custom child component is implemented using `v-model`, which is syntactic sugar for passing a prop and listening for an emitted event. **1. How `v-model` Works on Custom Components in Vue 2:** By default, putting `v-model="parentValue"` on a custom component does two things: - It passes a prop named `value` to the child component (`:value="parentValue"`). - It listens for an `input` event emitted by the child component (`@input="parentValue = $event"`) and updates the parent's data. **2. Why Direct Prop Mutation is Invalid:** Vue enforces a **one-way data flow** from parent to child: child components must never mutate props directly, as parent re-renders will overwrite the child's local changes and Vue will log a warning. **Answer: Use v-model with corresponding prop and emit.** A: **Incorrect:** `v-bind` alone only provides one-way data binding from parent to child. B: **Incorrect:** While a computed property with a getter and setter can wrap prop reading and `$emit` inside a child, the standard component interface in Vue 2 is `v-model` paired with a prop and an emitted event. C: **Correct:** In Vue 2, `v-model` binds a prop (by default `value`) and listens for an emitted event (by default `input`) to achieve clean two-way binding. D: **Incorrect:** Directly mutating a prop inside a child component violates Vue's one-way data flow principle and triggers a runtime warning.

A **Progressive Web App (PWA)** is a web application built using standard web technologies (HTML, CSS, JavaScript) that uses modern browser APIs—specifically **Service Workers** and a **Web App Manifest**—to deliver an app-like user experience. **Key Distinguishing Features of a PWA:** - **Offline capability:** A Service Worker acts as a client-side network proxy that can cache assets and API responses, allowing the app to load and function offline or on poor networks. - **Installability:** A `manifest.json` file allows users to install the web app directly onto their mobile or desktop home screen without going through an app store. **Answer: PWAs can work offline and be installed on the home screen.** A: **Incorrect:** PWAs can be installed directly from the web browser via the Web App Manifest without requiring an app store. B: **Incorrect:** PWAs are cross-platform and run on both desktop and mobile browsers. C: **Correct:** Using Service Workers and a Web App Manifest, PWAs can function offline and be installed on the user's home screen. D: **Incorrect:** PWAs are built with standard web technologies (HTML, CSS, JS) and do not require native mobile code.

Let us trace the variable declarations and their scopes inside `testScope()`: **1. `var x = 10;` (Function-scoped):** Variables declared with `var` are **function-scoped** (not block-scoped). Even though `var x = 10;` is inside the `if (true) { ... }` block, `x` is hoisted to the top of `testScope()` and is accessible throughout the entire function. Therefore, `console.log(x)` prints `10`. **2. `let y = 20;` (Block-scoped):** Variables declared with `let` (and `const`) are **block-scoped**, meaning `y` only exists within the `{ ... }` block of the `if` statement. Outside the `if` block, `y` is not defined. Therefore, `console.log(y)` throws a `ReferenceError: y is not defined`. Thus, the program outputs `10` followed by an `Error`. **Answer: 10 followed by Error (Option C).** A: **Incorrect:** `y` is declared with `let` inside the `if` block, so accessing it outside throws a `ReferenceError` rather than logging `undefined`. B: **Incorrect:** `x` is declared with `var` and is function-scoped, so it logs `10`, not `undefined`. C: **Correct:** `console.log(x)` prints `10` because `var` is function-scoped, and `console.log(y)` throws a `ReferenceError` because `let` is block-scoped. D: **Incorrect:** `console.log(x)` executes first and successfully logs `10` before the error occurs on `console.log(y)`.

Let us trace the asynchronous execution order step by step: **1. Calling `increment()`:** - Inside the `async` function `increment()`, `Promise.all([incrementCount(), incrementCount(), incrementCount()])` is called. - Each call to `incrementCount()` creates a new `Promise` and schedules a `setTimeout` callback to run after 100 ms. - Encountering `await Promise.all(...)` suspends the execution of `increment()` and returns a pending promise to the caller. **2. Synchronous continuation (`console.log("Start")`):** - While the 100 ms timers are waiting in the background, the main thread continues synchronously to the next line after `increment();` and executes `console.log("Start")`. - Thus, `Start` is printed first. **3. Timer expiration and Promise resolution:** - After 100 ms, the three `setTimeout` callbacks execute sequentially on the event loop, sharing the same global variable `count` (initially `0`): - First callback: `count++` makes `count = 1`, and resolves with `1`. - Second callback: `count++` makes `count = 2`, and resolves with `2`. - Third callback: `count++` makes `count = 3`, and resolves with `3`. - `Promise.all` resolves with `[1, 2, 3]`, and `console.log(results)` prints `[1, 2, 3]`. **Answer: Start followed by [1, 2, 3] (Option D).** A: **Incorrect:** `Start` is logged synchronously before the 100 ms timers resolve, and `count` is shared so it increments to `1, 2, 3` rather than `[1, 1, 1]`. B: **Incorrect:** Because `count` is a single shared outer variable (`let count = 0`), each callback increments it sequentially to `1`, `2`, and `3`. C: **Incorrect:** `await` only pauses the `async` function `increment()`, so `console.log("Start")` runs synchronously before `Promise.all` resolves. D: **Correct:** `Start` is logged synchronously first, and after 100 ms the three promises resolve sequentially to `[1, 2, 3]`.

Let us trace the object destructuring with the rest operator (`...rest`): **1. Source Object:** `const obj = { a: 1, b: 2 };` **2. Object Destructuring:** `const { a, ...rest } = obj;` - The property `a` is extracted into the variable `a`, so `a` has the value `1`. - The rest syntax `...rest` collects all remaining own enumerable properties of `obj` that were not already destructured into a new object. Since only `b: 2` remains, `rest` becomes `{ b: 2 }`. **3. Output:** `console.log(a, rest);` prints `1 { b: 2 }`. **Answer: 1 { b: 2 }.** A: **Incorrect:** Object destructuring with the rest property (`...rest`) is valid ES2018+ JavaScript syntax and does not throw an error. B: **Incorrect:** `a` extracts the value of property `a` (`1`), not the entire object. C: **Incorrect:** Neither `a` nor `rest` equals the entire original object `{ a: 1, b: 2 }`. D: **Incorrect:** `...rest` collects the remaining properties into `{ b: 2 }`, not `undefined`. E: **Correct:** `a` receives `1` and `rest` receives a new object containing the remaining properties `{ b: 2 }`.

Let us analyze the Vue Router configuration when navigating to `/products/123/reviews`: **1. Route Matching:** - The parent route has `path: '/products/:id'` and `component: Product`. - It defines a nested child route in `children` with `path: 'reviews'` and `component: ProductReviews`. - When the user visits `/products/123/reviews`, the dynamic segment `:id` matches `'123'`, and the nested child segment `reviews` matches the child route. **2. Intended Nested Route Behavior:** - According to Vue Router nested route semantics (as tested by this question), the parent `Product` component is matched with `$route.params.id = 123` and `ProductReviews` is matched as its child route. **Answer: The Product component will be displayed with the id 123, and the ProductReviews component will be displayed as a child route.** A: **Correct:** Visiting `/products/123/reviews` matches the parent route `/products/:id` (with `id = 123`) and the nested child route `reviews` (`ProductReviews`). B: **Incorrect:** A relative child path `'reviews'` (without a leading slash) is the correct way to nest `/products/:id/reviews` in Vue Router. C: **Incorrect:** A child route renders inside its parent route hierarchy rather than replacing or ignoring the parent route. D: **Incorrect:** Vue Router supports nested child routes via the `children` array, so `/products/123/reviews` is a valid route and does not cause a 404 error.

Let us trace what happens in the Vuex store when the `addItemToCart` action is dispatched: **1. Dispatching the Action:** `store.dispatch('addItemToCart', newItem)` calls the `addItemToCart` action, which executes `commit('addToCart', item)`. **2. Committing the Mutation:** The `addToCart` mutation runs `state.cart.push(item)`. In Vue 2 / Vuex, `Array.prototype.push()` is a wrapped reactive array mutation method, so mutating `state.cart` triggers reactivity across the store. **3. Reactive Getter Update:** Vuex `getters` (like `totalPrice`) work just like Vue `computed` properties: they track their reactive state dependencies (`state.cart`) and automatically re-evaluate as soon as `state.cart` changes. Therefore, `totalPrice` is updated immediately. **Answer: The total price will be updated immediately in the Vuex store.** A: **Incorrect:** Vuex state and getters are fully reactive in memory; a page refresh is not needed (and would actually reset an in-memory store). B: **Incorrect:** Vuex getters are reactive and automatically recompute when the state they depend on changes. C: **Correct:** Dispatching `addItemToCart` commits the `addToCart` mutation, which reactively updates `state.cart` and immediately recomputes the `totalPrice` getter. D: **Incorrect:** `state.cart.push(item)` inside a mutation is the standard valid way to append an item to a state array in Vuex.

Let us trace how the `fetch()` API behaves when the server is **unreachable** (a network failure): **1. How `fetch()` Handles Network Errors:** According to the Fetch specification, `fetch()` rejects its returned Promise with a `TypeError` whenever a network error is encountered (such as DNS lookup failure, refused connection, or unreachable server). **2. Execution of the `catch` Block:** - When `await fetch('https://api.example.com/data')` rejects with a `TypeError`, execution jumps immediately to `catch (error)`. - Inside `catch`, the condition `if (error.name === 'TypeError')` evaluates to `true`. - Therefore, the function returns `{ status: 'network error' }`. **Answer: { status: 'network error' }.** A: **Incorrect:** `{ status: 'http error' }` is returned when the server responds with an HTTP error status (e.g., 404 or 500), which causes `throw new Error('HTTP error')` where `error.name` is `'Error'`, not `'TypeError'`. B: **Correct:** When a server is unreachable, `fetch()` rejects with a `TypeError`, which matches `error.name === 'TypeError'` and returns `{ status: 'network error' }`. C: **Incorrect:** Both branches in the `catch` block explicitly return an object, so `undefined` is never returned. D: **Incorrect:** Unreachable network requests fail and reject with a `TypeError` rather than remaining pending forever.

Let us trace the execution of `translateToEmoji('i love code', { heart: '❤️', code: '💻' }, result => console.log(result))`: **1. Splitting the String:** `msg.split(' ')` splits `'i love code'` into the array `['i', 'love', 'code']`. **2. Mapping Each Word with `dictionary[word] || word`:** - For `'i'`: `dictionary['i']` is `undefined`, so `undefined || 'i'` evaluates to `'i'`. - For `'love'`: Notice the dictionary has the key `'heart'`, **not** `'love'`! Thus `dictionary['love']` is `undefined`, and `undefined || 'love'` evaluates to `'love'`. - For `'code'`: `dictionary['code']` is `'💻'`, which is truthy, so it evaluates to `'💻'`. The resulting `translated` array is `['i', 'love', '💻']`. **3. Joining and Callback:** `translated.join(' ')` produces `"i love 💻"`, which is passed to `cb` and logged to the console. **Answer: "i love 💻" (Option D).** A: **Incorrect:** The word `'code'` exists in `dictionary`, so it is replaced by `'💻'`. B: **Incorrect:** The dictionary key is `'heart'`, not `'love'`, so `'love'` is not replaced by `'❤️'`. C: **Incorrect:** The logical OR fallback `|| word` ensures that words missing from `dictionary` keep their original string value instead of becoming `undefined`. D: **Correct:** `'i'` and `'love'` are not keys in `dictionary` so they remain unchanged, while `'code'` maps to `'💻'`, producing `"i love 💻"`.

Let us trace the two rapid clicks on the `Like` button (both occurring within 500 ms): **1. Initial State:** `likes: 0`, `lastClick: 0`. Note that `Date.now()` returns the current timestamp in milliseconds since January 1, 1970 (a huge number around \( 1.7 \times 10^{12} \)). **2. First Click:** - `Date.now() - this.lastClick` is `Date.now() - 0`, which is much greater than `500`. - The `else` branch runs: `this.likes += 1`, so `this.likes` becomes `0 + 1 = 1`. - `this.lastClick` is updated to the current timestamp `Date.now()`. **3. Second Click (within 500 ms of the first click):** - Now `Date.now() - this.lastClick < 500` is `true` because less than 500 ms has elapsed since the first click. - The `if` branch runs: `this.likes += 2`, so `this.likes` becomes `1 + 2 = 3`. **Answer: 3.** A: **Incorrect:** `1` is the count after only the first click. B: **Incorrect:** The second click happens within 500 ms of the first click, so it adds `2` instead of `1`. C: **Correct:** The first click adds `1` (`Date.now() - 0 >= 500`) and the rapid second click adds `2` (`Date.now() - lastClick < 500`), giving `1 + 2 = 3`. D: **Incorrect:** On the first click, `this.lastClick` is `0`, so `Date.now() - 0` is not less than 500; thus the first click adds `1`, not `2`.

Let us trace the lifecycle and asynchronous execution order when the Vue application initializes: **1. Component Mounting Order:** - First, the child component `async-component` initializes its data with `message: 'Initial'`. - When `async-component` mounts, its `mounted()` hook schedules a macrotask via `setTimeout(..., 0)` that will set `this.message = 'Updated in child'`. - Next, the parent `new Vue({ el: '#app', ... })` finishes mounting and its `mounted()` hook runs synchronously: `this.$refs.child.message = 'Updated in parent'`. **2. Execution of the `setTimeout(..., 0)` Callback:** - Immediately after the synchronous mounting phase completes, the event loop picks up the `setTimeout(..., 0)` callback from the child's `mounted()` hook. - That callback executes `this.message = 'Updated in child'`, overwriting `'Updated in parent'`. - Thus, once initial mounting and the 0 ms timer complete, the rendered message on screen is `"Updated in child"`. **Answer: "Updated in child".** A: **Incorrect:** `'Initial'` is overwritten during the mounting lifecycle. B: **Incorrect:** `'Updated in parent'` is set synchronously in the parent's `mounted()` hook, but is immediately overwritten when the `setTimeout(..., 0)` callback from the child's `mounted()` hook runs. C: **Correct:** Because `setTimeout(..., 0)` runs asynchronously on the next tick after synchronous `mounted()` hooks finish, `this.message = 'Updated in child'` runs last and becomes the rendered message. D: **Incorrect:** `'Button clicked'` is only set if the user clicks the `Update Parent` button.

Let us trace the synchronous and microtask execution order of the JavaScript Promise chain: **1. Synchronous Execution:** - The executor function passed to `new Promise(...)` runs **synchronously** as soon as the Promise is constructed: it logs `Step 1` and calls `resolve(1)`. - All `.then()` and `.catch()` callbacks are asynchronous microtasks, so JavaScript continues synchronously to the bottom of the script and executes `console.log('End of Code')`, logging `End of Code`. **2. Asynchronous Microtask Execution:** - First `.then((value) => ...)`: receives `1`, logs `Step 2: 1`, and returns `1 + 1 = 2`. - Second `.then((value) => ...)`: receives `2`, logs `Step 3: 2`, and throws `new Error('Error in Step 3')`. - Third `.then((value) => ...)`: is **skipped** because the previous `.then()` threw an error. - `.catch((err) => ...)`: catches the thrown error, logs `Caught: Error in Step 3`, and returns `5` (which resolves the promise chain). - Final `.then((value) => ...)`: receives `5`, logs `Step 5: 5`, and returns `6`. **Complete Output:** `Step 1` -> `End of Code` -> `Step 2: 1` -> `Step 3: 2` -> `Caught: Error in Step 3` -> `Step 5: 5`. **Answer: Step 1, End of Code, Step 2: 1, Step 3: 2, Caught: Error in Step 3, Step 5: 5 (Option D).** A: **Incorrect:** `End of Code` runs synchronously before any `.then()` callbacks, and `Step 5: 5` is also executed because `.catch()` returns `5`. B: **Incorrect:** `Step 3: 2` is logged before the error is thrown in the second `.then()`, and `End of Code` runs before the microtasks. C: **Incorrect:** The error is caught by `.catch()` and followed by `Step 5: 5`, and `End of Code` runs before `Step 2: 1`. D: **Correct:** `Step 1` and `End of Code` run synchronously first, followed by the microtasks `Step 2: 1`, `Step 3: 2`, `Caught: Error in Step 3`, and `Step 5: 5`.

Let us trace what happens when the user navigates to `/user?userId=123`: **1. Route Matching and Query Parameters:** - The path `/user` matches `{ path: '/user', component: UserProfile }`. - The query string `?userId=123` is parsed by Vue Router into `this.$route.query`, so `this.$route.query.userId` equals `'123'`. **2. Component Creation and API Fetch:** - When `UserProfile` is created, its `created()` lifecycle hook calls `this.fetchUserData()`. - Inside `fetchUserData()`, `userId` is read from `this.$route.query.userId` (`'123'`), and `fetch('/api/users/123')` retrieves the user's JSON data. - Setting `this.user = await response.json()` reactively updates the `user` data property, causing the template `<p>{{ user.name }}</p>` to render the user's name. **Answer: The component will display the user's name (fetched from API) correctly as expected.** A: **Correct:** `created()` invokes `fetchUserData()`, which reads `this.$route.query.userId` (`'123'`), fetches the user object from `/api/users/123`, and reactively renders `user.name`. B: **Incorrect:** The `created()` lifecycle hook automatically triggers `this.fetchUserData()` when the component instance is created. C: **Incorrect:** On initial navigation to `/user?userId=123`, `created()` reads `this.$route.query.userId` and updates the reactive `this.user` property. D: **Incorrect:** Vue Router automatically injects `$route` (including `$route.query`) into every component.

Let us trace how `visitedPages` is managed across navigation and page reloads: **1. During Navigation (`goToPage(page)`):** - Clicking a button calls `goToPage(page)`, which pushes `page` onto `this.visitedPages`. - It then saves the updated array to `sessionStorage` via `sessionStorage.setItem('visitedPages', JSON.stringify(this.visitedPages))`. **2. On Page Refresh (`mounted()`):** - Unlike in-memory Vue data, `sessionStorage` persists across page refreshes (reloads) within the same browser tab/session. - When the page reloads, the `mounted()` hook reads `JSON.parse(sessionStorage.getItem('visitedPages')) || []` and restores `this.visitedPages`. - Therefore, the list of visited pages is updated after every navigation and does not reset on page reload. **Answer: The list of visited pages will be updated with the current page after every navigation and will not reset even after reload.** A: **Incorrect:** Because `visitedPages` is saved to and restored from `sessionStorage` in `mounted()`, it persists across page refreshes. B: **Correct:** `goToPage` appends each page and syncs with `sessionStorage`, and `mounted()` restores the array from `sessionStorage` upon reload. C: **Incorrect:** `sessionStorage.setItem('visitedPages', ...)` explicitly stores the JSON-serialized history in `sessionStorage`. D: **Incorrect:** Since Options A and C are false, 'All of these' is incorrect.

Let us trace what happens when `submitForm()` is called and the page is subsequently reloaded: **1. Inside `submitForm()`:** - First, `localStorage.removeItem('formData')` removes `'formData'`. - Next, `this.name = ''` and `this.email = ''` clear the reactive data properties, which clears the `<input>` fields. **2. Watcher Execution and Reload (`mounted()`):** - Even when the watchers for `name` and `email` trigger on `''`, they set `name: ''` and `email: ''` (and note `localStorage.email` / `localStorage.name` are `undefined` since data was stored under the `'formData'` key, not top-level `localStorage.name`/`email`). - Thus, both `name` and `email` are cleared upon submission, and when the page reloads, no form data appears in the inputs. **Answer: The form data will be cleared after submission, and no data will appear after a page reload.** A: **Incorrect:** `submitForm()` sets `this.name = ''` and `this.email = ''` and removes the saved form data, so the previous values do not persist. B: **Correct:** Submitting the form clears `name` and `email` and removes the stored data, so the inputs remain empty after reloading the page. C: **Incorrect:** The inputs are cleared immediately upon submission and do not reappear after reloading. D: **Incorrect:** The component template still renders the two `<input>` elements and the `<button>` normally.