Which responsibility belongs in a Container component?

Container components handle data fetching, state management, and business logic. Presenters render UI based on props

Why is the Container/Presenter split beneficial for testing?

Presenters are pure functions of props, so testing is straightforward with different prop values

A design team wants to modify button colors and spacing in a form. Which component should they edit?

Presenter components contain all UI/styling logic, so designers can safely modify them without affecting logic

What does it mean if a Presenter component imports `useState` or `useEffect`?

Presenters should be pure—if they have hooks for state/effects, they are handling logic and should be refactored

How should a Presenter component communicate changes back to its parent?

Presenters are read-only receivers of props. Logic flows up only through callback props from Container

When should you use React Context instead of a global store like Zustand?

Context is optimal for stable, infrequent-update values like theme/auth. It causes all consumers to re-render on change

What is the main performance drawback of using React Context for high-frequency updates?

Context has no granular subscription mechanism, so any change triggers all consumers to re-render

Which store library requires NO Provider component wrapper in your app root?

Zustand stores are accessed directly via hooks without needing a Provider component wrapping the tree

What does React Query's automatic cache invalidation solve?

React Query tracks mutations and can auto-refetch related queries, keeping UI in sync with server

Why is Redux Toolkit better for large enterprise apps than Zustand?

Redux enforces predictable patterns and has mature debugging tools, valuable when many developers touch state

What is the key difference between client state and server state in React Query?

React Query specializes in server state (fetching, caching, sync). Use Zustand/Context for pure UI state

Two sibling components need to share a piece of state. Where should the state live?

Lifting state to the parent allows both siblings to access and update the shared state via props and callbacks

A parent component tracks modal open/closed state but never uses it. What should you do?

State colocation principle: move state to the component that actually needs it to avoid unnecessary re-renders

You have a deeply nested component tree where state needs to be at the top. What problem might you encounter?

Props drilling is tedious but normal. Consider Context or a store if the chain becomes too long (4+ levels)

When should you start moving state to a global store instead of lifting to parent?

Global stores avoid excessive prop drilling when state is truly app-wide. Props to parent is better for local sharing

Is it ever correct to have the same state in two independent components?

Independent state is fine when components have different data. Problem is only when they should sync

What is the advantage of cursor-based pagination over offset-based for a news feed?

With offset, new posts shift items to next pages causing duplicates. Cursor points to exact position

What is optimistic updating in a chat application?

Optimistic updates make UI feel instant. If server rejects, the message is rolled back

When should you use virtual scrolling in a list component?

Virtual scrolling renders only visible items, dramatically improving performance with large datasets

What happens in optimistic updating if the server request fails?

Failed mutations should trigger rollback via onError handler to keep UI in sync with server reality

A news feed shows posts with like counts. How should you handle liking a post?

Optimistic updates provide instant feedback. Server sync happens in background with error handling

What is a race condition in infinite scroll pagination?

Fast scrolling can trigger multiple requests before previous completes. Handle with loading state or cancellation

In the Container/Presenter pattern, where should API error handling live?

Containers handle data fetching and errors. Presenters only receive clean data or receive an error prop to display

You have a Zustand store with 50 values. A component using just one value re-renders when another changes. How do you fix this?

Zustand supports selectors for fine-grained subscriptions to prevent unnecessary re-renders

A form has a modal for confirming deletion. The modal state was in the page parent. After refactoring, it was moved into the Modal component. Is this correct?

Pushing state down is correct—the parent doesn't need it. Parent only cares about the deletion mutation result

In the Container/Presenter pattern, which statement about prop flow is correct?

Container owns state and passes data as props downward; Presenter calls callback functions to notify Container of user interactions.

You have a Container fetching user data and a Presenter rendering it. The Presenter needs to validate email before rendering. Where should validation logic live?

Business logic (validation) belongs in the Container or extracted to pure utilities. Presenters should receive clean, validated data and only handle display.

A Presenter component receives 15 props. What does this typically indicate?

Many props often signal the Container is passing too much raw data. Consider computing derived values, flattening objects, or breaking into sub-components.

When testing a Presenter component, why is mocking unnecessary for data dependencies?

Presenters are pure functions of their props. Pass any mock data as props; no network calls or API mocking needed.

A designer wants to create 5 layout variants of a user card. With Container/Presenter split, how many files must they modify?

Container logic remains unchanged. Designer only modifies the Presenter to render different layouts—same props in, different UI out.

You refactor a giant component into Container and Presenter. The Container is now 120 lines, Presenter is 30 lines. Is this a good split?

A 120-line Container may indicate it's handling data fetching, transformations, error handling, and side effects. Consider further decomposition.

A user types into a search input 10 times per second. Which state management tool would cause the most wasteful re-renders?

React Context without splitting re-renders all consumers whenever value changes. Zustand and Redux with selectors only update subscribed components.

React Query's useQuery returns data. How does it differ from Zustand in terms of cache invalidation?

React Query provides staleTime (when data becomes stale) and cacheTime (how long to keep unused queries). Zustand has no built-in expiration logic.

You need to manage: theme (rarely changes), cart items (frequent updates), and user API data (server synced). Which combination is best?

Theme (stable) fits Context. Cart (client state, frequent) fits Zustand. User data (server-synced) fits React Query's automatic caching.

A Zustand store mutation increments a counter. If two components call the increment action simultaneously, how many times does the counter increase?

Zustand mutations execute synchronously in order. Each call increments once. Zustand's state updates are not batched by default in newer versions.

