Application Development - 2 · Quiz 2 · May 2025

**1. Identify the body format:** JSON.stringify(data) serializes the object as JSON text. To tell the receiving endpoint to interpret that request body as JSON, set the request header Content-Type to application/json. **2. Distinguish content type from accepted response type:** Accept describes which response formats the client can receive; it does not label the format of the submitted body. Multipart form-data also has a different body structure and requires boundaries. **Answer: A — Content-Type: application/json.** **Convention note:** This is the required content-description header for an endpoint expecting JSON. The header alone does not guarantee success: authentication, CORS rules, payload validation and server behavior can still matter. A: **Correct:** application/json matches the serialized JSON request body. B: **Incorrect:** Multipart form-data does not match the JSON.stringify body and normally requires a multipart boundary. C: **Incorrect:** application/text is not the correct media type for the JSON body. D: **Incorrect:** Accept: */* concerns the response and does not identify the request body as JSON.

**1. Identify the file format:** A .vue Single-File Component typically groups template markup, JavaScript logic and component styling into template, script and style sections. It is not directly a normal JavaScript source file. **2. Explain the build requirement:** Browsers do not natively parse the .vue SFC format. A tool such as Vue’s compiler with a bundler, Vue CLI or Vite transforms it into executable JavaScript and CSS before the component can run. **3. Distinguish a compiled component from a direct file load:** Loading an unprocessed .vue file in an ordinary script element does not perform that compilation. Likewise, an ordinary JavaScript import alone does not give browsers native SFC support. **Answer: B, C — B and C.** **Convention note:** A specialized in-browser loader/compiler can perform preprocessing at runtime, but it is additional tooling, not native browser execution “without preprocessing.” A: **Incorrect:** Browsers cannot directly parse and execute unprocessed Vue SFC syntax. B: **Correct:** These are the typical SFC sections. C: **Correct:** The SFC must be transformed/compiled before normal browser execution, commonly by the named build tools. D: **Incorrect:** A plain script element does not compile a .vue file into JavaScript.

**1. Compare persistence scopes:** localStorage persists data for an origin across ordinary browser closures without an application-specified expiration time. sessionStorage is scoped to an origin within a particular top-level tab/page session and normally ends when that session closes. **2. Compare storage format:** Both use string keys and string values. Structured objects can be stored by JSON serialization and recovered by parsing. Both therefore support the key–value description in C. **3. Distinguish tabs:** Independent tabs do not share a single live sessionStorage area merely because they use the same origin. A newly opened tab can sometimes begin with a copy from its opener, but later mutations are not shared. **Answer: A, B, C — A, B and C.** **Convention note:** Persistence is subject to user clearing, browser privacy/eviction policies and private-browsing behavior. “No expiration date” describes the API’s normal model, not an absolute guarantee that data can never disappear. A: **Correct:** Ordinary localStorage has no automatic expiration timestamp and persists across normal browser restarts. B: **Correct:** sessionStorage belongs to the page/tab session and survives reloads within that session. C: **Correct:** Both Storage objects provide key–value storage of strings. D: **Incorrect:** sessionStorage is isolated by tab/top-level browsing context rather than shared across all tabs.

**1. Explain SPA navigation:** Client-side routing updates the displayed view inside the current document rather than requiring a complete page navigation for every in-app route. A server-side routing language is not mandatory for that behavior. **2. Explain PWA capabilities:** A service worker can intercept requests and provide cached responses, enabling designed offline behavior. Supported browsers can also install a suitably configured web app to the home screen. **3. Keep capability separate from guarantee:** Not every page of every PWA automatically works offline, but the claim says “can,” which is correct when the application implements the required caching and installation support. **Answer: A, B, D — A, B and D.** A: **Correct:** Client routing is the standard way a multi-view SPA navigates without full reloads. B: **Correct:** Service-worker caching can enable offline operation. C: **Incorrect:** Static hosting with client routing can support an SPA; a server-side language is not always needed. D: **Correct:** Installable PWAs can be launched from a device’s home screen like applications.

**1. Follow the response method actually called:** The promise chain invokes res.json(), not res.meta(). Therefore the data are Alpha=40,Beta=30,Charlie=50 and Delta with no score. **2. Trace map and filter:** parseInt(p.score)||0 produces [40,30,50,0]. The missing Delta score parses to NaN and falls back to 0. Filtering score>=40 leaves [40,50]. **3. Reduce the surviving values:** Starting from accumulator 0, the sum becomes 40 and then 90. The logged output is Total Score: 90. The unused meta data do not contribute. **Answer: B — Total Score: 90.** A: **Incorrect:** The retained score values sum to 90, not 80. B: **Correct:** 40 and 50 pass the threshold and sum to 90. C: **Incorrect:** 120 is the total before filtering out Beta’s 30. D: **Incorrect:** The ||0 fallback replaces the missing-score NaN with zero before the sum.

**1. Wait for each returned promise in sequence:** The initial promise resolves after about 2 seconds with The cat sleeps, which the first handler logs. That handler returns a second promise, delaying the next handler by another second. **2. Follow the next two messages:** The second promise resolves with Rain falls gently. Its handler logs that and returns a third promise, which resolves after another 1.5 seconds with Books gather dust. The next handler logs that message. **3. Propagate the thrown error:** That same handler then throws Error("Coffee grows cold"). The promise becomes rejected and skips the following success handler that would print Stars shine bright. The catch logs Caught: Coffee grows cold. **4. Preserve the output order:** The four lines are The cat sleeps; Rain falls gently; Books gather dust; Caught: Coffee grows cold. They occur after nominal cumulative delays around 2,3,4.5,4.5 seconds, with actual scheduling potentially later. **Answer: B — The cat sleeps; Rain falls gently; Books gather dust; Caught: Coffee grows cold.** A: **Incorrect:** The thrown error skips the Stars success handler and is handled by catch. B: **Correct:** This includes all three preceding messages and the final caught-error message. C: **Incorrect:** Books gather dust is logged before the error is thrown, so it is not omitted. D: **Incorrect:** The error is caught after earlier successful messages have already printed. E: **Incorrect:** The success handler after the throw is skipped; Stars shine bright cannot follow it.

**1. Inspect beforeCreate timing:** Vue 2 invokes beforeCreate before initializing reactive data proxies. this.phase and this.counter are not yet the declared data values, and this.items is undefined. The attempt to call this.items.push("A") throws a TypeError inside that lifecycle hook. **2. Account for Vue’s error handling and data initialization:** Vue catches/reports lifecycle-hook errors and continues initialization. The data object then supplies phase="", counter=0 and items=[]. Temporary assignments made before data initialization are not the final reactive state. **3. Apply the later hooks:** created adds Ready-, changes counter to 3 and pushes B. beforeMount adds Prep-, changes counter to 1 and pushes C. mounted adds Live, doubles counter to 2 and pushes D. **4. Read the updated UI:** After Vue’s pending DOM update, phase is Ready-Prep-Live, counter is 2 and items.length is 3. A console error from beforeCreate can coexist with this rendered result. **Answer: B — Phase: Ready-Prep-Live; Counter: 2; Items: 3.** **Convention note:** This uses Vue 2’s normal lifecycle-hook error handling and the settled DOM after mounted’s reactive changes. The beforeCreate hook is not a safe place to mutate declared data. The source output can still appear despite the reported hook TypeError. A: **Incorrect:** The beforeCreate operations do not successfully contribute Init-, 5 or A to the initialized reactive data. B: **Correct:** The later hooks produce Ready-Prep-Live, counter 2 and three items B,C,D. C: **Incorrect:** created still runs, so its Ready- text and B item are not missing. D: **Incorrect:** created and beforeMount both run before mounted, so their contributions remain. E: **Incorrect:** The counter is (0+3−2)×2=2, not 12.

**1. Use history-mode path matching:** The registered product route is /inventory/:productId, and the catch-all route displays Item not found in inventory!. In history mode, the router matches the URL pathname, not a hash-style /#/... route. **2. Resolve the valid item:** /inventory/101 matches the product route and finds Canvas with quantity 15 and warehouse count 3, producing Canvas - 15 units stored in 3 locations. **3. Resolve unmatched paths:** /inventory lacks the required productId, and /products/101 uses an unregistered prefix. Both match the catch-all route, so C and E are correct. The hash-style URL in B has pathname / and also falls to the catch-all, rather than finding Brushes. **4. Distinguish missing data from missing routes:** /inventory/103 does match /inventory/:productId, but inventory[103] is undefined. The template then attempts item.product and raises a render error; the router does not automatically switch to its catch-all component for an unknown data key. **Answer: A, C, E — A, C and E.** **Convention note:** History-mode direct loads require the host server to serve the SPA entry page for its routes. As in the question, this solution assumes that hosting requirement is satisfied and describes the client router’s behavior. A: **Correct:** The route matches and the 101 record supplies Canvas,15,3. B: **Incorrect:** History mode does not interpret the fragment as the route pathname; the pathname is / here. C: **Correct:** The missing parameter prevents a match to the product route and activates the catch-all. D: **Incorrect:** The route matches structurally but its undefined data cause a render error, not the stated catch-all message. E: **Correct:** The products prefix is not registered, so the catch-all renders the error page.

**1. Identify the router mode and route paths:** Vue Router 3 defaults to hash mode here. The declared parent is /dashboard, with child paths stats and settings, making /dashboard/stats and /dashboard/settings valid. **2. Check the first URL exactly:** #/dashboard/unknown has no registered child named unknown. No partial parent-only match is selected for this unknown full path, so the catch-all renders 404 Not Found. **3. Check the spelling of the second URL:** It is #/dashboards/stats, with dashboards in the plural. That is different from the singular registered parent /dashboard, so it also hits the catch-all. **4. Distinguish the nearby valid URL:** #/dashboard/stats would display Dashboard containing the nested Stats Component. That is not the second URL printed in the question. **Answer: D — both show 404 Not Found.** A: **Incorrect:** Neither exact URL matches the declared parent/child route records. B: **Incorrect:** The first unknown-child URL also activates the catch-all. C: **Incorrect:** The first is unknown, and the second uses the plural dashboards prefix, so neither claimed output is correct. D: **Correct:** Both exact URLs fail route matching and render the catch-all component.

**1. Update the loading state when clicked:** On the Home route, fetchData immediately sets loading=true. At Vue’s next DOM update, the v-if loading paragraph appears and the v-show=!loading message paragraph is hidden. **2. Await the simulated API:** simulateApiCall returns a promise resolved by a timer after about 1000 ms. The existing use of await with a returned .then chain still waits for that asynchronous result. **3. Apply the completed result:** The handler assigns message="Fetched Data from API!" and loading=false. Vue removes the loading paragraph and displays the message paragraph. Thus Loading data... is shown for roughly one second before the fetched message. **Answer: B — Loading data... for about one second, then Fetched Data from API!.** A: **Incorrect:** The timer deliberately delays the result by about one second. B: **Correct:** The loading flag shows the loading text until the asynchronous result is applied. C: **Incorrect:** The two visibility conditions are complementary, so both are not displayed together in the normal settled state. D: **Incorrect:** v-if and v-show can be used on separate elements in the same template.

**1. Locate the race:** While one call is pending, the Fetch button remains enabled. Rapid clicks can start multiple promises, each later assigning message and loading, so an earlier completion can hide loading while another call is still pending. **2. Prevent additional UI-triggered calls:** Bind the button’s disabled property to loading. With disabled=true during the pending operation, the normal user cannot start another request through that button until the first completes. **3. Distinguish syntax cleanup from concurrency control:** Replacing await-plus-then with a simpler await can improve readability but does not itself prevent overlapping calls. Replacing visibility directives also does not stop extra fetches. **4. Strengthen a production implementation:** Add an early if(this.loading) return guard in the method for programmatic/reentrant calls, and reset loading in finally so rejection does not permanently disable the control. The listed option implementing the essential button lock is C. **Answer: C — disable the Fetch button while loading is true.** **Convention note:** Vue batches DOM updates, so a method-level loading guard is a useful additional defense against calls before the disabled property is patched. Error handling with finally is also needed when a real request can reject. A: **Incorrect:** Changing conditional rendering does not prevent multiple invocations of fetchData. B: **Incorrect:** A simpler await expression alone still lets repeated clicks start concurrent requests. C: **Correct:** A disabled binding blocks normal additional button clicks while loading is true. D: **Incorrect:** v-html changes how content is rendered and does not manage asynchronous calls.