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