When to Reach for useMemo, useCallback, and useRef

Lộc Trương — Mon, 13 Apr 2026 11:09:23 +0000

Let's talk about hooks. Specifically, useMemo, useCallback, and useRef. These aren't magic wands. They're tools I use to solve specific problems in React. But using them wrong can bloat your code and make it slower.

First up, useMemo. This hook is for memoizing expensive calculations. It takes a function and an array of dependencies, and only recomputes that value if one of the dependencies changes. I used to think I should use useMemo everywhere to save every possible millisecond. But I was wrong. Memoization has overhead too. If the calculation isn't expensive, or if it has many dependencies that change often, useMemo might not help. In fact, it might even hurt your performance. I've learned to skip useMemo unless I can point to a specific, measurable render lag caused by a calculation. Otherwise, the memoization overhead isn't worth it.

Next, we've got useCallback. This is crucial when you're passing callbacks to child components. If a component re-renders and passes down a new function, child components might unnecessarily re-render too, even if the function's body hasn't changed. By wrapping the function with useCallback, we can avoid that. It's similar to useMemo, but for functions. I've found this to be particularly useful when working with libraries like Redux, where you're passing down dispatch actions. But don't use it indiscriminately. If a function's dependencies change often, useCallback might not help much.

Lastly, there's useRef. This is different from the other two because it's not about optimization. Instead, it's about persistence. A ref object's .current property holds a mutable value that doesn't trigger re-renders when updated. This is great for keeping track of things like previous prop values, timers, or DOM elements. Some might say it's the most underrated hook of them all. With useRef, I've found myself doing things that would have previously required class components. But beware, it’s not a silver bullet. Overusing useRef can make your code harder to read and debug.

Reach for these hooks when you have a clear problem—a laggy UI, unwanted child re-renders, or a need to persist values outside the render cycle. But here’s the thing: Don’t start with them. Default to simpler code first. Only optimize with these tools when you need to. And when you do, be sure you’re actually solving a problem, not just chasing perceived performance gains.

How to Get the Correct Y Position of an Element in CHATGPT UI

Lộc Trương — Tue, 24 Mar 2026 00:40:29 +0000

The Problem

You try to get the vertical position of an element like this:

window.scrollY

...but it always returns 0.

Even worse, this common pattern also fails:

element.getBoundingClientRect().top + window.scrollY

If you're inspecting the ChatGPT web UI, this can be very confusing.

Why `window.scrollY` Is Always 0

In ChatGPT (and many modern web apps):

The page itself does not scroll
Scrolling happens inside a nested container
The <body> is fixed-height

That means:

window.scrollY === 0 // always true

So "the top of the page" is not the document - it's the scrollable container.

Step 1: Target the Element

const el = document.querySelector("div.whitespace-pre-wrap");

Step 2: Find the Scroll Container

This helper walks up the DOM and finds the element that actually scrolls:

function findScrollParent(element) {
  let parent = element.parentElement;

  while (parent) {
    const style = getComputedStyle(parent);
    if (/(auto|scroll)/.test(style.overflowY)) {
      return parent;
    }
    parent = parent.parentElement;
  }

  return document.documentElement;
}

const container = findScrollParent(el);

Step 3: Calculate the Correct Y Position.

This gives you the distance from the beginning of the scrollable page:

const y =
  el.getBoundingClientRect().top -
  container.getBoundingClientRect().top +
  container.scrollTop;

console.log(y);

How to verify the Y Value is Correct

Test 1: Scroll to it

If the value is correct, the element will align perfectly:

container.scrollTo({
  top: y,
  behavior: "smooth"
});

Test 2: Visual Marker

Draw a horizontal line at the calculated Y:

const marker = document.createElement("div");
marker.style.position = "absolute";
marker.style.left = "0";
marker.style.right = "0";
marker.style.background = "red";
marker.style.height = "2px";
marker.style.top = y + "px";
document.body.appendChild(marker);

Test 3: Reverse Check

container.scrollTop = y;
const diff = 
  el.getBoundingClientRect().top() - 
  container.getBoudningClientRect().top;
console.log(diff);

What Does NOT Work (and Why)

window.scrollY // page doesn't scroll
document.body.scrollTop
element.offsetTop // breaks with nested layouts

Key Takeaways

window.scrollY only works when the document scrolls
ChatGPT uses an internal scroll container
Always compute positions relative to the scroll container
Use getBoundingClientRect + scrollTop for reliable results

Final snippet

const el = document.querySelector("div.whitespace-pre-wrap");
const container = findScrollParent(el);

const y = 
  el.getBoundingClientRect().top -
  container.getBoundingClientRect().top +
  container.scrollTop;

When This Pattern Is Useful

Browser extensions
UI automation (Playwright / Selenium)
Auto-scrolling chat UIs
Virtualized lists
Any SPA where windows.scrollY is useless

DEV Community: Lộc Trương