React Keys Bug — Input Focus Lost on List Reorder

React is the most popular front-end library in the world right now, and that means every JavaScript developer eventually walks into an interview room and faces React questions. The problem isn't that these questions are hard — it's that most developers know HOW React works but can't explain WHY it works that way. Interviewers can smell the difference in about 30 seconds. If you can only recite syntax, you'll get filtered out. If you can explain the reasoning behind design decisions, you get the offer.

React solves the messy problem of keeping your UI in sync with your data. Before React, developers manually poked at the DOM and prayed nothing got out of sync. React introduced a declarative model: you describe what the UI should look like given your current state, and React figures out the most efficient way to make it happen. It's the difference between telling someone 'make the button red' versus giving them step-by-step painting instructions every single time.

By the end of this article you'll be able to answer questions about the virtual DOM, reconciliation, hooks rules, controlled vs uncontrolled components, and performance optimization — and more importantly, you'll understand the reasoning deeply enough to handle follow-up questions you've never seen before. That's what actually passes interviews.

The Virtual DOM and Reconciliation: The Engine Under the Hood

The most common React interview question is 'What is the Virtual DOM?' but the follow-up 'How does reconciliation work?' is where most candidates stumble. React doesn't just refresh the page; it maintains a lightweight copy of the real DOM in memory. When state changes, React creates a new virtual tree and compares it (diffing) with the previous one.

Interviewers look for an understanding of the O(n) heuristic algorithm React uses. It assumes that two elements of different types will produce different trees and that a 'key' prop helps identify which elements are stable across renders. This prevents unnecessary re-renders and keep the UI snappy.

import React, { useState } from 'react';

/**
 * TheCodeForge — Reconciliation & Key Demo
 * This illustrates why 'keys' matter in the Virtual DOM.
 */
const ListManager = () => {
  const [items, setItems] = useState(['Docker', 'Kubernetes', 'Spring Boot']);

  const addTech = () => {
    // Adding to the start of the array to test React's diffing
    setItems(['React', ...items]);
  };

  return (
    <div className="p-4">
      <button 
        onClick={addTech} 
        className="bg-blue-500 text-white px-4 py-2 rounded"
      >
        Add React to Stack
      </button>
      <ul className="mt-4">
        {items.map((item, index) => (
          // BAD: Using index as key. React might lose state if items shift.
          // GOOD: Using the item string (or a unique ID) as the key.
          <li key={item} className="border-b py-1">
            {item}
          </li>
        ))}
      </ul>
    </div>
  );
};

export default ListManager;

Hooks Rules: Why They Exist and What Breaks When You Break Them

React hooks enforce two rules: only call hooks at the top level, and only call them from React functions (components or custom hooks). The 'why' is critical for interviews. Under the hood, React relies on the order of hook calls between renders to maintain state and effect references. If you conditionally call a hook, the number of hooks changes between renders, and React's internal list of hook states gets misaligned — leading to bugs like stale state or skipped effects.

Mid-level developers can recite the rules; senior developers explain the linked-list based hook storage mechanism. React stores hooks for a component as a linked list where each hook's pointer depends on the call order. Conditional calls break the order, corrupting the list.

import React, { useState, useEffect } from 'react';

/**
 * TheCodeForge — Hook Rules Violation Demo
 * This demonstrates what happens when you break the rules.
 */
const CounterWithCondition = ({ initial }) => {
  const [count, setCount] = useState(initial);
  // BAD: conditionally calling hook
  if (count > 5) {
    const [flag, setFlag] = useState(false); // WRONG — violates top-level rule
  }
  useEffect(() => {
    document.title = `Count: ${count}`;
  }, [count]);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(c => c + 1)}>Increment</button>
    </div>
  );
};

export default CounterWithCondition;
// Error: Hooks must not be called conditionally

Controlled vs Uncontrolled Components: The Production Reality

In interviews, you'll be asked the difference between controlled and uncontrolled components. Controlled components keep form state in React state (single source of truth). Uncontrolled components store form data in the DOM itself, and you access it via refs when needed (e.g., form submission). The choice matters for validation, real-time UI updates, and testability.