Redux DevTools show action history and time-travel debugging. Which tool comes closest to this feature out-of-the-box?

Zustand supports middleware (like immer and devtools middleware) but requires explicit setup. Others lack built-in time-travel.

A React Context Provider wraps your app. You call useContext() in 1000 components. How many memory instances of the context value exist?

One Provider creates one object in memory. All 1000 consumers read that same reference. Changes re-render subscribers, not duplicate memory.

You use React Query to fetch a list of products. The query is stale. A component mounts that also uses the same query key. Does it refetch?

By default, React Query refetches stale queries when a new subscriber mounts (staleTime: 0 by default). Prevents serving outdated data to new consumers.

A parent tracks 'isModalOpen' state but never uses it directly. Only a grandchild (nested 3 levels deep) needs it. What should you do?

If intermediate components don't need the state, push it down to the component that owns and uses it. Reduces props drilling and keeps parent simple.

Component A and B are siblings and need to share a toggle state. Their parent (Component C) never uses the toggle. Where should it live?

State must live in the nearest common ancestor of all consumers. That's C, even if C doesn't use it. Lift state up for siblings to share.

You lift state from a child to parent. Now the parent has 8 state variables. When should you consider pushing some back down?

If state only belongs to one subtree, push it down. Parent should only hold state needed by multiple direct or near children.

A form input's error message is only shown if the input is focused AND invalid. Should focus state be lifted or local?

Validation affects form submission (parent concern), but focus is internal to the input. Split concerns: lift validation, keep focus local.

You have 5 tabs. Only the active tab renders its content. Should 'activeTabIndex' be in the tab container or global?

Tab state is scoped to the TabContainer. Only lift if other unrelated components need to know which tab is active. Default: keep it local.

In a news feed with 10,000 posts, rendering all DOM nodes causes lag. Which pattern prevents this?

Virtual scrolling renders only ~20 visible posts instead of 10,000. As user scrolls, old posts unmount and new ones mount. Essential for long lists.

A news feed shows 100 posts. User scrolls and 50 more load. API returns posts at IDs 101–150. Should pagination use offset or cursor?

If new posts are added at the top, offset pagination shifts posts between pages, causing duplicates. Cursor pagination is stable.

User likes a post. UI updates immediately, but the server rejects the request. What's the correct recovery?

Optimistic updates assume success. On failure, rollback to truth (server state) and show error. React Query's onError handles this.

A chat message appears in the UI but the server hasn't acknowledged it yet. User closes the browser tab. What happens?

Robust chat requires offline-first design: queue unsent messages in localStorage or IndexedDB, retry on reconnection.

A real-time chat receives 100 messages per second from WebSocket. Rendering each immediately causes lag. What's the solution?

Batching updates reduces render cycles. Collect incoming messages, batch them into one state update every ~100ms using requestAnimationFrame or setInterval.

A Compound Component uses Context to share state between parent and children. If the parent re-renders, do children re-render?

Parent re-render evaluates children's JSX, so they mount/unmount again. However, Context value changes only re-render Context consumers separately.

You split one Context into 'ThemeContext' and 'CounterContext'. Does this reduce overall re-renders in your app?

Context splitting isolates consumers. ThemeContext consumers never re-render on counter changes. Each Context notifies only its subscribers.

A Compound Component passes data via Context. A child component needs to access the parent's state outside the component tree (e.g., in a utility function). Is this possible?

Context values live inside React's component tree. Plain utility functions can't call hooks. Pass data as parameters or use a store outside React.

Frontend Architecture Patterns — System Design Concept

🍪 TechCookies

Home DSA System Design My Progress

Free

Concepts Practice SD challenges Pricing Privacy Terms Contact

📚Frontend Architecture PatternsFree

7 sections

~28 min total

54 quick quizzes

4 SD challenges linked

0 of 7 done·~24 min left

Concepts›Frontend Architecture Patterns›What is Frontend Architecture Patterns?

0 / 7

7 sections~28 min

What is Frontend Architecture Patterns?

Organizing frontend code through proven patterns for maintainability, scalability, and team collaboration

Read

~4 min

⋯

Container / Presenter Split

Separates logic (container) from presentation (presenter) for testability and reusability

ReadQuizCode

~4 min

⋯

Context vs Global Store (Zustand vs Redux vs React Query)

Choosing the right tool for sharing state across components based on use case and frequency

ReadQuizCode

~4 min

⋯

When to Lift State Up vs Push State Down

Colocating state at the correct level in component hierarchy for efficiency and clarity

ReadQuizCode

~4 min

⋯

Relevant System Design Questions

Applying frontend architecture patterns to real-world features like feeds and chat systems

ReadQuizCode

~4 min

⋯

Advanced Patterns

Senior-level patterns — compound components, context splitting, selectors, optimistic locking, stale closures, and cursor pagination

ReadQuizCode

~4 min

⋯

Practice test

54 questions

~18 min

Section 1 of 7Read

What is Frontend Architecture Patterns?

Organizing frontend code through proven patterns for maintainability, scalability, and team collaboration

~4 min read

Frontend architecture is about organizing your code so it is easy to understand, maintain, and scale. Think of it like organizing a kitchen: if everything is in the right place, cooking is easy. If pots are in the fridge and spoons are on the roof, chaos follows. These notes cover the most important patterns every frontend developer should know, explained from the ground up with diagrams and real-world examples.

Mark this section complete.

Notes

🔍

Loading…