Expert Mastery — Series 2

Preview — 3 of 10 questions

Why does Reacts Fiber architecture maintain two separate trees instead of mutating the tree thats already on screen in place?

javascript

// Conceptually, React keeps two fiber trees:
// "current" — what's actually on screen right now
// "work-in-progress" — being built for the next render

AIt's purely a memory-caching optimization with no functional purpose — a single mutable tree would work identically, just slower

BBuilding the next version of the tree separately, without touching what's currently rendered, lets React abandon or pause that in-progress work at any point (e.g., if a higher-priority update comes in) without leaving the actually-displayed UI in a half-updated, inconsistent state

CTwo trees are required because JavaScript cannot mutate a tree structure that's currently attached to the DOM

DThe second tree exists solely for React DevTools to display the component tree — it has no role in normal rendering

Why does React need a concept of update priority at all — why not just process every state update in the order it was called?

javascript

function App() {
  const [text, setText] = useState('');
  const [results, setResults] = useState([]);

  function handleChange(e) {
    setText(e.target.value); // urgent
    startTransition(() => {
      setResults(expensiveFilter(e.target.value)); // marked non-urgent
    });
  }
  // ...
}

APriority exists only for visual polish (animations), and has no effect on functional correctness or perceived responsiveness

BAll updates are already processed instantly in modern React; priority is a legacy concept kept only for backwards compatibility with class components

CProcessing every update strictly in call order would mean an expensive update (like re-filtering a large list) could block a cheap, latency-sensitive one (like updating the text the user is actively typing) from showing up promptly — priority lets React finish the urgent setText update and paint it immediately, while deferring setResults' more expensive work

DPriority only matters for updates triggered outside of React event handlers, like setTimeout callbacks — updates from onChange are always processed at the same fixed priority

Testing Librarys `render` and `fireEvent` already wrap their internals in Reacts act() utility. What specific problem does act() solve that makes it necessary in the first place?

javascript

test('increments on click', () => {
  render(<Counter />);
  fireEvent.click(screen.getByRole('button'));
  expect(screen.getByText('Count: 1')).toBeInTheDocument();
});

Aact() ensures that all state updates, effects, and their resulting re-renders triggered by an interaction are fully flushed and applied to the DOM before the test's assertions run — without it, a test could read the DOM in a state that doesn't yet reflect updates React has queued but not yet processed

Bact() is purely a TypeScript typing helper with no runtime behavior — it exists only to satisfy the type checker in test files

Cact() mocks all network requests automatically so tests don't need a separate mocking library

Dact() is required only for class components — function components using hooks never need to be wrapped in act()

Answer all 10 questions (7 more), see explanations for every answer, and track your score.