Forem: Rostislav B

React Myths That Just Won't Die

Rostislav B — Mon, 16 Mar 2026 09:14:20 +0000

Ask any LLM to write a hook that returns a function and it'll wrap it in useCallback. Ask for a component with state that depends on other state and you'll get a useEffect managing it. The code looks professional and reads cleanly. It's also quietly wrong. LLMs learned from the same sources we did: Stack Overflow answers from 2019, tutorials that predated the hooks docs. They reproduce those patterns with complete confidence, at scale. Mental models have always spread faster than documentation, and now they spread faster than ever.

React didn't help either. Class components had lifecycle methods, hooks replaced that model, concurrent features changed some assumptions again — and now "where should I put state?" reads like a philosophy essay. Simplified mental models fill that gap, not accurate but stable enough to build habits on.

Developers aren't being careless. The models just happen to be convenient to think with. They generate plausible predictions often enough to feel reliable. And the ones that survive feel like they should be true. They're the kind of wrong that's almost right, which is the hardest kind to dislodge.

"Components Re-Render When Props Change"

React is literally called React. It responds to things, and JSX looks like components are watching their inputs. The mental model people arrive at feels like the obvious interpretation: a component observes its state and props, and when those change, it re-renders. Props don't change, no re-render. It sounds right, given the name.

A component re-renders when its parent re-renders, regardless of whether its own props changed — or when its own state or context changes, but that's the part people usually get right.

React renders by calling every component function in the tree, then reconciles by diffing against the previous result to find what actually changed. A parent re-rendering pulls all its children into that pass, props or not. (React.memo is the opt-out, though it's often reached for before understanding why the re-render happened in the first place)

Consider a parent that holds some state and renders a child that receives none of it as props. Parent state updates, parent re-renders, child re-renders too. The child's props haven't changed.

function Parent() {
  const [count, setCount] = useState(0);
  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>Click</button>
      <Child />
    </>
  );
}

function Child() {
  console.log('Child rendered'); // fires on every parent click
  return <div>I have no props from Parent</div>;
}

Wrapping a child in React.memo makes sense because "so the props don't change." Wrapping a value in useMemo makes sense because "so the prop stays stable." The whole optimization story hangs on the wrong model. memo works at the reconciliation step: if props are shallowly equal, React skips re-rendering entirely and the component function never gets called.

"useMemo and useCallback Are Optimizations You Add When In Doubt"

In most codebases, useMemo is considered safe and professional. Not using it is the thing you have to justify.

The assumption underneath is that useMemo caches the result so React doesn't recompute it, and wrapping things in it is just getting free performance. But here's the thing: if you pass a plain object or array as a dependency, the memo is effectively useless.

function SearchResults({ query }) {
  const options = { page: 1, sort: 'asc', query }; // new object every render

  const result = useMemo(() => expensiveCalc(options), [options]);
  // options is always a new reference — useMemo recalculates every time
}

Now, what does useMemo actually see here? A new object on every render — same shape, different reference. It invalidates, recalculates, and you've paid for the bookkeeping without getting any of the benefit. If options comes from useState, React guarantees the same reference as long as you haven't called the setter, and that's when useMemo actually does something.

useCallback has a similar problem, maybe more common. Wrapping a function in useCallback does nothing useful unless the receiving component is wrapped in React.memo, or the function is listed as a dependency in another hook. Without that, the child re-renders regardless and the callback memoization was effort that changed nothing. (And yet this is probably the most common hook pattern in production React codebases.) LLMs generate this pattern automatically — ask for a component and you'll get one with useCallback on every handler, doing nothing useful.

The irony is that people wrap things in useMemo to be "the developer who thinks about performance." But without understanding the dependency model, it often does nothing, or actively misleads the next person who assumes the memo is there for a reason and starts building around it. There's also memo's second parameter, a custom comparison function, which almost nobody knows exists but is probably more useful in edge cases than reflexive memoization.

The default should be: don't. If you can't point to a profiler trace that justifies the wrapper, you're paying the bookkeeping cost for nothing.

"useEffect Is How You React to Changes"

The mental model people import here comes from other tools: Vue's watch, MobX's reaction, that whole "observe this value, do something when it changes" pattern. Which, if you think about it, is a reasonable instinct. Why wouldn't React work the same way? "When filters changes, update filteredData." It just comes from somewhere else.

useEffect is for synchronizing with external systems React doesn't control: DOM APIs, WebSocket connections, third-party libraries. When you use it to sync two pieces of React state together, you're using the tool for something it wasn't meant to do.

The classic antipattern shows up in roughly every other "useEffect best practices" article as the example to avoid:

