obsidian/wiki/concepts/active-component-import-verification.md
2026-05-10 22:41:36 +01:00

50 lines
1.8 KiB
Markdown

---
title: Active Component Import Verification — Check Which File Is Actually Rendered
source: daily/2026-05-10.md
updated: 2026-05-10
tags: [react, next.js, debugging, workflow]
---
# 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 file
- `src/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
```bash
# 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.tsx` vs `HeaderClient.tsx` (React Server Component split)
- `Button.tsx` vs `ButtonBase.tsx`
- `Layout.tsx` vs `RootLayout.tsx`
- `index.tsx` barrel 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).