FE Design

React

A declarative, component-based JavaScript library for building user interfaces, centered around a reconciliation engine that synchronizes a virtual representation of the UI with the actual DOM.

Cheat Sheet

Prime Use Case

When building complex, state-driven web applications that require high interactivity, frequent UI updates, and a scalable component architecture.

Critical Tradeoffs

  • Developer productivity vs. runtime overhead
  • Declarative simplicity vs. abstraction leakiness
  • Rich ecosystem vs. decision fatigue

Killer Senior Insight

React's true power isn't the DOM; it's the abstraction of 'UI as a function of state' (UI = f(state)), which allows the same logic to target DOM, mobile (Native), or even hardware via custom renderers.

Recognition

Common Interview Phrases

We need to handle real-time updates across multiple UI sections
The UI has many interdependent components with shared state
We need a highly maintainable and testable codebase for a large team

Common Scenarios

  • Single Page Applications (SPAs) with complex client-side routing
  • Cross-platform component libraries used across web and mobile
  • Data-intensive dashboards with frequent partial updates

Anti-patterns to Avoid

  • Using React for a purely static landing page where HTML/CSS would suffice
  • Directly manipulating the DOM inside a React component without using refs
  • Storing every single UI variable in a global state manager like Redux

The Problem

The Fundamental Issue

The 'State-Sync' problem: manually keeping the UI in sync with underlying data changes is error-prone and leads to 'spaghetti code' in imperative programming.

What breaks without it

Inconsistent UI states where the view doesn't match the data

Memory leaks from uncleaned event listeners and DOM nodes

Performance bottlenecks due to excessive and inefficient DOM thrashing

Why alternatives fail

Imperative jQuery-style updates scale poorly as the number of state-UI connections grows exponentially

Two-way data binding (like early Angular) can lead to unpredictable side effects and hard-to-debug circular data flows

Mental Model

The Intuition

Think of React like a blueprint (Virtual DOM). Instead of telling a builder to 'move that brick' (Imperative), you hand them a new blueprint and say 'make it look like this.' The builder (Reconciler) figures out the most efficient way to change the existing building to match the new blueprint.

Key Mechanics

1

Virtual DOM (VDOM) representation of the UI

2

Diffing algorithm (O(n) heuristic) to identify changes

3

Fiber architecture for incremental, non-blocking rendering

4

Synthetic Event system for cross-browser consistency

Framework

When it's the best choice

  • Large-scale teams requiring standardized patterns and component reuse
  • Applications needing a vast library of third-party components and tools
  • Projects targeting multiple platforms (Web, iOS, Android) using shared logic

When to avoid

  • Ultra-low latency requirements where the VDOM overhead is unacceptable
  • Extremely small bundle size constraints (e.g., micro-widgets < 10KB total)
  • Simple websites with minimal interactivity

Fast Heuristics

If SEO and initial load are critical, use React with Next.js (SSR/SSG)
If the app is mostly static content, consider Astro or Svelte
If you need fine-grained reactivity without VDOM overhead, consider SolidJS

Tradeoffs

+

Strengths

  • Predictable data flow (Unidirectional) makes debugging easier
  • Massive ecosystem and talent pool reduces hiring and integration risk
  • Strong abstraction for cross-platform development (React Native)
−

Weaknesses

  • Steep learning curve for advanced concepts like Hooks and Concurrent Mode
  • Large runtime bundle size compared to 'compiler-first' frameworks
  • Potential for performance issues if re-renders are not carefully optimized

Alternatives

Svelte
Alternative

When it wins

When bundle size and 'zero-runtime' performance are the highest priority.

Key Difference

Svelte shifts work from the browser to a build-time compilation step, eliminating the VDOM.

SolidJS
Alternative

When it wins

When you want React-like syntax but with fine-grained reactivity and better performance.

Key Difference

Uses proxies to update only the specific parts of the DOM that change, avoiding the diffing process entirely.

Vue.js
Alternative

When it wins

When you prefer a more structured, 'batteries-included' framework with a gentler learning curve.

Key Difference

Uses a template-based system and a reactive data model that tracks dependencies automatically.

Execution

Must-hit talking points

  • Explain the 'Fiber' reconciler and its role in enabling interruptible rendering
  • Discuss the 'Rules of Hooks' and why they rely on a stable call order (linked list of state)
  • Mention React Server Components (RSC) and the shift toward 'Zero-Bundle-Size' components

Anticipate follow-ups

  • Q:How would you optimize a list with 10,000 items? (Windowing/Virtualization)
  • Q:Explain the difference between useMemo and useCallback in terms of memory vs. CPU
  • Q:How does React's event delegation work at the root level?

Red Flags

Over-using 'useEffect' for data transformations

Why it fails: Triggers unnecessary re-renders and makes the data flow hard to trace; transformations should happen during the render phase.

Using array indices as 'key' props

Why it fails: Breaks the reconciler's ability to track component identity, leading to UI bugs and performance degradation during list re-ordering.