Frontend Architecture (RADIO) — Series 2

Preview — 3 of 10 questions

A large single-page application has some UI state thats genuinely used across many unrelated parts of the app (like the logged-in users info) and some that's only ever relevant to a single small component (like whether a specific dropdown is open). Why does drawing this boundary matter for frontend architecture?

APutting every piece of state, no matter how local or trivial, into one global store is always the best practice with no downsides

BState that's genuinely shared across distant, unrelated parts of the app benefits from living in a global store (accessible from anywhere, single source of truth, but changes can trigger broader re-render/update concerns) — while state that's only relevant to one component or its immediate children is better kept local (simpler to reason about, changes are isolated, no risk of unrelated components accidentally depending on it). Getting this boundary wrong in either direction causes real problems: over-globalizing state creates unnecessary coupling and re-render overhead, while under-globalizing forces awkward prop-drilling or duplicated state to get local data to distant components that need it

CAll application state must always be local to a single component, with global state being an architectural anti-pattern that should never be used under any circumstances

DThe boundary between local and global state has no measurable effect on application performance or maintainability, regardless of how it's drawn

A user clicks like on a post. Instead of waiting for the server to confirm before updating the UI, the app immediately shows the like as applied, then reverts it if the server call actually fails. What's this pattern called, and why use it?

AOptimistic UI updates mean the interface only ever displays optimistic, positive messages to the user regardless of whether an action actually succeeded or failed

BThis pattern requires disabling all network requests entirely, since the UI update itself replaces the need to ever contact the server

COptimistic UI updates guarantee the action will always succeed on the server, eliminating any possibility of failure

DThis is called "optimistic UI updating" — updating the interface immediately based on the expected successful outcome of an action, before the server has actually confirmed it, because for actions that succeed the vast majority of the time, waiting for a full round trip before showing any feedback makes the app feel noticeably slower and less responsive than it needs to; if the server call does fail, the UI is rolled back to its prior state and the user is typically shown an error

A frontend data-fetching library uses a stale-while-revalidate caching strategy for API data. What does this mean, and why might it feel faster to users than always waiting for a fresh network response?

AStale-while-revalidate means the UI immediately shows whatever data is already cached (even if it might be outdated), while simultaneously firing off a background request to fetch fresh data — once that fresh data arrives, the UI updates to reflect it. This makes the app feel instantly responsive on repeat views (no loading spinner for previously-seen data), at the cost of briefly showing data that could be a little stale before the background refresh completes

BStale-while-revalidate means the application refuses to display any data at all until it can absolutely guarantee the data is 100% fresh from the server

CStale-while-revalidate is a server-side-only caching technique with no corresponding client-side/frontend implementation or relevance

DStale-while-revalidate means cached data is kept forever and never refreshed under any circumstances, even in the background

Answer all 10 questions (7 more), see explanations for every answer, and track your score.