Frontend architecture that lasts

10 questions drawn from the parts of this series. Answers here count toward each post's own quiz.

1. Question 1 of 10·IntermediateThe list page fetches users, the detail page fetches that same user again, and the header fetches the current user once more. What is the core problem with this design and the fix?

   Too many requests, so merge them with a global store holding all usersState is duplicated across pages so the copies drift apart; identify the source of truth first and let screens be cheap projections of itEach page should manage its own data to stay independentIt is only a performance problem, solved by adding loading skeletons
2. Question 2 of 10·IntermediateWhere should a list filter, the text currently being typed in a field, and the order list fetched from an API live?

   All three in a global store for easy accessFilter in local state, typed text in the URL, order list in a global storeFilter in a global store, typed text in local state, order list in the URLFilter in the URL, typed text in local state, order list in a query cache (server state)
3. Question 3 of 10·StarterA component uses three flags: isLoading, isError and data. What is the core problem with this approach?

   Three state variables make the component render slower.The number of combinations doubles with each added flag, producing many nonsensical states the code still allows, like having data and a stale error at once.React does not allow more than two state variables in a component.Boolean flags cannot be used in conditional JSX.
4. Question 4 of 10·IntermediateIn the post's approach the reducer never calls an API. Where does the request run, and why is this design sound?

   In an effect reacting to the submitting state, with cleanup aborting the request when leaving it; the reducer is pure so tests just call reducer(state, event).Inside the reducer itself, since it is the only place that knows about events.In the JSX, so rendering and requests stay in sync.In a global variable, to avoid depending on React.
5. Question 5 of 10·IntermediateWhich of the following errors is NOT caught by a React error boundary?

   A child component throwing while renderingAn error thrown in a child component's constructorAn error in an onClick event handler, because it does not run during renderingAn error in a child component's lifecycle method
6. Question 6 of 10·IntermediateWhy does retry need jitter (randomness) on top of exponential backoff?

   So that when the server recovers, thousands of clients do not retry at the same moment and knock it over againSo that the total waiting time is shorter than with pure backoffSo that the browser does not block repeated requestsSo that each client gets a different maximum number of retries
7. Question 7 of 10·StarterWhat is the core difference between optimistic UI and offline-first?

   Optimistic UI uses IndexedDB while offline-first only uses in-memory stateOptimistic UI updates the UI immediately but keeps changes in memory, so closing the tab mid-flight loses them; offline-first persists locally first and then syncsOffline-first differs only in not showing a spinnerOptimistic UI solves losing connectivity, while offline-first only solves perceived slowness
8. Question 8 of 10·IntermediateWhy does each outbox mutation need an idempotency key when retrying?

   Because a request may already have been processed by the server while the response was lost; resending with the same key makes the server return the stored result instead of applying it twiceBecause the key lets the server order mutations chronologicallyBecause the key replaces the version number for detecting conflictsBecause the browser resends requests by itself and the key blocks that
9. Question 9 of 10·IntermediateThe rule "Pro customers see advanced reports" is permanent. How does the post say to handle it?

   Use a release flag, since that is the fastest way to enable a feature for a customer groupUse an experiment flag to measure whether Pro really needs that reportTreat it as business logic that lives in the authorization system, and check access on the server; hiding a button in the frontend is not securityUse an ops flag so on-call can turn it off quickly
10. Question 10 of 10·IntermediateIn the Next.js App Router, why evaluate flags once on the server and bootstrap them to the client through a provider?

    The HTML arrives in the right variant from the start and the client's first render uses the same values, so there is no flicker or hydration mismatch and no second requestBecause a client-side flag SDK is always a second slower than the serverBecause server evaluation makes the whole page easier to cache at the CDNBecause the client must not know flag values for security reasons