const [filters, setFilters] = useState({});
const [filteredData, setFilteredData] = useState([]);

useEffect(() => {
  setFilteredData(data.filter(item => matchesFilters(item, filters)));
}, [data, filters]);

Two renders for every filter change. The filtered data could just be derived during render:

const filteredData = data.filter(item => matchesFilters(item, filters));
// no useState, no useEffect

A simpler version of the same mistake: initialize state from a prop, then write an effect to "sync" it when the prop changes. The prop could often just be the state directly. Or the component shouldn't own that state at all.

There's a reason MobX has loyal fans even as React dominates — it just fits the brain better. Observe data, react to changes: that's what people expect React to do too. Most developers nod when you explain the difference, then write a useEffect to sync state the next morning anyway.

The react.dev docs cover this now — there's a whole section called "You Might Not Need an Effect". But documentation doesn't fix how knowledge spreads. People learn React from colleagues who learned from other colleagues, from code reviews where nobody questioned the mental model. The patterns persist, and now they autocomplete. Which means the next generation of React developers will learn from LLMs that learned from us. Understanding where these models come from is the first step to not passing them on.

Do We Even Need Modals?

Rostislav B — Mon, 23 Feb 2026 09:14:52 +0000

Ever feel like the web could use some design police? No one enforcing consistency, no standards for how things should behave. Just pure freedom. And somehow, in all that freedom, modals became the answer to everything. Forms, confirmations, settings, edit screens. Whatever the question, modal was the answer. Not because they're particularly good at any of this, though. Just because they're easy to reach for when you need something to work.

What's Actually Wrong With Modals

Here's the core problem: modals block context. The page you were working on disappears behind a dark overlay, and if you need to check something in that table before filling the form, you're stuck — close the modal, look at the data, open it again, hope the state survived. It probably didn't.

The accidental dismissal problem makes this worse. Click outside and the state is gone. Hit Escape by habit — same result. Three required fields filled, but you accidentally touched the backdrop, and now you're starting over. Sound familiar? Because this isn't some edge case. It's just how most modals work out of the box.

Have you ever tried sending someone a link to a modal? Some implementations do support URLs, but it's rare enough that most people never think to try. Modals tend to exist outside the navigation model: no back button, no way to return. In a world where client-side routing makes page transitions essentially free, we're still building these floating islands with no address.

On mobile, the situation gets stranger still. Modals become fullscreen, which defeats the entire purpose. If it takes the whole screen anyway, why not make it a page with proper navigation?

And then there's async. Submit a form in a modal and suddenly you're making decisions nobody thought about upfront: where the loader goes, which buttons to disable, whether the modal closes on request start or waits for success. What happens to the content underneath while the spinner runs? Every team answers these differently, and the result is that no two modals behave quite the same way.

And in code, the complexity shows: isOpen, onOpen, onClose, handleClose, shouldClose. Every modal is a little state machine, though it's never quite clear where that state machine should live. In the component that triggers it? In a portal at root? In some global store? The answer is usually "wherever the last developer put it."

How Did We Get Here

Browser alerts exist: window.alert(), window.confirm(). They're built-in, accessible, and keyboard-friendly, which sounds like everything you'd want.

The problem is they're also ugly, completely uncustomizable, and terrifying to modern users. Most people see a browser dialog and assume something broke. You can't style them to match your design system, and good luck putting a form in one.

So we built our own. Custom divs layered on top of everything, dark overlay behind, trap the focus, listen for Escape. This solved the styling problem, but it created a dozen new problems that we're still dealing with.

What Native and Game Design Got Right

Think about the iOS date picker. You already know exactly what it looks like, how it behaves, what to expect. So does pretty much every designer and developer who's ever built for mobile. No debate about whether it should be a modal or inline or a separate screen. Standardization already solved that question.

Game interfaces, meanwhile, follow a different philosophy entirely: UI is part of the world, not a layer blocking it. Open your inventory and the game world stays visible. Need to check stats while crafting? Both panels coexist. Context is never fully blocked.

What makes this work, though? Partly standardization: when everyone knows how a component behaves, nobody wastes time reinventing it. But also, these interfaces don't hide anything behind an overlay. UI elements expand the layout, and you stay oriented because the thing you were looking at is still there. And when actions need confirmation, they flip the pattern: do the thing first, then offer undo. No interruption, just trust the user and give them a way back.

Alternatives For the Web

The simplest alternative is just... a page. I happened to work on a project where we replaced all modals with pages and back links. Client-side routing made transitions instant, URLs worked everywhere, state lived in the URL. It works on mobile, it's accessible by default. Feels heavy for small actions, sure. Not every "create new item" deserves its own route. But more things could be pages than we typically assume, even if whether they should be is a different question entirely.

