Frontend Architecture
Putting it together: code reading
Crux Read four real frontend snippets — global state placement, a fetch waterfall, a lazy import, a token reference — and pick the fix a senior makes first.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitArchitecture is read in code, not slides. Each snippet below is a layer of the track caught in the act of going wrong. Read the code, predict the cost, and pick the fix that targets the layer that actually owns the bug.
Goal
Practise the cross-track diagnosis loop: read a snippet, identify which layer it belongs to (state, fetch, splitting, tokens), and choose the highest-leverage fix instead of one that patches a symptom upward.
Snippet 1 — where the keystroke lives
// global store
const useStore = create((set) => ({
search: "",
setSearch: (v) => set({ search: v }),
}));
function SearchBox() {
const setSearch = useStore((s) => s.setSearch);
return <input onChange={(e) => setSearch(e.target.value)} />;
}
function Dashboard() {
// Chart, Table, Filters, Sidebar all call useStore(...) somewhere
return <><SearchBox /><Chart /><Table /><Sidebar /></>;
} Quiz
Completed
Typing in the search box janks the whole dashboard. From this code, what is the cause and the fix?
Heads-up Selector-based stores re-render only subscribers whose selected slice changed. The jank is real because Chart/Table/Sidebar subscribe to state that shares update notifications with `search` — the cure is to not put per-keystroke state in the shared store at all.
Heads-up memo guards against prop changes, but these components re-render because they subscribe to the store that updates on every keystroke. You would memo-wrap the whole tree and still pay; the fix is moving the state, not memoising every consumer.
Heads-up Debouncing reduces frequency but keeps the keystroke in global state, so typing still feels laggy and the architecture is still wrong. Colocation removes the blast radius entirely; debounce is a patch on a misplaced piece of state.
Snippet 2 — the fetch graph
function ProductPage({ id }) {
const product = useQuery(["product", id], () => fetchProduct(id));
// these two do NOT depend on product, yet they wait for it:
const reviews = useQuery(["reviews", id], () => fetchReviews(id), {
enabled: !!product.data,
});
const related = useQuery(["related", id], () => fetchRelated(id), {
enabled: !!product.data,
});
// ...renders after all three resolve
} Quiz
Completed
Reviews and related products do not depend on the product payload, yet LCP is slow. What is the defect and the fix?
Heads-up The enabled flags are exactly the bug — they create a dependency that does not exist in the data. reviews and related need only `id`, which is available immediately, so gating them on product.data adds two needless sequential round-trips.
Heads-up Caching helps repeat visits but does nothing for the first paint, which is where the waterfall hurts LCP. The structural fix is to parallelise the independent fetches, not to rely on a warm cache.
Heads-up Collapsing hooks is cosmetic; if that single query still awaits product before reviews/related, the waterfall survives. Removing the false dependency — not merging hooks — is what parallelises the trips.
Snippet 3 — the lazy import
import { HeavyChart } from "./HeavyChart"; // pulls in a 400 KB charting lib
function Analytics() {
const [open, setOpen] = useState(false);
return (
<>
<button onClick={() => setOpen(true)}>Show charts</button>
{open && <HeavyChart />}
</>
);
} Quiz
Completed
The 400 KB charting library ships in the initial bundle even though most users never click 'Show charts'. Why, and what is the fix?
Heads-up A conditional render controls when the component mounts, not whether its module is bundled. The static import is evaluated at build time, so the 400 KB ships up front — only a dynamic import() splits it into a separate chunk.
Heads-up Tree-shaking removes provably unused exports, but HeavyChart is used (it is rendered when open), so it cannot be shaken out. Deferring its download requires code-splitting via dynamic import, not tree-shaking.
Heads-up A separate package still gets statically imported into this chunk the same way; the package boundary does not split the bundle. Runtime code-splitting with lazy()/import() is what keeps it out of the initial download.
Snippet 4 — the token reference
/* Button.css */
.btn-danger {
background: #d33; /* brand red, hardcoded */
color: #fff;
}
/* repeated across ~40 components: #d33, #fff, #1a1a1a ... */ Quiz
Completed
Dark mode needs `.btn-danger` to read differently on a dark surface, and a rebrand will change the red. What does this CSS reveal, and what is the structural fix?
Heads-up Per-component dark overrides re-create the hardcoding problem in a second place and scale linearly with components. A semantic token resolved per theme means the component declares intent once and the theme supplies the value.
Heads-up A build-time Sass variable cannot switch at runtime for dark mode the way a CSS custom property can, and it still binds the component to a primitive rather than a semantic role like surface-danger. The fix is a runtime semantic token layer.
Heads-up Using the same hex everywhere is exactly the trap: there is no indirection, so the rebrand is a find-and-replace and dark mode has no switch. The value being consistent does not make it a token; a token carries meaning the theme can remap.
Recap
Four snippets, four layers, one habit: per-keystroke state belongs colocated, not in a global store; an enabled gate on an independent fetch is an artificial waterfall; a static import bundles eagerly while only a dynamic import() splits; and a hardcoded hex is a missing semantic token. In each case the highest-leverage fix lives at the layer that owns the bug — moving the state, removing the false dependency, splitting the chunk, adding the semantic layer — never a patch one layer up.