Most mid-level devs can define both. Senior devs discuss the tradeoffs: controlled components give you full control but cause a re-render on every keystroke (fine for most forms). Uncontrolled components are lighter but harder to react to changes. In production, you'll use controlled for most inputs, uncontrolled for file inputs or when you need to integrate with non-React code.

import React, { useState, useRef } from 'react';

/**
 * TheCodeForge — Controlled vs Uncontrolled Example
 */
const FormExample = () => {
  // Controlled input with state
  const [email, setEmail] = useState('');

  // Uncontrolled input with ref
  const passwordRef = useRef(null);

  const handleSubmit = (e) => {
    e.preventDefault();
    const password = passwordRef.current.value;
    console.log('Controlled email:', email);
    console.log('Uncontrolled password:', password);
  };

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label>Email (Controlled):</label>
        <input
          type="email"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
        />
      </div>
      <div>
        <label>Password (Uncontrolled):</label>
        <input
          type="password"
          ref={passwordRef}
          defaultValue=""
        />
      </div>
      <button type="submit">Submit</button>
    </form>
  );
};

export default FormExample;

useEffect and Lifecycle: The Cleanup Trap

useEffect is the gateway to side effects in React components. It replaces componentDidMount, componentDidUpdate, and componentWillUnmount — but with a functional twist. The function passed to useEffect runs after every render by default, unless you specify a dependency array. The cleanup function returned from the effect runs before the effect re-runs and on unmount.

Interviewers probe for understanding of the dependency array and cleanup. Common pitfalls: missing dependencies causing stale closures, omitting cleanup leading to memory leaks (e.g., subscriptions or timers).

import React, { useState, useEffect } from 'react';

/**
 * TheCodeForge — useEffect with Cleanup
 * Tracks online/offline status using a browser event.
 */
const OnlineStatus = () => {
  const [isOnline, setIsOnline] = useState(navigator.onLine);

  useEffect(() => {
    const handleOnline = () => setIsOnline(true);
    const handleOffline = () => setIsOnline(false);

    window.addEventListener('online', handleOnline);
    window.addEventListener('offline', handleOffline);

    // Cleanup function: removes event listeners to prevent memory leak
    return () => {
      window.removeEventListener('online', handleOnline);
      window.removeEventListener('offline', handleOffline);
    };
  }, []); // Empty array: effect runs once (mount) and cleanup on unmount

  return (
    <div>
      <p>You are currently: {isOnline ? 'Online' : 'Offline'}</p>
    </div>
  );
};

export default OnlineStatus;

Performance Optimisation: memo, useMemo, useCallback

React's reconciliation is fast, but unnecessary re-renders drag down performance in complex apps. The interview topic: when and how to prevent wasteful re-renders. React.memo wraps a component to skip re-render if props haven't changed (shallow comparison). useMemo memoises expensive computation results. useCallback memoises callback functions to maintain referential stability across renders.

Interviewers like to see that you understand when NOT to use these tools. Over-optimisation can make code harder to debug and even hurt performance by holding onto large memoised objects. The key is: only memoise when you've measured a re-render bottleneck.

import React, { useState, useMemo, useCallback } from 'react';

/**
 * TheCodeForge — Memoisation Patterns
 * Optimising a component that renders a large filtered list.
 */
const ExpensiveList = React.memo(({ items, onToggle }) => {
  console.log('ExpensiveList rendered');
  return (
    <ul>
      {items.map(item => (
        <li key={item.id} onClick={() => onToggle(item.id)}>
          {item.name}
        </li>
      ))}
    </ul>
  );
});

const App = () => {
  const [filter, setFilter] = useState('');
  const [items] = useState([/* large dataset */]);

  // useMemo: avoid recomputing filtered list on every render
  const filteredItems = useMemo(
    () => items.filter(item => item.name.includes(filter)),
    [items, filter]
  );

  // useCallback: stable reference for the callback so React.memo can work
  const handleToggle = useCallback((id) => {
    console.log('Toggled item', id);
  }, []);

  return (
    <div>
      <input
        placeholder="Filter"
        value={filter}
        onChange={(e) => setFilter(e.target.value)}
      />
      <ExpensiveList items={filteredItems} onToggle={handleToggle} />
    </div>
  );
};

export default App;