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

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
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

# 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).