1.8 KiB
| title | source | updated | tags | ||||
|---|---|---|---|---|---|---|---|
| Active Component Import Verification — Check Which File Is Actually Rendered | daily/2026-05-10.md | 2026-05-10 |
|
Active Component Import Verification — Check Which File Is Actually Rendered
The Pattern
Before editing a component file, verify it is the one the app actually imports and renders. Editing the wrong file wastes multiple edit cycles with no visible change in the browser.
The Bug (Shumiland Case Study)
A project had two header files:
src/components/Header.tsx— unused legacy filesrc/components/HeaderClient.tsx— the actual rendered component
All edits went to Header.tsx because it was found first by glob. The app imports HeaderClient.tsx exclusively. The browser never changed.
How to Verify Before Editing
# Find who imports the component you want to change
grep -r "import.*Header" src/ --include="*.tsx" --include="*.ts"
# Or trace from the page/layout file downward
grep -r "Header" src/app/ --include="*.tsx"
In Claude Code, use Grep to check the import chain:
pattern: "import.*Header|from.*Header"
path: src/
Rule
When a component name has multiple matching files, always grep for which one is imported before editing.
Common patterns that cause this:
Header.tsxvsHeaderClient.tsx(React Server Component split)Button.tsxvsButtonBase.tsxLayout.tsxvsRootLayout.tsxindex.tsxbarrel files that re-export a different file
Cost of Getting This Wrong
Each wasted edit cycle = reading the file, editing, checking browser, realizing nothing changed, investigating. In a long context window this compounds quickly and causes false conclusions ("the CSS must be wrong" when the file was never rendered at all).