Why you should not start coding when you get a feature request
How do you handle vague requests like "make it faster" or "make it prettier"?
- frontend
- spec
LATEST ESSAY
What broke when I replaced blocking window.confirm with a React Dialog. I learned to separate confirmation, cancellation, and execution into request/cancel/confirm flows.
RECENT ESSAYS
Archive
How do you handle vague requests like "make it faster" or "make it prettier"?
When tests in React Router or TanStack Query fail, I usually inspect my code first. When tests I wrote fail, I sometimes end up re-checking the test itself as well. That difference made me rethink the boundary between unit, integration, browser, and e2e tests.
Two sentences in the React docs looked contradictory at first. useRef stores values not needed for rendering, yet React says not to read ref.current during render. Tracing the source code shows these are about two different dimensions of rendering: trigger vs consistency, all the way to tearing.
Tracing just next/navigation through the source reveals where the complexity comes from: re-export entry points, context adapters, and .react-server.ts splits.