You click a card on the dashboard. Looks like nothing — one component, right there in the file you're already looking at.
It isn't. It's one of several produced by a .map(). It's the branch of a conditional that happens to be on screen — the other branch is one state change away, and invisible right now. What actually draws it is a wrapper, with the real component a layer or two underneath. And that real component lives in a different file, reached through a re-export. Four walls between the pixel you clicked and the code that made it: a loop, an invisible branch, a wrapper, a re-export.
Most tools stop at the first wall. Land you in the wrong place, or just the nearest place, and call it done. That's the actual pain: you click, you get somewhere, but not there. You still have to go hunting.
We built drill-down to keep going. Through the .map(), through the wrapper, through the re-export, all the way to the file where the thing is actually defined — and back up again, one layer at a time, whenever you want.
Why stopping at the first wall is the default failure mode
The screen you're looking at is a flat tree of pixels. The source that produced it is a nested tree of expressions, conditionals, and loops, spread across however many files someone decided to spread it across. These two trees don't line up file-for-file, wall-for-wall.
So a click can't just be "find the matching thing." It has to be a path — DOM node, then the JSX expression that drew it, then the component call, then the component's actual definition, then the file that definition lives in, then the call site above that passed the props in. Stopping one layer too early is the single most common way a "click to find it" feature quietly fails.
Four walls that stop a shallow tool cold
The .map() wall. One line of JSX produces five cards. Click any of them, you land on that one line — we don't pretend to know "which iteration" you clicked, that's runtime data, not source structure, faking it just makes the tool unpredictable. What we do instead: land on the map expression, then let you drill one more level down, into the actual template structure sitting inside it. Two honest stops instead of a guess.
The invisible-branch wall. {isVip ? <GoldBadge /> : <SilverBadge />} — only one branch is on screen right now. Click into the one that isn't, and a shallow tool just says "nothing to show." We render that branch on its own instead, like flipping the switch for a second, so you actually see it.
The re-export wall. The component you clicked isn't defined where you are. It's imported, maybe through a barrel, maybe through two. A tool that stops here drops you at the import line and calls it a day. Drilling through means landing on the real definition, without losing track of what props the original call site was passing — otherwise you land in a strange file with no idea how you got there.
The wrapper wall. withAuth(withTheme(Card)). Click the rendered thing — is "this component" the innermost Card, or something a wrapper is doing? A shallow tool picks one and hopes. Drilling means you can move through every layer of wrapping, one click at a time, and see what each one is actually responsible for.
The rule that keeps the drill-down predictable
One rule, applied every time: land somewhere definite first, then give an explicit way to go deeper or pull back — never a silent guess.
First click: the smallest meaningful JSX unit closest to what you clicked. Not the outer wrapper, not the raw DOM leaf.
Click again, or use an explicit gesture, and you move up the chain — component call, then the call site that passed props in, then the file the component actually lives in. This is the same chain behind the breadcrumb trail from our earlier walkthroughs — here we're talking about the rule driving it, not the visual.
This rule only got solid after running it against a few hundred real templates. It wasn't right on a whiteboard the first time.
Drilling the other direction, from code into canvas
Cursor on a .map() expression: every one of the N rendered results lights up on canvas, not just the first.
Cursor on a HOC's definition: every rendered instance using that wrapper lights up — could be scattered across totally different screens.
Cursor on an inactive branch: canvas renders that branch on its own so you can actually see it, instead of a dead end.
The nastiest case we could find
shadcn-admin, the left sidebar — components/layout/nav-group.tsx. You click one nav item. On screen it's just a button.
It isn't one thing. It's one of N produced by items.map(...), and inside that map a three-way branch decides what the item even is: a plain <SidebarMenuLink> when it has no sub-items, a <SidebarMenuCollapsedDropdown> when the sidebar is collapsed, or a <SidebarMenuCollapsible> otherwise — so two of the three are off screen right now, in whatever state you're not currently in. The button you actually see is <SidebarMenuButton asChild>, a Radix Slot wrapper that merges its props onto its child, and its real definition isn't in this file at all — it's in @/components/ui/sidebar, behind a barrel export.
Click it. First stop: the closest JSX layer. Drill up: you're inside the items.map(...) that generates the whole menu. Flip to the branch that isn't showing — the collapsed-sidebar dropdown — and the canvas renders just that branch on its own, without actually collapsing anything. Peel the asChild Slot to see what it's merging onto. Jump to the real SidebarMenuButton: a different file, through the barrel.
Four walls — a .map(), an invisible branch, a Slot wrapper, a re-exported definition — one click, and you get through all of them. (Every name above is real: nav-group.tsx, SidebarMenuLink/SidebarMenuCollapsible/SidebarMenuCollapsedDropdown, and SidebarMenuButton from @/components/ui/sidebar.)
Why this is a real pain point, not a nice-to-have
Every "click to inspect" feature that exists eventually hits one of these four walls and just stops — usually silently, so you don't even realize you're in the wrong place until you've wasted five minutes editing the wrong file. That's the actual cost: not "this feature is missing," but "I trusted where it took me and it was wrong."
What this means for teaching React
Put a cursor inside a .map(), watch eight elements light up at once — that teaches list rendering better than any explanation of the key prop ever has, and it only works because the tool knows exactly how many things to light up.
HOCs and wrapped components are one of the hardest things for beginners to reason about — "what even is this component" doesn't have one right answer. Drilling up through the wrapper stack, one layer at a time, and seeing what each one is actually doing, beats defining "higher-order component" on a slide.
Being able to see both branches of a conditional side by side — what a VIP sees, what everyone else sees — without touching state or faking test data is something a lot of people never get straight even years into writing React.
What this means for reviewing AI's diffs
The common workflow now: AI hands you a diff, you review it. Real problem — if that diff touches one line inside a .map(), you genuinely can't tell from the text alone whether it changes every item in that list or just one special case. Layer ambiguity is a live blind spot in code review, and it's exactly the kind of thing that slips through when someone's skimming a PR at the end of the day.
With a real notion of layer, an AI-generated change can be labeled by what it actually touches — a shared component definition (hits every call site) versus a single call site's props (hits just this one). That distinction is the whole ballgame for judging whether a change is safe, and most diff views today just don't carry it.
Push it further — if an AI agent itself can sense which layer a change lands on, it avoids a common failure mode: thinking it edited one instance when it actually touched the shared definition, quietly breaking five other places that use that component.
Three questions for any tool claiming to handle this
Click one of several elements generated by a
.map()on the canvas — does the code correctly select the map expression that generated it? Can you drill one step further into the actual template? What happens with nested maps?Click a component wrapped in a HOC — can you climb up / down, one layer at a time, and see what each wrapper actually does?
Put your cursor on a conditional branch that isn't currently rendering — does the canvas actually render that branch for you, or does it just apologize that there's nothing to show?