For cases where a full page feels like overkill, sliding panels work reasonably well. The form slides in from the side while the main content stays visible, so you can still reference the table while filling out the form. Though panels have their own problems: they eat horizontal space, and on narrow screens they're basically modals again.

Confirmation dialogs have a cleaner replacement: toast with undo. Delete something and it's gone immediately, then a toast appears with an "Undo" button, five seconds to reverse the action. No "Are you sure?" dialog that everyone clicks through anyway. Gmail proved this works at scale, though it helps that email deletion is soft-delete anyway. For truly permanent actions, this approach gets murkier.

For editing, often no overlay is needed at all. Click a cell and it becomes an input, save on blur or Enter. Inline editing won't help with creating new entities, but it eliminates a whole category of "edit this one field" modals. And contextual menus (right-click or long-press) keep actions close to their objects rather than forcing a journey to a modal in the center of the screen.

When Modals Are Actually Right

The list is short, though maybe that's the point.

Destructive actions with no undo are the clearest case. If delete is permanent and there's no recovery, then blocking context is actually what you want, and this is probably the one situation where a modal earns its interruption.

Beyond that, you're looking at situations where you genuinely need acknowledgment before proceeding: legal consent, session expiry warnings, maintenance notifications. Cases where "just do it and offer undo" doesn't work because there's nothing to undo.

That's... mostly it?

The Designer Problem

Here's what happens. Team agrees on modal standards: header, body, footer, max height, scroll behavior, button placement. Seems reasonable.

Then second sprint comes around: "This one needs an interactive header." Third sprint: "Footer should change based on form state." Fourth sprint: "Can we have tabs inside?" By fifth sprint, welcome to modal hell.

You'd think there'd be some guardrails — but the web won't stop you from putting tabs inside a modal inside a drawer. If it renders, it ships. So people do whatever feels right in the moment. Every modal becomes a special case, composition explodes, and the component that started as <Modal title="Create Item"> becomes a 200-line monster with fifteen props.

Funny thing: the closest the web got to modal standardization was the <dialog> element, and most teams don't even know it exists.

The Actual Point

Nobody's saying modals are evil. But they've become the default answer to a question that most teams stopped asking a long time ago. When someone clicks "Create Item," do they need to focus completely on the form, or would they rather keep the table visible for reference? A modal decides for them: full focus, context gone. A sliding panel makes the opposite bet, yet most of the time we reach for the modal anyway — not because we thought about which one fits, but just out of habit.

Maybe the habit keeps winning for a reason. Or maybe it just keeps winning because it's there, and nobody has time to rethink what already works well enough.

Why Visual Metaphors Might Beat Code-First Thinking

Rostislav B — Sun, 08 Feb 2026 17:34:53 +0000

Frontend developers could spend all day thinking visually —component trees, state flow diagrams, DevTools showing exactly where things break. Then an algorithm problem appears, and that visual instinct vanishes. The editor opens, typing starts, and somehow we expect the code to figure itself out.

On the other hand, every tutorial says "draw it out before coding." Which makes sense — but draw what, exactly? If you haven't seen the pattern before, a blank page stays blank. It seems to work the other way around: learn a few visual shapes, and the right one surfaces when you need it.

The Code-First Trap

Consider the typical approach — see a problem, open the editor, start typing:

// See problem → start typing immediately
function solve(arr) {
  // uhh... for loop?
  for (let i = 0; i < arr.length; i++) {
    // wait, nested loop?
    for (let j = i + 1; j < arr.length; j++) {
      // this feels wrong but I'll keep going...
    }
  }
}

Two hours later, still broken. No idea why.

The problem becomes clearer with distance: JavaScript's flexibility lets you write anything. No compiler stops you from pursuing bad ideas. Without some visual mental model of what you're trying to do, debugging becomes guesswork — just changing things and hoping something sticks. And if you, like me, sometimes have trouble maintaining focus, the thread gets lost completely after 20 minutes of trial and error.

Pattern 1: Finding the Maximum

Find the largest number in an array. Picture a champion on stage — challengers come one by one, strongest stays.

function findMax(arr) {
  let champion = arr[0]; // First one on stage

  for (let challenger of arr) {
    if (challenger > champion) {
      champion = challenger;
    }
  }

  return champion;
}

Simple, but it sets up the idea: a visual shape makes the code obvious.

Pattern 2: Stack (Matching Brackets)

Here's a classic problem: check if brackets are balanced. "(())" is valid, "(()" is not.

The code-first approach hits a wall fast:

function isValid(s) {
  // Count opening and closing?
  let count = 0;
  for (let char of s) {
    if (char === '(') count++;
    if (char === ')') count--;
  }
  return count === 0;
}
// Fails on ")(" - same count, wrong order!
// Now what? Add more conditions? Track positions?

Consider a different model: think of it as a stack of plates.

Input: "(())"

Read (  →  Add plate     Stack: [(]
Read (  →  Add plate     Stack: [(, (]
Read )  →  Remove plate  Stack: [(]
Read )  →  Remove plate  Stack: []

Stack empty at end = Valid ✓

Input: "(()"

Read (  →  Add plate     Stack: [(]
Read (  →  Add plate     Stack: [(, (]
Read )  →  Remove plate  Stack: [(]
End: Stack not empty = Invalid ✗

Opening bracket? Add a plate. Closing bracket? Remove a plate. At the end, if the stack is empty, the brackets match. If there are leftover plates or you try to remove from an empty stack, they don't match.

The physical metaphor makes it hard to mess up — you can't remove a plate from an empty pile, and you can't have a balanced stack with plates left over.

The code becomes more obvious:

function isValid(s) {
  const stack = [];

  for (let char of s) {
    if (char === '(') {
      stack.push('('); // Add plate
    } else if (char === ')') {
      if (stack.length === 0) return false; // No plate to remove
      stack.pop(); // Remove plate
    }
  }

  return stack.length === 0; // All plates removed?
}

Pattern 3: Two Pointers (Palindrome Check)

Check if "racecar" reads the same forwards and backwards. Picture two fingers moving from the edges:

Word: "racecar"

L               R
r a c e c a r   ✓ r === r, move both inward

  L         R
  a c e c a     ✓ a === a, move both inward

    L   R
      c e c     ✓ c === c, move both inward

      LR
        e       ✓ fingers meet - it's a palindrome!

Left finger on the first letter, right finger on the last. Do they match? Move both inward. Keep going until they meet:

function isPalindrome(s) {
  let left = 0;
  let right = s.length - 1;

  while (left < right) {
    if (s[left] !== s[right]) {
      return false;
    }
    left++;
    right--;
  }

  return true;
}

Some might immediately see this pattern in other places — finding pairs in sorted arrays, removing duplicates, merging sorted lists. And there's probably some truth to that, though each of those has enough differences that it's worth treating them separately.

Pattern 4: Sliding Window (Consecutive Sum)

Find the max sum of 3 consecutive numbers in [1, 3, 2, 6, 2, 8].

Code-first means recalculating everything repeatedly:

function maxSum(arr, k) {
  let max = 0;
  // For each position, sum next k elements
  for (let i = 0; i <= arr.length - k; i++) {
    let sum = 0;
    for (let j = i; j < i + k; j++) {
      sum += arr[j]; // Recalculating same numbers over and over
    }
    max = Math.max(max, sum);
  }
  return max;
  // Works but slow (O(n*k))
}

Picture a frame sliding across the array instead:

Array: [1, 3, 2, 6, 2, 8], k=3

Frame 1: [1, 3, 2] → sum = 6

Frame 2:    [3, 2, 6] → sum = 11
              ↑     ↑
           remove  add

Frame 3:       [2, 6, 2] → sum = 10
                 ↑     ↑
              remove  add

Frame 4:          [6, 2, 8] → sum = 16 ← max

Calculate the first frame's sum. Then slide the frame: remove the left edge, add the right edge. Don't recalculate the middle numbers — they stay in the frame. The optimization follows naturally:

function maxSum(arr, k) {
  // Calculate first window
  let windowSum = 0;
  for (let i = 0; i < k; i++) {
    windowSum += arr[i];
  }
  let maxSum = windowSum;

  // Slide the window
  for (let i = k; i < arr.length; i++) {
    windowSum = windowSum - arr[i - k] + arr[i];
    //              remove left   add right
    maxSum = Math.max(maxSum, windowSum);
  }

  return maxSum;
}
// O(n) instead of O(n*k) - much faster!

The drawing shows what changes: only the edges. Middle stays the same.

This one took me longest to get. I'd seen the formula, could memorize it, but it felt... arbitrary? Subtract left, add right — why? Watching the frame slide, the visual makes it inevitable. Not a trick to remember, but a shape that's there whether you notice it or not.

Pattern 5: BFS (Shortest Path)

One more pattern, slightly harder. Find the shortest path from S to E in a maze:

S . . #
# . . #
# . # .
# . . E

Without a visual, it's hard to even figure out where to start:

// Try every path? Recursion?
function findPath(maze, row, col) {
  // Go right? Down? Up? Left?
  // How do I know which way is shortest?
  // Recursion depth getting crazy...
  // Stack overflow on complex maze...
}

Think of dropping a stone in water. Ripples spread in circles. That's BFS.

Step 0:  S . . #     Start: S is wave 0
         # . . #
         # . # .
         # . . E

Step 1:  0 1 . #     Wave 1 spreads from S
         # . . #
         # . # .
         # . . E

Step 2:  0 1 2 #     Wave 2 spreads from wave 1
         # 2 . #
         # . # .
         # . . E

Step 3:  0 1 2 #     Wave 3 spreads from wave 2
         # 2 3 #
         # 3 # .
         # . . E

Final:   0 1 2 #     Found E at distance 5!
         # 2 3 #
         # 3 # 5
         # 4 5 E

Start position is wave 0. Each step spreads to neighbors, creating the next wave. First wave to reach the goal gives you the shortest path, because waves spread uniformly.

There's something satisfying about drawing this one — watching the numbers fill in like water. The visual sticks.

The algorithm makes more sense:

function shortestPath(maze, start, end) {
  const queue = [{ pos: start, distance: 0 }]; // Wave 0
  const visited = new Set();

  while (queue.length > 0) {
    const { pos, distance } = queue.shift(); // Process current wave

    if (pos === end) return distance; // Found it!

    if (visited.has(pos)) continue;
    visited.add(pos);

    // Spread to neighbors (next wave)
    for (const neighbor of getNeighbors(pos)) {
      if (!isWall(neighbor) && !visited.has(neighbor)) {
        queue.push({ pos: neighbor, distance: distance + 1 });
      }
    }
  }

  return -1; // No path found
}

One caveat: this only works when all steps cost the same. If some paths are "harder" than others — like moving through mud versus pavement — the wave metaphor breaks. You'd need Dijkstra's algorithm instead, which is more like... actually, not sure what the right visual is there. Priority queues don't map to water as cleanly.

Frontend Example: Flattening Nested Comments

Consider a real-world frontend problem. You have nested comment threads and need to flatten them for display or search:

const comments = {
  id: 1,
  text: "Parent comment",
  replies: [
    {
      id: 2,
      text: "First reply",
      replies: [
        { id: 3, text: "Nested reply", replies: [] }
      ]
    },
    { id: 4, text: "Second reply", replies: [] }
  ]
};

Code-first thinking stalls immediately:

function flatten(comment) {
  // Recursion... but wait
  // How deep can this go?
  // What if there are 1000 levels?
  // Stack overflow risk?
}

Try drawing it as a tree:

        1 (Parent)
       / \
      2   4
     /
    3

Stack: [1]           → pop 1, result: [1], push 2,4
Stack: [2, 4]        → pop 2, result: [1,2], push 3
Stack: [3, 4]        → pop 3, result: [1,2,3]
Stack: [4]           → pop 4, result: [1,2,3,4]
Stack: []            → done

Once you draw the tree, it clicks — this is a tree traversal problem, deep nesting means recursion might overflow the stack, and you probably need an iterative solution with an explicit stack.

Solution becomes clearer:

function flattenComments(root) {
  const result = [];
  const stack = [root]; // Explicit stack (no recursion limit)

  while (stack.length > 0) {
    const comment = stack.pop();
    result.push(comment);

    // Add children to stack (reverse order for correct traversal)
    for (let i = comment.replies.length - 1; i >= 0; i--) {
      stack.push(comment.replies[i]);
    }
  }

  return result;
}

How to Recognize Patterns

Look for trigger words in the problem — they point to the shape:

Trigger Words	Pattern	Visual	When It Might Help
"largest", "smallest"	Simple loop	Champion on stage	One-pass comparison
"matching pairs", "nesting"	Stack	Plates pile	Last-in-first-out
"palindrome", "from both ends"	Two Pointers	Fingers from edges	Scan from both sides
"consecutive k", "window"	Sliding Window	Moving frame	Fixed-size range
"shortest path", "minimum steps"	BFS	Water ripples	Graph/grid traversal
"nested", "hierarchical", "tree"	DFS/Stack	Tree + stack trace	Recursive structures

Does This Actually Help?

Memorizing code patterns fades quickly, but visual metaphors stick. Drawing helps, but recognition is the real skill — knowing which shape fits the problem in front of you.

Next time you're stuck, try asking "What does this look like?" instead of "How do I code this?" You might be surprised how often the answer is already there, waiting to be seen.