DEV Community: Jack Lee

Your sx prop is already a data structure, and almost no tool treats it that way

Jack Lee — Mon, 28 Sep 2026 12:00:00 +0000

Last week I wrote about why shadcn is hard to edit visually, and somewhere in the middle I made a claim in passing: shadcn's styling is a string, MUI's sx is data, and those two need different editors.

A few people asked the obvious follow-up. Fine — what does the data side actually look like?

This is that answer. It's less dramatic than the shadcn one, because nothing here was blocked on a rendering trick. It's more useful, though, because the interesting decisions are all about where to stop.

Put the two side by side:

className="p-4 hover:bg-accent md:p-6"

sx={{ p: 4, '&:hover': { bgcolor: 'accent' }, '@media (min-width:900px)': { p: 6 } }}

Same design intent. The first is a token list that happens to have conventions baked into the token names. The second has actual shape: keys, nesting, values you can address by path.

A string has to be parsed before you know what's in it. An object already knows. Which sounds like it makes the editor easy — and the tree part genuinely is easy. The hard parts moved somewhere else: deciding which keys deserve to be structure, and putting a change back in the file without touching anything else.

Nesting is a tree, so the UI is a tree

The rule for what becomes a branch is one line:

key.startsWith('&') || key.startsWith('@') || key.startsWith(':')

Hit → expandable branch, recurse. Miss → leaf, render a control.

That's the whole thing, and it covers more than you'd expect. &:hover, @media (min-width:900px), & > *, &::placeholder, & .MuiButton-root — all of them become tree nodes for free, because CSS-in-JS conventions are prefix conventions.

Seventeen of them ship with human labels: &:hover → Hover, @media (min-width:900px) → MD, & > * → Direct Children. Anything not in that list still nests correctly, just without a friendly name. The rule is general; the labels are a courtesy.

One decision in there is worth pulling out, because it's the kind of thing that only shows up once you've used the panel on real code:

isBranch = !isExpression && !isResponsive && (hasChildren || isSelector)

Expressions and responsive values win over selectors. If a key looks structural but its value is one of those two, it stays a leaf.

That isn't a house style. It's how MUI's own sx processor dispatches. When it walks an sx object and hits a nested object, it asks whether the keys are breakpoints before it treats the thing as a nested style block — roughly:

hasBreakpoint(value) ? resolveResponsive(value) : recurseAsNestedStyles(value)

A breakpoint object is a value spread across viewports. A selector object is a scope containing more styles. They're written with identical syntax and mean entirely different things, so the styling engine has to disambiguate before it can do anything, and it disambiguates on the keys.

The panel is drawing that same decision. { xs: 2, md: 3 } renders as one responsive control rather than a two-child subtree because that's what MUI is going to do with it. An expression stays whole for the same reason: MUI calls it with the theme and uses the result as a value, so the panel treats it as a value too.

Which is also the practical answer. When someone writes a responsive object or drops in an arrow function, they're holding it in their head as one thing. Exploding it into a subtree turns a single decision into rows you have to keep in sync — and now the panel's model of the file disagrees with the framework's.

Keep that in mind for the write-back section. The same instinct runs through it: touch as little as possible.

The tree's edges have to follow the real semantics

Breakpoints in the panel aren't hardcoded. They come from the same VIEWPORTS config the canvas uses for device sizes — MUI's breakpoint keys, with a representative device width picked for each: xs 375, sm 600, md 900, lg 1200, xl 1536.

(Those widths are canvas device widths, not breakpoint thresholds. sm through xl happen to line up with MUI's defaults; xs doesn't, because MUI's xs floor is 0 and you can't render a 0px canvas.)

The nice consequence is that the breakpoint you click in the style panel and the device you switch to on the canvas are the same object. Not two lists that have to be kept in sync by whoever remembers.

Promoting a value to responsive fills all five breakpoints with the current value:

{ p: 2 }  →  { p: { xs: 2, sm: 2, md: 2, lg: 2, xl: 2 } }

Not { xs: 2, md: 3 }. You differentiate afterward, by hand, at whichever breakpoint you actually care about.

I've been asked why it doesn't write a minimal object. Because the panel is showing you five rows, and three of them would be blank while still rendering something — MUI cascades responsive objects upward, so the value is real even when the key is absent. Blank rows that aren't blank in the output are a bad place to start editing from. Filling all five means promotion is a visual no-op: nothing changes on screen, you just gained five editable slots. Then you change one.

And when you do change one, only that one gets written. Editing the md slot produces a patch carrying dirtyPath: ['md'], which becomes ['p', 'md'] by the time it reaches the writer. The other four are never re-emitted. (That matters more than it sounds. It's the next section.)

Here's the part I think is actually worth the post, and it took me a while to see why it wasn't a limitation.

The same-looking value gets different treatment depending on which path it's written on.

Inside sx={{ ... }}, any property can be promoted — including custom CSS keys you invented. sx is MUI's own styling channel and it accepts breakpoint objects wherever a value goes. (On any component that processes sx, which is every MUI component. A plain <div> doesn't have an sx prop to begin with.)

Written as a top-level system prop, it can't:

<Box p={{ xs: 1, md: 3 }}>          {/* fine */}
<Typography p={{ xs: 1, md: 3 }}>   {/* not a thing */}

Only Box, Stack, and Grid support system props as top-level breakpoint objects. Typography's system props were deprecated in v6. So the panel offers promotion on those three and withholds it elsewhere — on the top-level path only.

And under either path, a value that came from a spread can't be promoted at all, because there's nowhere unambiguous to write the result.

That's three different answers for what looks, in the inspector, like the same number:

where the value lives	promotable?
inside `sx={{ ... }}`	any property, on any component that takes `sx`
top-level system prop	`Box` / `Stack` / `Grid` only
anything from a spread	no

If the panel flattened those into one rule, one of two things goes wrong. Offer promotion everywhere and you get a control that produces code MUI ignores — the panel looks right, the render doesn't change, and you lose twenty minutes deciding whether you misunderstood breakpoints or found a bug. Withhold it everywhere outside Box/Stack/Grid and you've disabled a feature that works fine, on the path where it works fine.

So the panel's edges follow MUI's semantics rather than a single convenient fiction about them.

That's the concrete version of the argument I was making last week. "Does this accept a breakpoint object here?" is knowledge about the styling system, it differs by path within the same component, and it's only actionable if the styles are data you can reason about. A tool that edits className as a string has no way to know the difference, and no place to put the distinction even if it did.

The three-second version, if you want to check it: put p={{ xs: 1 }} on a Box and on a Typography, then look at the same spacing value written inside sx on both. Three of those four offer promotion. On a free account the affordance is a gold lock rather than the control — responsive promotion is a paid feature — but a lock and an absence are different states, and telling them apart is the whole exercise.

Writing back: no reserialize

Most people assume a visual editor works like this: read the file, parse to AST, mutate the AST, print it back out.

That assumption has a well-known answer already — recast and ts-morph have preserved original formatting for unmodified nodes for over a decade. So this isn't a story about a tool that mangles your file versus one that doesn't. That problem is solved.

The difference here is where the ranges live. The IR carries them. Every value node knows its own start and end offset in the source, so an edit doesn't need a print-then-reconcile pass at all. An edit is a path plus a new value, and the path resolves to a byte range:

Every IR value node carries range_v — where that value starts and ends in the source.
An edit produces a dirtyPath — ['p', 'md'] — naming the one thing that changed.
Write-back replaces that range. One splice.

Which means your formatting, your comments, your quote style, that arrow function three properties down, the blank line you put there on purpose:

They aren't preserved. They're untouched. We never had them in hand, so there's nothing to get wrong.

There's a second thing worth mentioning here, because it surprised me when I traced it. The theme editor and the sx editor are the same writer. Three commands form one cascade:

updateJSObject  >  updateStyle  >  updateProp

updateJSObject — the one the MUI theme editor emits — wraps itself in a synthetic style, then rewrites its own command type and falls through to updateStyle, which does the same thing again and falls through to updateProp. Editing createTheme()'s palette and editing an inline sx value converge on the same byte-range splice by the time they hit the file.

That 1310-line theme editor isn't a second implementation. It's a second entrance to one hallway.

The part that answers last month's post

I ended the shadcn piece on a problem I didn't have an answer for:

className={cn("border-b", isActive && "bg-red-500", buttonVariants({ variant }))}

Set padding to 6 from a panel, and something has to decide which literal to edit. The base string? The conditional? The variant definition every other button on the page also uses? Sometimes there's no correct answer, only a policy.

On the sx side — when sx is an inline object literal — the question doesn't come up. Not because we solved it. Because objects have paths. sx.p.md names exactly one span of bytes in exactly one file, and the panel doesn't have to choose anything.

The qualifier is load-bearing, so let me be exact about it. Two shapes don't get that guarantee:

sx={sharedSx}            // the path isn't in this JSX attribute at all
sx={{ ...base, p: 4 }}   // whatever base contributes lives somewhere else

The first is the same class of problem as the shadcn one, arrived at from the other direction. The second I'd rather not characterize than characterize wrong.

But that's the real difference between the two sides, and it's narrower than "objects good, strings bad": an inline object literal gives you an addressable path; string concatenation never does, no matter how it's composed.

Where it refuses, and how

Plenty of sx values can't be turned into controls. That refusal happens when the panel reads, not when it writes.

The IR has exactly three value shapes:

shape	meaning	UI
`{ value }`	a plain value	visual control
`{ code }`	an expression, source text kept verbatim	expression editor
`{ object }`	a branch	recurse

Plus { code, object } — source text and parsed result, both retained.

So sx={{ p: theme => theme.spacing(2) }} becomes { code: "theme => theme.spacing(2)" }, stays a leaf, and gets a code editor instead of a slider. If the entire sx prop is an expression the panel switches itself to advanced mode. Properties outside the Basic set say so in as many words: "This style is not available in Basic mode."

None of that is silent degradation. The boundary is stated: here's a control, here's why there isn't one, here's your original text back. A structured editor that guesses wrong rewrites your source incorrectly. One that drops to text doesn't.

Being straight about the gaps

Three, and the third is the one that bothers me.

Responsive promotion is a paid feature. Free accounts get a gold lock and an upgrade prompt. I'd rather you learn that here than from the lock.

On the top-level system-prop path it's Box/Stack/Grid only — explained above, and I think that's correct rather than partial, but it does mean the affordance is absent in places where a casual read would expect it.

Your custom theme tokens don't appear in the sx autocomplete. The theme editor edits your project's real createTheme(). The sx suggestion list is a hardcoded table of MUI's default keys. palette.primary.main is in it. palette.brand.main, which you defined, is not.

That last one should look familiar if you read the shadcn post. I wrote there that your tailwind.config tokens are fed to the engine but never reach the inspector. This is the identical seam in a completely different styling system:

The rendering pipeline gets your project's configuration. The editing surface doesn't.

Two style systems with nothing in common, the same unconnected wire in both. That's not two oversights. That's one missing idea — project configuration isn't a first-class input to the panel yet — and finding it twice is how I know it's structural rather than a todo someone forgot.

The actual difference

sx can be a tree because MUI's styling happens to be a data structure. shadcn's happens to be a string. Neither is a design failure; they're different bets, and both are reasonable.

But they hand a tool completely different jobs. One asks you to understand structure. The other asks you to render it correctly before you can understand anything at all.

Change a value inside a string, and you have to decide which part of the string to change.
Change a value inside an object, and the path already told you.

Everything hard about visual editing lives on one side of that sentence or the other.

If you work in MUI: Studio has a free tier. Open a template, find an sx prop with a &:hover in it, and tell me where the tree gets it wrong. The write-back path is the part I'd most like to hear about breaking.

shadcn/ui says the code is yours. So why can't anything edit it?

Jack Lee — Mon, 21 Sep 2026 12:01:00 +0000

~9 min read

shadcn/ui's whole pitch is that it isn't a dependency. You run the CLI, the component lands in components/ui/button.tsx, and it's yours. No package to upgrade, no wrapper to fight, no !important war with someone else's stylesheet.

Which raises a question nobody asks out loud: if the code is mine, why is hand-editing the only way to change it?

Not a rhetorical complaint. There's a real technical answer, and it isn't the one you'd guess.

Visual editors assume a prop table. shadcn doesn't have one.

Every visual React editor I've looked at makes the same bet: components arrive from a package, and that package has a documented, stable prop surface. MUI is the ideal case. <Button variant="contained" size="large" color="primary"> — three enums with known values. A tool can read the type, render three dropdowns, write back a string. It works because the component is a black box with a labelled control panel bolted to the front.

Now open a shadcn button.

const buttonVariants = cva(
  "inline-flex items-center justify-center rounded-md text-sm font-medium ...",
  {
    variants: {
      variant: {
        default: "bg-primary text-primary-foreground hover:bg-primary/90",
        destructive: "bg-destructive text-destructive-foreground ...",
        outline: "border border-input bg-background hover:bg-accent ...",
      },
      size: { default: "h-10 px-4 py-2", sm: "h-9 px-3", lg: "h-11 px-8" },
    },
    defaultVariants: { variant: "default", size: "default" },
  }
)

There's no prop table. There's a variant map — written in your repo, in plain TypeScript, in a file you own.

The standard read is that this is worse for tooling: no types to introspect from a package, no docs to scrape, everyone's copy drifts. And it's true that you can't point a package-shaped tool at it.

I think the opposite conclusion is the right one. A CVA map is strictly more information than a prop table, and it's information you already have on disk.

A prop table tells you variant accepts "contained". It does not tell you what "contained" does. That's compiled into the library. To find out, you read the docs, or you guess, or you try it.

The CVA map tells you variant: "destructive" is bg-destructive text-destructive-foreground. The mapping is right there, as data, in source you control. Nothing is hidden, because nothing was ever packaged.

So the argument is simple:

Structured visual editing needs to know what a control does, not just that it exists.
With a package component, that knowledge lives in the library's compiled internals.
With shadcn, it lives in your repo as a literal object.
shadcn should be the easiest component library to edit visually, not the hardest.

Instead, the thing I can't find anywhere is structured variant editing driven by your CVA map, in your repo. Visual editors for Tailwind exist, and theme editors for shadcn exist — but a theme editor rewrites CSS variables, which is a different job: it changes what bg-primary resolves to, not which variant a button is using or what that variant is made of. The obstacle to the second one turns out to sit a layer below variants.

The obstacle: shadcn's styling is class names, and class names need a build step

MUI styles at runtime. sx={{ p: 2 }} becomes CSS while the component renders — nothing precomputed, nothing to scan. MUI in a browser with no build step is plenty of work, but none of it is styling work: it's module resolution, keeping emotion and the theme as true singletons, and shipping a coherent set of package versions (we vendor eight MUI-related builds across three version tiers for exactly that reason). We wrote about that side here. Once the modules resolve, the styles take care of themselves.

Tailwind works the other way around. It scans your source files, sees which utility class names appear as text, and generates exactly those rules. No scan, no CSS. And "scanning source files" is a build step.

So for a tool that renders a real project in the browser with no install and no dev server, shadcn presents a wall that MUI never did. You can compile button.tsx perfectly and get an unstyled button. The class names are all present in the DOM and mean nothing, because nothing generated the rules.

That's the actual reason visual tooling stops at the door. Not variants. Styling.

There's a sharper version of the problem, too. Tailwind's scanner reads source text. But shadcn components don't have class names in source text — they have a function call:

<button className={cn(buttonVariants({ variant, size }), className)} />

There is no string "bg-destructive" anywhere in that line. It's assembled at runtime from the CVA map, the incoming props, and whatever the caller passed.

In a normal build this is handled, and handled well: the variant map file gets scanned too, the literals live there, and the extractor sees them. (Worth saying plainly, since it gets garbled a lot: Tailwind's rule is don't construct class strings like `text-${color}-500`. CVA variant maps hold complete literals. shadcn is the recommended pattern, not a workaround, and it needs no safelist.)

In a browser with no build step, there is no scanning pass at all — so there is nothing to handle it. That's what makes this version of the problem sharper rather than the same problem again.

What we did instead: collect classes from the DOM, not from the source

The fix is to stop scanning source entirely.

Studio runs Tailwind's real browser engine — the official one, not a reimplementation. The version is picked from what the project declares: v3 projects get Tailwind's Play CDN engine, vendored in the app rather than fetched from the CDN; v4 and up get @tailwindcss/browser, likewise vendored. A remote fetch happens only when no vendored build matches the declared major — a v5 project, say. Your tailwind.config is fed to the engine, so your theme extensions are the ones in effect.

The obvious question here is why not run Tailwind's own extractor in the browser and scan the source after all. We measured what that costs: one render already issues somewhere between 40 and 340 file reads on the host side, and on a large template a single read runs 5–8 ms with no throughput gain from concurrency. Scanning the repo means reading every file instead of the ones that render. And after paying for it you still miss class names that come from runtime data. Collecting from the DOM isn't the lazy option — it trades "read the whole repo" for "read the result once."

Running the engine gets you halfway. Then the interesting problem shows up.

The engine is document-scoped and only observes light DOM — it calls observe(document.documentElement) and never touches shadow roots. Studio's design mode renders the template inside a shadow root, for isolation. So the engine looks at the document, sees none of your component's class names, and generates nothing. Correct engine, correct config, zero output.

What bridges it:

After render, walk the shadow DOM and collect every class token actually present on actual elements.
Write those tokens into a hidden sink element in the light DOM, where the engine can see them.
The engine generates rules for exactly the utilities in use.
Adopt the resulting stylesheet back into the shadow root.
A MutationObserver on the shadow root — subtree, attributeFilter: ['class'] — catches everything that appears later: route changes, lazy content, anything conditional.

One detail worth flagging because it cost real time: the sink must be inserted with native appendChild. The canvas patches document.body.appendChild to redirect portal content into the shadow root, and going through the patched version buries the sink inside the shadow root — where the engine can't see it. The bridge then fails silently, which is the worst kind.

The sink is a real node in the light DOM, and it keeps filling as you use the app — switch routes and the classes the new page needs show up in it, without a reload.

There's a second gotcha like the first one. It's not a shadcn thing — it comes from other templates we render — but it's the same failure shape. Tailwind v3 templates built on Next often set important: '#__next' in their config, scoping every utility under the app's root ID. That ID doesn't exist in the canvas, so every utility silently fails to match. The config's selector gets redirected to the live render root — and the replacement has to also be an ID selector, because the (1,0,0) specificity is doing load-bearing work against the template's own CSS.

The payoff for doing it this way:

Because collection happens from the DOM instead of the source, any class name assembled at runtime works. cn(), clsx, twMerge, CVA, a ternary, a lookup table, a class name built from a prop by string concatenation — the engine never has to understand any of it. By the time collection runs, the composition already happened and the result is sitting in a class attribute. shadcn-admin renders correctly not because we special-cased shadcn, but because this approach is indifferent to how the string got there.

The honest limit: only classes that have actually rendered get generated. A real Tailwind build scans source, so it emits both branches of cond ? 'bg-red-500' : 'bg-blue-500' even though only one can be on screen. Here the untaken branch has no CSS until it renders. The MutationObserver fills it in when state flips — but that means the frame where it flips can be unstyled. In practice you see it as a brief flash on the first toggle of a variant you haven't hit yet.

It cuts the other way too, which is why I'd call it a tradeoff and not a deficit. Take statusColors[res.status], where the key arrives from an API response. No complete utility literal exists anywhere in the source, so a scanning build generates nothing for it — this is the case safelists exist to paper over. DOM collection doesn't distinguish it from anything else; by the time we look, the class is on the element. Source scanning gets you branches that haven't run. DOM collection gets you class names that were never written down. You pick which one you'd rather have, and in a browser the choice is mostly made for you.

Where this leaves the argument

So: shadcn-admin renders. A template built entirely on class names, CVA variants, and cn() composition, running with no install and no dev server, with the real Tailwind engine and your real config.

Which is worth something specific, and it isn't "visual editing."

Think about the last time you opened an unfamiliar admin template to decide whether to use it. You cloned it, installed it, waited, ran it, clicked around for four minutes, and closed it. Most of that time was the machine's, not yours. Now think about the last time you wanted to show a teammate what a component looked like in three states, or check whether a template's dark mode was actually finished, or figure out where a card's spacing came from before quoting a change. Same tax, every time, for a question that takes seconds to answer once something is on screen.

That tax is the thing that's gone. A shadcn project renders in seconds with its real classes, and then everything Studio does that isn't styling-specific works on it: selection that goes both ways between code and canvas, drilling into a component defined five files away, seeing what breaks if you delete a file. Those operate on your code, not your styles, so they never cared which styling system you picked. They just needed the thing to render first.

What's still missing is the styling side of the inspector: className is edited as a string like any other prop, nothing reads your CVA map to build variant controls, and your tailwind.config tokens reach the engine but not the panel. The MUI side has a theme editor and a structured sx tree; the Tailwind side has none of that yet. I'd rather say so than let a demo imply otherwise.

But that ordering is the actual point, and it isn't obvious from outside:

shadcn's styling is class names, not props.
So correctly rendering runtime-composed class names is the prerequisite for editing them in any structured way.
That prerequisite is genuinely hard in a browser, because the engine only sees light DOM and design-mode rendering happens in a shadow root.
The class bridge solves it by collecting from the DOM rather than the source.
The prerequisite is now in place.

What sits on top of it is a smaller problem than what's underneath, but not a trivial one, and I don't want to wave at it. A CVA map is a literal object in a file you own; reading it and rendering a variant selector is ordinary work. Writing the change back is not. A class name can arrive from three composition sites at once:

className={cn("border-b", isActive && "bg-red-500", buttonVariants({ variant }))}

Set padding to 6 in a panel, and something has to decide which literal to edit — the base string, the conditional, or the variant definition that every other button on the page also uses. Sometimes there's no correct answer, only a policy. That's the next real problem, and it's hard in a different way than this one was.

If you'd asked me before starting which half would be hard, I'd have guessed wrong.

If you work in shadcn and have opinions about what that control surface should look like — variant dropdowns driven by the CVA map, spacing controls that rewrite utilities rather than inline styles, a rule for which literal a write-back should land in — that's a conversation I'd like to have before building it rather than after. Studio has a free tier; point it at a shadcn project and tell me where it's wrong.

Every React instructor has drawn this box diagram. Let's go further

Jack Lee — Mon, 14 Sep 2026 12:01:00 +0000

You finish teaching props. You drew the box diagram, you gave examples. And they got it — you ask a question in class, they answer it fine.

Next week, in the homework, the same student asks: "how do I know where this total comes from?"

He didn't forget what you said. He knows what props are. He just can't call on it inside real code.

The box diagram got him to "I understand." It doesn't reach "I can use it." That part was never in range of an explanation.

The thing I want to say first

Your teaching is fine. They really do understand.

The problem is the next step. There's a distance between understanding and using, and that distance doesn't close with a better explanation.

props, context, .map(), conditional rendering, module structure — these are relational, not factual. "useState returns an array" is a fact. Say it once, done. "This line of JSX corresponds to that thing on screen" is a mapping. Mappings only get built by matching them up, over and over.

You can explain a mapping beautifully. They'll understand it. But understanding a mapping and being able to call on it instantly are two different things.

This isn't about teaching skill. Explanation has a ceiling, and the ceiling is at "understand." Getting past it takes reps from the student — and whether they get reps depends on whether they have something they can poke at.

So: four places this shows up every term. In all four, the students understood you. They still got stuck.

One: your first class gets eaten by environment setup

Thirty people. The lesson plan says "get a React project running."

What actually happens: five have the wrong node version. Three hit npm permission errors on Windows. Two are behind a corporate network that won't install packages. One installed nvm into the wrong shell config. You spend forty minutes doing tech support and the last twenty rushing through half your material.

What it actually costs you:

Your class time goes to something that has nothing to do with React. And you pay it again with every new cohort.

You end up maintaining a setup guide doc. Every time node, npm, or vite moves, you update it. Unpaid, forever.

You can't assign "go run this at home," because half the class gets stuck and then your weekend is answering setup questions.

And the quiet one: you filtered people out in week one, on a criterion that has nothing to do with React. The ones who dropped weren't bad at React. They just couldn't get an environment running yet. But they'll read that failure as "I'm not cut out for this."

What changes it: opening a real project costs about as much as opening a webpage. No install, no dev server — the compile happens in the browser, so there's nothing on their machine to go wrong. Which means the goal of your first class can actually be "read the structure of a real project" instead of "get thirty laptops to agree with each other." (how that works)

Someone always asks: so they never learn to set up an environment? They do. But setup is a standalone skill you can teach in week five, on purpose, with your attention on it. Putting it in week one as a gate is just a sequencing mistake.

Two: they understood props. They still can't use props.

A student can read <AnalyticsWidgetSummary total={714000} color="warning" /> and tell you what every part does. He can define props correctly.

Ask him what happens if you change total — he pauses. Ask where color="warning" is actually defined — he has no direction.

He's not confused about props. The mapping just isn't reflexive yet.

Here's why explanation tops out here, and I think this is the real point of this whole post:

A diagram is you doing the mapping for them. They see the result, they understand that it holds, but they never walked it themselves.

It's the gap between reading a translation and being able to translate. Passive understanding and active recall run on different tracks. The first doesn't automatically become the second.

And there's a counterintuitive bit: the clearer you explain it, the easier it is for them to stop at "I get it" — because the quality of your explanation saved them from having to build the mapping themselves.

So investing more in making the explanation better returns less and less. Not because the method is wrong. Because that road ends there.

Which is why you keep building fancier analogies for the same concept and the results don't scale with the effort. Your part is done. The missing part isn't on your side.

What changes it: click code, the canvas highlights. Click the canvas, the code highlights — the exact JSX node, not the general area. That's not impressive technology; it's that it turns one thing you said into forty things they did. (the mechanics of that)

Something you can use next week: before you define props abstractly, have them do twenty clicks. Let them notice on their own that this text corresponds to that pixel. Give the concept its name after the operation, not as setup for it.

And the obvious objection: won't they get dependent on the tool and never learn to find files? Depends on whether the tool shows the path. If it silently navigates for them and they never look, sure, that's a crutch. If it shows the component chain it walked and which file each layer lives in, then they're seeing real structure over and over until it stops being mysterious. That's training wheels.

Three: three concepts, three lessons, everyone half-gets each one

.map(). Student asks how to change the third card. You say you're changing the template, not the third card. He understands the sentence. But his eyes see five separate cards. Accepted intellectually, not built as intuition.

Conditional rendering. He writes isVip ? A : B, then spends twenty minutes debugging branch B. His test data always goes down A. He's debugging code that isn't running, and he doesn't know it.

HOCs. He sees withAuth(withTheme(Card)) and asks what the component is. There's no single answer — it depends which layer you mean. You can say that clearly. You can't make him walk each layer himself on a whiteboard.

Here's the useful part: those three look like three different teaching problems. They're one. What's missing isn't three pieces of knowledge. It's one piece of meta-knowledge — the rendered result and the source structure aren't one-to-one, and I need to know which layer I'm looking at.

What it costs you: you treated them as three topics, built three explanations, spent three lessons. All three explanations were correct. They all understood. But the conversion to "can use it" was low on all three, because the missing piece was the same operation, not three explanations.

What changes it:

.map(): click the second card, the code selects the map expression — because there genuinely is no "second card" in the source — then drill one step further into the template inside it. They watch five things come from one line. Reverse it: cursor on the map expression, all five cards light up at once.

Conditional rendering: put the cursor on the branch that isn't currently rendering, and the canvas renders that branch on its own. No state changes, no fake test data. That student debugging for twenty minutes figures out what he's doing in two seconds.

HOCs: climb the layers one at a time, definite answer at each. "What is this component" becomes a question you can answer layer by layer. (more on how the layers are defined)

Something you can use next week: collapse three lessons into one, called "layers." Let them drill up and down first, bump into the concept themselves, then name it.

Four: they don't know what to be careful with

Students go one of two ways. Either they won't touch anything (afraid of breaking it), or they'll touch anything (no idea what it's connected to). Both make homework hard to grade — one turns in nothing, the other turns in collateral damage.

Why explanation can't quite reach this: importance isn't a static property. It's a relationship — how many things depend on this. You can accurately say "some files are more critical," and they'll agree, and it won't help them when they open an unfamiliar repo. They need a specific answer about a specific file.

What they actually need isn't being told a file is important. It's seeing eleven references light up when they change one file. Specific, countable, located. That's when importance stops being an adjective.

And here's the part I'd care most about if I were teaching: this instinct decides whether your students can handle an unfamiliar codebase after graduation. The confusion in someone's first two weeks is almost never "I don't know React." It's "I don't know where anything lives in this repo." Someone who can trace an import chain and check inbound references can onboard anywhere. Someone who only knows hooks can onboard onto the one repo they were taught on. Which of those you're producing decides how rough their first job is.

What changes it: inbound edges give that signal a shape you can point at, and they can practice it on file after file — including the references that arrive through a barrel, which a plain editor search doesn't catch. There's an even better classroom move: break an edge on purpose. Rename an export, watch which part of the graph goes red. Targeted breakage teaches faster than a correct example. (what building that graph involves)

Worth mentioning: one of the most stubborn beginner misconceptions is that an import path tells you where the code lives. Jump through three barrels in one hop to the real definition and that misconception dies immediately.

One rule you can run your syllabus through

The four pains look unrelated — a psychological gate, a visual mapping, structural layers, relational reasoning. Underneath they're the same thing:

If a concept is fundamentally a relationship or a mapping, explanation gets them to "I understand." The rest of the way to "I can use it" only happens by doing it ten times themselves.

So, a test you can apply to your own outline:

Can students use this correctly right after understanding it? Yes → factual. Explanation is the whole solution.

Or do they still need a few tries to get comfortable? → relational. Your explanation already did its job. What's missing is somewhere for them to try.

Most of the hard parts of React are the second kind. Which is why a genuinely good instructor still ends up feeling like students "know it but can't quite use it." That stretch was never in range.

Four things you could change next week

Make the goal of class one "open a real project without being scared of it." Move environment setup to week five and teach it properly.

Before defining props, twenty clicks. Name the concept after.

Merge .map(), conditional rendering, and HOCs into one lesson called layers. Operate first, name second.

Before teaching context, have them delete a provider in a real project and see what breaks and where. Then explain why it's needed.

Not replacing your explanation. Adding the part after it.

If you've taught React for a few years and students land in the same four spots every time — understood it, can't quite use it — that isn't a quality problem with your teaching. The box diagram did its job. It got them to "I understand."

The rest of that distance doesn't need a better diagram. It needs the student to have something they can try ten times themselves.

The four things above — opening a real project with no setup, clicking between code and canvas, drilling through layers, seeing what depends on what — are all things we built into CrossUI Studio, mostly for other reasons. Each one links out to its own writeup above if you want the details. Free for classroom use; if you're teaching a cohort and want it set up, get in touch.

Vibe coding made writing cheap. It made reading expensive.

Jack Lee — Mon, 07 Sep 2026 13:20:52 +0000

A junior I know shipped a change last month. Cursor wrote it. He ran it. Looked fine. Opened the PR.

Senior sent it back in five minutes: "this touches three things we don't have tests for."

He had nothing to say. He didn't write the code. It looked right. He genuinely didn't know what he'd missed — or where you'd even start looking.

He's not dumb. Nobody ever showed him what sits between "looks right" and "I checked."

The myth first

People keep saying AI made writing code free.

It didn't. Tokens cost real money. Run agents in a loop on a decent-sized repo for a week and go look at your bill. Nobody who's done that thinks generation is free.

What AI actually did is narrower than the hype. It made producing a plausible diff fast. It did exactly nothing for the hard part — knowing whether that diff is safe.

So the cost didn't vanish. It moved. Writing got cheaper. Reading got brutal, because now there's ten times more of it and none of it is yours.

Nobody teaches reading

Think about how we train people. Syntax. Hooks. Build a project. All production.

Then they get a job where most of the day is reviewing changes they didn't write, and we act surprised when they can't.

Most people file "can spot a bad change" under experience. Years of it. Can't teach it, you just earn it.

I don't buy that. I've watched enough seniors do it to see it's not magic. It's four moves.

Locate. Which element on screen does this actually affect? Not roughly. Exactly which JSX node.

Trace. Is this a shared definition, or one call site? Shared means everything using it. Call site means just here. This one question decides whether the next move matters.

Blast radius. If shared — who uses it? How many? Any references hiding behind a barrel or an export *, where your editor's search just doesn't look?

Run it. Does it render what you expected? Including the branch that isn't on screen — the other half of that ternary.

Four moves. All teachable. None taught.

"We have tools for this"

Do we? Let's check.

TypeScript catches type mismatches. But AI's signature move is code that types perfectly and sits in exactly the wrong place. Add a legal optional prop to a shared component. All green. Three of five call sites now render a UI element that shouldn't be there.

Unit tests only cover what someone already thought about. The danger with an AI change is that it landed on a call site nobody thought about. Which almost certainly has no coverage — that's the state of UI testing everywhere, not one lazy team.

Storybook, visual regression. These tell you something changed. Never why. Alarms after the fact, and only for components someone bothered to write a story for.

And then the diff view. This is the real problem, and it hides in plain sight.

A diff shows you text. It shows you nothing about position or reach. Three lines feels safe. Three hundred feels scary. And that feeling has zero connection to what either one actually breaks.

Sit with that for a second, because it's the whole thing:

Diff size and blast radius are unrelated. Human alarm scales with diff size anyway.

A three-line change can hit eleven files. A three-hundred-line refactor can be perfectly contained. Your gut has it backwards, and vibe coding means you now get to be wrong about this several times a day.

"Fine, better models will fix it"

Probably not. And not for the reason people assume.

The model sees a window. A few open files, some conversation. From inside that window everything looks isolated. Almost nothing in a real repo is isolated.

Look at what AI actually gets wrong. Same three patterns, forever:

Thinks it's editing one instance. Actually editing the shared definition. Five other places quietly change.

Imports through a path that isn't what it thought, because two barrels sat in between.

Edits a branch that your case doesn't even go through, so the change never renders at all.

None of those are syntax problems. They're all where does this line sit in the system problems. Position. And position is not something a language model has good intuition for. A bigger context window is not a map.

Someone always replies: so give the model the graph. Fair, and we do. It helps.

But two things survive. First, shipping a change is a responsibility question, not an information question — when the AI says "safe," someone still has to be able to check that, or you're trusting a system that bears no consequences. Second, the map has to exist before you can hand it to anyone. Build it first. Then argue about who reads it.

Why good engineers skip the checks anyway

Here's the part that took me a while to see.

The four moves aren't hard to understand. Everyone nods along. And then they don't do them.

Not laziness. Cost.

Locating means eyeballing a wall of JSX hunting for which part of the UI this touches. Inside a .map(), inside a conditional, in a component from another file — that hunt is half your review.

Blast radius means three greps, two of which return false hits from a string match, and none of which catch the reference coming in through a re-export.

Running it means switching to a terminal, maybe installing whatever the AI just pulled in, waiting for a build, waiting for a dev server. Two or three minutes to verify a two-second change. So people read it, decide it looks fine, and ship. That's not a discipline failure. That's an entirely rational response to an absurd ratio.

Layer awareness means rebuilding a component's whole structure in your head. At 6pm. On the fourth PR of the day.

Which is why a better PR template doesn't fix this. A template tells people what to check. It does nothing about what checking costs — or whether the answer you get back is even right.

So we made the checks cheap

But cost was only half of it. The other half is worse.

Even if you're willing to spend the half hour, some of these questions your tools cannot answer correctly.

Run a Find All References on a component in a real template. It returns what it indexed. It does not return the reference that arrived through an export * in a barrel file — there's no textual match to find, and the indexer didn't resolve the chain. You get a list. The list looks complete. It isn't, and nothing tells you that.

So when someone does the diligent thing — greps it, checks the callers, decides it's contained — they can be diligent and wrong at the same time. That's the failure mode that actually bothers me, more than the people who skip the check entirely. At least skipping feels like skipping.

That's the reason CrossUI Studio exists. Not to run the same checks faster. To make a couple of them answerable at all.

Locate is one click. Click the thing on screen, land on the exact JSX node that drew it — through the .map(), through the conditional, through a component defined in a different file. Works backwards too: cursor on a line, and everything it draws lights up on the canvas. Put the cursor inside a .map() and watch eight cards light up at once. That's the whole "one line, many elements" idea, no explanation needed.

Trace is shown, not reconstructed. Click again and you climb: this expression, then the component call, then the call site that passed the props, then the file the component actually lives in. "Shared definition or one call site" stops being a thing you work out in your head. It's just on screen.

Blast radius is a resolved graph, not a text search. We resolve imports the way a bundler would — through barrels, through path aliases, through export *. So "who imports this" returns the references a string search structurally can't reach. Fast is a side effect. Complete is the point.

Running it is instant. No install, no bundler, no dev server. Open a real repo, it renders in the browser. And that branch that isn't on screen? Put your cursor on it and we render it for you. No faking state, no editing test data to see what a VIP sees.

Two of those make a slow check fast. Two of them make a question answerable that wasn't. The second kind is the part I'd care about if I were choosing a tool.

What that looks like in practice

You ask AI for a discount badge on the product card. It adds a conditional inside <ProductCard>. Clean diff. Runs. No errors.

Click the badge. You land inside a .map() — so this isn't one card, it's every card in the list.

Climb up one layer. <ProductCard> is a shared definition. This page doesn't own it.

Check who imports it. Three places: cart, favorites, search results. Search results has no discount field at all.

Open search results, cursor on the new branch, render it. There it is. Empty badge, alignment broken.

Under a minute. No build. Without those four moves that diff merges clean and you hear about it from a user.

The team version of this problem

One more thing, because individual judgment isn't a process.

When half your team runs these checks and half doesn't, whether a bad PR gets caught depends on who got assigned. That's worse than a uniformly weak team, because it looks like something is working.

And it caps how hard you can lean on AI. Without this, you've got two options: throttle AI usage, or accept an incident rate you can't predict. Neither is a strategy.

The uncomfortable version for anyone teaching this

Same problem, one step earlier.

If a junior's day is mostly reviewing code they didn't write, then "hand-write a TodoList" is training the wrong muscle.

Better assignment: here's an AI-generated diff. It runs fine. Something in it is wrong. Find the real blast radius and show your work.

Build the material from the failure patterns above — bait diffs, tiny in lines, huge in reach. Train people out of trusting line count.

Not saying skip learning to write code. Someone who's never hand-written a .map() or been burned by conditional rendering can't judge either. Writing is the floor judgment stands on. It just isn't the whole building. (More on the teaching side in a separate post.)

Where this leaves us

The bottleneck moved. Writing is cheap now. Reading is expensive — and part of it isn't just expensive, it's guesswork wearing the clothes of diligence.

That's the piece I'd want closed before leaning harder on AI. Not because review takes too long. Because "I checked" should mean something.

If you want to try the four moves on something real: CrossUI Studio opens an actual React repo in the browser, no install. Click something and see how far down it goes.

Drill down. All the way — even when the real code is five files away

Jack Lee — Mon, 31 Aug 2026 12:01:00 +0000

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?

No npm install. No dev server. A faster way to iterate on React UIs?

Jack Lee — Mon, 24 Aug 2026 12:01:00 +0000

You've done this a hundred times. Clone a template. npm install. Wait. Maybe a peer dependency fight. Fix the node version. Install again. Start the dev server. Wait for the first compile. Now you can finally look at the thing.

Nobody complains about this anymore. We just accept it as the cost of looking at code. But if all you wanted was to glance at a component or tweak one prop, that whole ritual is wildly out of proportion to the task.

So — why does "look at this code" require an entire toolchain as a prerequisite?

That whole ritual was invented, not required

Browsers have been able to run JS forever. Running was never the hard part. Compiling is the hard part — JSX isn't valid JS, TypeScript annotations aren't valid JS, both need translating first.

The standard answer puts that translation on your machine, in your terminal, through a bundler running on Node, and it hands the browser a finished file afterward. That's a historical accident, not a law of nature. Browser-side compilers just weren't mature when this pattern got set. Node was there first.

If the compiling itself moves into the browser, the whole chain in between just goes away.

Putting a compiler in the browser is harder than it sounds

Parsing TSX isn't free. A real template is hundreds of files. Full type-checking on the main thread would lock up the UI. You have to decide what's actually needed to render — mostly that means syntax transforms and type erasure, not a full type-check on every keystroke.

There's no filesystem to resolve against. Node's module resolution assumes a real disk, a real node_modules, package.json exports fields. In a browser you're simulating all of that in memory — path aliases, workspace protocols, conditional exports, the works.

Where do the packages even come from? A template depends on real npm packages — MUI, shadcn, whatever. You can't ask the user to install first. Either resolve real package versions off a CDN, or pre-bundle the common ones — and match whatever's actually pinned in that template's package.json, or the render won't match the real project.

Some plugins assume they're running in Node. Build-time babel plugins, emotion's compile-time optimizations — a fair number of templates lean on these. You either reimplement the effect in the browser or find a runtime equivalent. Neither is free.

Recompiling everything on every keystroke would be miserable. You need module-level caching and invalidation — only the file that changed, and whatever depends on it, gets rebuilt.

Source maps have to survive the whole trip. Errors, breakpoints, and any node-level mapping have to point back to your actual source line, not some transformed mess. That has to hold end to end, not just at one stage of the pipeline.

None of this is exotic. It's just what a real React template looks like once you actually try to run it without Node standing in the middle.

What we gave up to get here

Being upfront about the tradeoffs, because a piece claiming none is a little suspect.

Not every build-time plugin gets covered — projects leaning heavily on custom webpack/vite codegen plugins are only partially supported right now. Big monorepos have a real compile cost on first load, incremental after that, but not instant the very first time. And this isn't a replacement for a production build — production still needs a real build tuned for tree-shaking and performance. This is a tool for looking and editing, not a deploy pipeline.

Why this is the floor the other two pieces stand on

SCD(Symmetric Collaborative Development) selection needs position info injected at compile time, and a live index kept in sync with it. If compiling happens in some black-box bundler on your machine, there's no place to slot that in. Owning the compiler means owning every step of it, so the index can live inside the pipeline instead of bolted on after.

The dependency graph needs imports resolved live, as you edit — not from some static analysis script run once, offline, drifting out of sync the moment you touch a file. A browser-side compiler means the graph updates incrementally, with you, instead of "run the script again."

Neither of the other two pillars gets to be real-time without this one underneath it. It's the least visible of the three, and the one everything else depends on.

What this actually looks like, side by side

Old way: clone, npm install (thirty seconds to several minutes depending on the day, longer if peer deps fight you), sort out the node version, start the dev server, wait for the first compile.

New way: open the file.

The gap isn't "faster." It's a different category of thing. One is running a project. The other is opening a file. Your brain never has to switch into "this is an engineering task" mode just to look at a card component.

We've already shown this holding up on real templates — Material Kit React, shadcn-admin — where "open it and it renders" isn't a demo trick, it's just what happens.

What this means for teaching React

Environment setup is where most tutorials lose people. A lot of beginners hit an npm install error before they've written a single line of real React, and they walk away — and that has nothing to do with whether they could've learned the material.

Zero-infrastructure flattens the gap between "open a real template" and "open a CodePen." A student can touch actual production-shaped code in the first session instead of waiting out a whole week of environment setup first.

For instructors it kills a specific nightmare: half the room stuck on a different Node version, a different OS quirk, a different peer dependency error, each one eating fifteen minutes of class time that had nothing to do with React.

What this means for pairing with AI

The part of AI pairing nobody talks about is the loop after the generation — you get a diff, and now you have to actually run it to see if it's right. The old loop: switch to a terminal, maybe install something new the AI just pulled in, wait for the build, wait for the dev server, then look. Call it two or three minutes per round trip, easily.

Cut the compile step out and that loop collapses. The AI finishes, you open it, it's already rendered — no waiting stage in between. That turns human-AI back-and-forth into something closer to real-time instead of something metered out in build-times. If the AI keeps getting faster and the human verification step doesn't, all that generation speed just evaporates into the wait.

There's a second-order effect too — an AI agent itself can look at a render in this environment and self-check (screenshot, check for errors) without spinning up a whole build chain inside its own sandbox first. This isn't just saving a human's coffee break. It's infrastructure for the "AI writes code, then checks its own screenshot" loop that's already how a lot of people work now.

Three questions for any tool claiming to skip the build

Open a template you've never seen. Do you have to run a single command line command before you see it rendered?
Change one file, one line. Does that mean waiting for a full recompile, or does it just... update?
When something breaks, does the stack trace point at your actual line, or at some scrambled, transformed mess three layers removed from what you wrote?

What breaks if I delete this file? React tooling can't answer that.

Jack Lee — Mon, 17 Aug 2026 14:20:24 +0000

You want to delete a file.

A quick search shows three direct imports. That's easy enough to see.

The harder question is what those three files are used by.

One may be a layout dependency. Another may be part of navigation. A third may feed a page that doesn't look related at first glance.

So the real question isn't "Who imports this file?"

It's "What breaks if I remove it?"

Most tools don't actually keep a dependency graph around as something you can ask questions of. They keep a list of files and a pile of text search. That's not the same thing.

A component tree is not a dependency graph

People mix these up a lot, so worth separating.

Component tree: who renders who, at runtime. Parent to child. React DevTools shows you this one.

Dependency graph: who imports who, at compile time. Directed, sometimes has cycles, crosses files and packages freely.

They're not the same shape. A provider might be a distant ancestor in the component tree, but in the dependency graph it's just one edge coming off main.tsx. You debug with the component tree. But when you're actually changing code, the thing you're navigating is the dependency graph — and that one's never had good tooling.

What a real graph actually looks like

Here's why building this is annoying, not fun-annoying, actually annoying:

Barrel chains. @/components → components/index.ts → chart/index.ts → chart-widget.tsx. Three re-exports before you hit real code. Do you keep those middle hops as nodes in the graph? Keep them and it's noisy. Collapse them and you lose the truth of what's happening. We keep the edges, mark them transitive, and let you collapse the view when you don't care.

Path aliases. @/, ~/, whatever a monorepo's workspace protocol wants to call itself this week. The resolver has to actually understand the build config to draw the right edge, and the build config itself is sometimes three files stacked on each other.

export * ambiguity. Same symbol name coming in from two barrels, and which one wins depends on order. The graph has to remember that order or it's just wrong.

Dynamic imports. React.lazy(() => import('./Page')). Static analysis can see it, but it's an edge that only activates at runtime. Should probably be a dashed line, not a solid one.

Type-only edges. import type doesn't exist at runtime. Delete that file and your app still runs, but tsc breaks. Two different kinds of edges, same graph.

Cycles. Real repos have them constantly, plenty of them harmless. The graph has to represent that, not fall over.

None of this is exotic. It's just Tuesday in a real repo.

Making the graph answer questions

The point isn't "look, we drew a graph." The point is what you can ask it:

Resolve-through — give me the file this import actually lands on, skip every barrel in between, one hop.

Inbound edges — who references me? If I change this file, what screens does it touch? This is the actual answer to that opening question.

Reachability from entry — can you get here from main.tsx at all? If not, it's dead code, or only a test imports it.

Shortest path between two nodes — how does this page even use that util? The path itself is the explanation.

Cut vertices — which files are chokepoints, where one change ripples everywhere? That's an objective basis for refactor priority, not someone's gut feeling.

None of this is a visualization trick. It's turning engineering instinct into something you can actually ask and get an answer to.

The graph is never complete, and that's fine

Real repos always have holes — a missing peer dep, an optional import, an alias nobody set up, a file that flat out doesn't exist anymore.

Two ways to handle that. Throw out the whole graph the second one edge fails to resolve, which is what most tools do. Or mark that edge unresolved and keep building the rest of the graph around it. We do the second. An incomplete graph you can still navigate beats a complete-or-nothing graph every time. (We wrote about the mechanics of that specific move — bypassing a broken import instead of stopping — in an earlier post, if you want the deep dive on that one piece.)

Graph plus symmetric editing

This is where the two pieces click together, and it's the part that's genuinely hard to copy.

Symmetric editing gives you precision inside one node — this thing on screen maps to exactly this AST node. The dependency graph gives you reach across nodes — this AST node's position in the whole repo's topology.

Put together: click a card on screen, and you don't just land on its JSX. You get its full path back to the entry point — through the route, the view, past three barrels, to the real file — plus who else depends on it. A precise map with no way to zoom out is just a precise island. A zoomed-out map with no precision is just a picture. You need both to actually navigate.

Why this matters more now that AI writes half the code, not less

The instinct is that once AI writes your code, you stop needing to understand structure. It's actually the opposite.

The mistake AI tools make most often is a graph mistake — importing something that doesn't exist, or not noticing a util is already used in five places and changing it breaks all five. The model sees a local window of tokens. It doesn't see the topology.

The part of the job that's left for a human is exactly "is this change safe on the graph" — inbound edges, reachability, cut vertices. That's precisely what a limited context window can't hold. So a navigable dependency graph isn't a nostalgia tool for people who refuse to use AI. It might be the one navigation skill a human still has to own.

And the gap in speed is not subtle. Working it out by hand means opening tabs, running greps, manually throwing out the false hits from a string search — that's minutes, and it's still sometimes wrong. A precomputed graph answers the same question, barrels and all, in milliseconds. Minutes versus milliseconds, and the minutes might be a wrong answer too.

A real walkthrough, with a sting in it

Say you're in Material Kit React and decide that logo.ts is no longer needed. Maybe the product has moved to a different branding component, or the logo is simply being removed from the application.

At first, it looks like a trivial deletion.

You check the graph and find three direct consumers: layout, nav, and not-found-view.

That's already useful. But the interesting part starts when you follow the upstream edges.

layout isn't the end of the story. It is itself used by higher-level application components. Follow that edge and you can see where the layout enters the application structure. nav leads into another chain of consumers. not-found-view comes through yet another path, eventually connecting back to the routing layer.

So instead of seeing:

logo.ts
├── layout
├── nav
└── not-found-view

you can keep walking:

     <higher-level page/router>
                 │
         ┌───────┴───────┐
         │               │
   layout.tsx        nav.tsx
   (import)           (import)
         │               │
         └──────┐ ┌──────┘
                ▼ ▼
              logo.ts
                  ▲
                  │
             (import)
        not-found-view.tsx
                  │
      <higher-level page/router>

The important question is no longer:

Who imports logo.ts?

It's:

What parts of the application are sitting above those consumers?

That distinction matters when you're deleting something.

A direct-reference search can tell you that three files need attention. It doesn't necessarily give you the context needed to understand where those three files participate in the application. You can easily remove the component, clean up the obvious imports, and still miss an affected path higher in the tree.

And that's where seemingly harmless deletions become expensive.

A shared component can sit low in the dependency graph while its consumers sit inside completely different application paths. One may affect the main layout. Another may affect navigation. Another may only appear on an error route that nobody happened to test locally.

Without the graph, the usual workflow is familiar: search references, make the change, run what you normally run, and assume the result is complete. The missing dependency may not surface until a particular route is opened, a rarely used state is rendered, or another developer hits the code path you didn't know existed.

With the graph, you can inspect those upstream paths before deleting the file.

You can see that logo.ts is not really an isolated file. It's a small node sitting underneath several higher-level parts of the application. That gives you the information needed to decide whether the deletion is actually safe, which consumers need to be changed, and how far the impact extends.

The file may take five seconds to delete.

Understanding what that deletion means is the real job.

That is the value of the graph: not merely finding references, but making the dependency footprint of a change visible before the change is made.

What this means if you're teaching React

Courses teach the component tree. The job is navigating the dependency graph.

Someone who can trace an import chain can onboard onto any codebase. Someone who only knows hooks can only onboard onto the one they were taught on.

The difference is simple: the component tree teaches you how the UI is assembled; the dependency graph teaches you how the codebase is connected.

That matters the moment something stops working.

A student sees a blank screen. Instead of guessing which component is broken, they can start from the component they were working on and follow its dependency chain. One import leads to another, then another, until the broken dependency becomes visible.

The graph turns:

“Something is broken.”

into:

“This dependency is breaking this path, which affects these components.”

That is a much more useful debugging skill.

It also changes how students learn unfamiliar codebases. They don't have to understand the entire project first. They can start from something they recognize — a page, a component, an import — and navigate outward through the graph. Each edge answers a concrete question: where does this come from, and what depends on it?

This is particularly valuable when the application itself can't help you. A broken import can prevent the UI from rendering, but it doesn't erase the source-level dependency graph. You can still trace the chain, locate the failure, and understand what is happening even when the canvas is dead.

And you can deliberately turn that into a lesson.

Rename an export in a "Shadcn Admin" template. Break an import. Watch the affected part of the graph change. Then trace the path back to the change that caused it.

Now students aren't just being shown a correct React example. They're learning how to investigate a system when their change causes something else to fail.

That's the real value.

The goal isn't to teach students another React API. It's to give them a way to enter an unfamiliar codebase, understand its structure, trace problems, and keep working when the obvious surface — the running application — stops telling them what is wrong.

And barrel traversal made visible, in one click, fixes one of the most persistent beginner misunderstandings there is: that an import path tells you where the code actually lives. It usually doesn't.

Three questions for any tool claiming to handle this

Can it jump through a barrel in one hop and land on the real definition?
Can it tell you who references a file, including references that came in through a re-export?
And when an import can't resolve, does it give up on the whole graph, or keep working with everything it can still see?

The ultimate debugging experience:

Can you hover over any file to see its import/export flow in real-time?
Does it trace a crash back to the exact broken file in the import chain?
Can you define custom interceptors to bypass failing modules and keep your app rendering?

Worth testing on whatever you're using now. We're not going to tell you what it'll find.

What this graph looks like on a real template

We ran this against a real, popular template, not a toy repo. Because the full dependency map is massive, click the image below to download the high-resolution version directly.

Material Kit React dependency graph

blog.crossui.com

Shadcn Admin dependency graph

blog.crossui.com

Two-way is not the same as symmetric

Jack Lee — Mon, 10 Aug 2026 12:02:00 +0000

Every visual editor for React says it's "two-way." Click something, see the code. Change the code, see the canvas update. Sounds symmetric. It's usually not.

Look closer at most tools and you'll find one side is doing real work and the other side is just watching. Design tool exports JSX once, and if you touch the code after that, good luck getting back in. Visual panel changes a prop, but it's writing to some in-memory state or a JSON config file, not your actual source. Sandbox previews your code fine, but try clicking on the rendered output to jump back into the file — nothing happens, it doesn't even know what produced that pixel.

Two-way, but not symmetric. There's always a first-class side and a side that's along for the ride. You can sort most of these into three buckets.

Export-once. Design tool spits out JSX one time. Nice for the first commit. Then someone edits the code by hand — which happens on day two, always — and the tool has no way back in. Round trip is a one-way trip wearing a costume.

Runtime-overlay. The visual panel changes something, but it's changing an in-memory prop or a config JSON, not the file. Refresh the page and it's gone, or it lives forever in a second file that now has to stay in sync with the real one by hand. Your code isn't the truth here. Some other file is.

Preview-only. CodeSandbox, StackBlitz, plain Vite HMR. Great at showing you the code running. Click on the rendered thing though — nothing happens. It doesn't know what produced that pixel, because nobody ever built that link.

We built something different for CrossUI Studio. We call it Symmetric Collaborative Development, SCD for short. The idea is simple to say and annoying to build: code and canvas are two views of the same AST. Neither one is the source of truth that the other has to catch up to. Both can read, both can write, and both write to the exact same place.

What "symmetric" actually has to mean

Marketing copy loves the word "two-way." I want to make it testable instead. Three things have to be true, or it's not symmetric, it's just two-way-ish.

Selection has to go both directions, cleanly. Click any element on the canvas, it resolves to exactly one AST node. Click any JSX node in the code, every rendered thing it's responsible for lights up on the canvas. Not "usually works." Both directions, every time.

Editing has to go both directions too, with equal power. If you can change a prop from the code, you can change it from the canvas. If you can restructure something from the canvas, that same change is expressible as a code edit. No "oh that one's canvas-only" or "sorry, edit the code for that."

There's one truth, not two. No hidden config layer, no shadow state that only the visual panel knows about. Every edit, from either side, lands as a real patch to the actual source file. What you get out is a diff you could commit, not an export you have to translate.

Most tools fail at least one of these. Usually the third one — they'll do fine selection and okay editing, but underneath it's writing to some intermediate format that isn't your code.

The pieces underneath

Mechanically, this runs on three things working together. An in-browser TypeScript/JSX compiler, so there's no build step standing between a keystroke and a render. A runtime layer that walks the live component tree as it actually renders, not just the static file tree. And an AST patcher that turns any edit, from either side, into one small diff instead of a full-file rewrite.

None of these three alone gets you symmetry. The compiler without the AST patcher just gives you fast previews. The runtime tree without the compiler gives you introspection but no live editing. It's the three stacked that make either side able to write.

Why this is actually hard to build

If it were easy everyone would have shipped it already. Here's where it gets messy.

The DOM doesn't remember where it came from. By the time React renders something to the screen, the structural info from your source is gone. You need to inject position info at compile time and keep a live index mapping rendered stuff back to AST nodes, and keep that index correct as things re-render.

One line of code, many things on screen. A .map() produces N elements from one JSX node. Click the third card — do you select the JSX expression, or "the third iteration of it"? Both are valid answers depending on what the user is trying to do, and the tool has to pick sensibly.

Some code draws nothing at all, right now. A ternary's other branch exists in the source but isn't on screen. If someone clicks that branch in the code, what does the canvas even show? There's no pixel to point at.

The thing on screen might be defined three files away. A component gets imported through two barrel re-exports before you reach its actual definition. The mapping has to survive that, and still land you on the real file, not a re-export shim.

Formatting and comments can't get mangled. Every patch needs to be small and clean, or nobody's going to want the diff in their PR. This alone rules out "just regenerate the file from a new AST" as a strategy — you have to patch, not rewrite.

The dependency graph is sometimes broken, and that's fine. Real repos have imports that don't resolve — missing packages, aliases nobody configured, whatever. If one broken edge kills the whole feature, you've built something too fragile to use on a real codebase. So it has to keep working around the parts it can't resolve.

None of these are exotic edge cases. They're just... what a real React app looks like on a random Tuesday.

What symmetry buys you

Once selection and editing are actually symmetric, some things stop being separate features and just become normal.

Point at a card buried inside a .map(), inside a conditional, inside a component from another file — and land exactly on the JSX that made it, in one click, no searching. Change a prop from the canvas side, and the diff you get is one clean line, same as if you'd typed it. Change the code, and the canvas updates without you needing to guess which part of the screen you just touched.

It also means you're never locked out. You can start from the canvas because you're thinking visually, switch to code because you need precision on a value, switch back because you want to see six components move together after a theme change. Nothing about that flow required an export step or a "sync now" button.

Walking one, for real

Take a real template, not a toy one — Material Kit React, the MUI admin kit. Click a revenue card on the dashboard. It's not a top-level thing — it's the fourth hop down: main.tsx → DashboardPage → OverviewAnalyticsView → AnalyticsWidgetSummary, and that last one is sitting inside a .map() over a list of stat cards.

One click, and the exact JSX for that card is selected in the code, not the whole map block, not the parent — that one card. Change total={714000} to total={928000} in the code. Canvas updated.

Now go the other way. Select the "New users" card on the canvas. In the Inspector, change its color from the default "secondary" to "success". Code updated. The change lands exactly where you'd expect:

   <AnalyticsWidgetSummary
     title="Weekly sales"
     percent={2.6}
-    total={714000}
+    total={928000}
     ...
   />
   <AnalyticsWidgetSummary
     title="New users"
     percent={-0.1}
     total={1352831}
-    color="secondary"
+    color="success"
     ...
   />

No reformatting. No touched imports. The other cards stay untouched. Real template. Real component. Real source.

Why this matters if you're teaching React, not just shipping it

A side effect I didn't expect going into this: it's a genuinely good teaching tool, maybe better than it is a shipping tool.

Beginners lose a lot of energy just holding the map between "this text" and "that rectangle on screen" in their head. Symmetric selection hands that map to the tool instead. Put a cursor inside a .map(), watch eight things light up at once on the canvas — that explains list rendering better than any slide ever has. Change a theme token and watch six unrelated components move, and context stops being a diagram on a whiteboard and starts being a thing you just saw happen.

It's the same shift devtools gave CSS. Before devtools: edit stylesheet, reload, squint, guess. After: click the element, see exactly which rule applies. Nobody thinks devtools made people worse at CSS. React never really got that moment for itself. This is closer to it.

A quick test for any tool claiming "two-way"

Three questions, works on anything, not just us:

Can I go from canvas to code and code to canvas, always, not just sometimes? Can I do the same kinds of edits from either side? And when I'm done, do I get a diff I can commit — or a format I have to translate first?

If the answer to any of those is "well, mostly," it's two-way. Symmetric is a stronger bar, and it's the one that actually matters once you're editing a real app instead of a demo.

What if students could edit a real React app before they can even write one?

Jack Lee — Mon, 03 Aug 2026 12:01:00 +0000

Most React courses teach in the same order. Syntax first. Then hooks. Then a small app. Then, somewhere near the end — if there's time — how a real project is actually organized.

I understand why. You can't explain a provider tree to someone who doesn't know what a component is. The order makes sense on paper.

But there's a gap in the middle that nobody really covers, and I think it's the reason so many people finish a course and still feel like they can't read real code.

Reading code and understanding code are different things

You can stare at this for an hour:

<AnalyticsWidgetSummary
  title="Weekly sales"
  total={714000}
  color="warning"
  chart={{ series: [22, 8, 35, 50, 82, 84, 77, 12] }}
/>

And you'll "understand" it. Title is a string. Total is a number. Color is a string that's probably one of a few allowed values. Chart is an object with a series array.

Now: what does color="warning" actually change? Where does "warning" come from? Is it defined in this file? No. In the component? No. It's in a theme object, three directories away, that gets injected through a provider wrapped around the entire app in a file the student has never opened.

None of that is visible from reading the line. You only learn it by changing the value and watching what happens — or better, by changing the theme and watching six unrelated components shift at once. That's the moment the concept lands. Not before.

Sandboxes solve the setup problem, not the structure problem

The usual answer here is CodeSandbox or StackBlitz, and they're genuinely good tools. Setup friction goes to zero, the student clicks a link and there's running code. Great.

But look at what's actually in most educational sandboxes:

One file, maybe three
No routing
No theme provider
No barrel exports
No features/ folder, no layouts/, no shared component library
State that lives exactly where you'd expect it to live

That's a curated environment. It's useful for isolating one concept — and that's what it's for — but it's the opposite of what the student will face at their first job. Real apps are five providers deep before anything renders. Components import from @/components which re-exports from somewhere else which re-exports from somewhere else. Half the props come from a context you can't see in the file you're looking at.

So we teach on tidy code and then hand people messy code and act surprised when the transition is rough.

The missing link: code and canvas, pointing at each other

There's one more thing sandboxes structurally can't do, and I think it matters more for learning than anything else on this list.

In a sandbox, the editor and the preview are two separate worlds. You have code on the left, a rendered iframe on the right, and nothing connects them. If a student sees a card on screen and wants to know which JSX made it, they have to guess: search for the text, scroll, open three files, guess again. If they change a line of code, they see something change on the right, but they have to work out for themselves which change was theirs.

That guessing step is where beginners lose the thread. It's a translation tax paid on every single interaction.

Now flip it. Selection is shared in both directions:

Click a JSX node in the code, the matching element lights up on the canvas. "This is what that line draws." No searching.
Click an element or prop on the canvas, the exact JSX node or prop gets selected and highlighted in the code. “That’s the line that made this — and the property that controls it.” No guessing..

And editing works both ways too:

Type in the code, the canvas updates live.
Change a prop on the canvas, and the corresponding code updates — the changed prop briefly highlights.

Sounds small. It isn't. What it does is collapse the gap between symbol and thing. Beginners spend enormous energy holding an unstable mental map between "this text" and "that rectangle on screen." When the tool holds the map for them, that energy goes back into the actual concept.

It's the same reason browser devtools were such a leap for learning CSS. Before devtools you edited a stylesheet and reloaded and squinted. After devtools, you clicked the element and saw which rules applied. Nobody argues devtools made people worse at CSS. It just removed the guessing.

React never really got that moment. The component tree is a runtime construct, the JSX is source text, and the two have historically lived in separate windows with no line between them. Two-way selection is that line.

And this genuinely is not something CodeSandbox or StackBlitz can bolt on. They run your code in an iframe — they can host it and hot-reload it, but they don't have a live mapping from the rendered DOM node back to the exact AST node that produced it, especially once that node came out of a .map(), or a ternary, or a component defined in a different file. That mapping is the hard part, and it's the part that turns "here's your code running" into "here's your code, and here's what each piece of it is."

For a student, the practical effect is that the feedback loop drops from minutes to zero. Click, see, change, see. Repeat forty times in a session. That's not a nicer UI — that's a different learning rate.

The dependency graph is the thing you're actually teaching

Here's the part I think gets underrated. When a student says "I can't find where this comes from," they're not asking a syntax question. They're asking a graph question.

Every React codebase is a dependency graph. Files import files, barrels re-export barrels, a component pulls a hook that pulls a context that's provided six levels up. The rendered UI is just one projection of that graph. Most of the confusion beginners have — "where does this prop come from," "why did changing that file break this screen," "which of these five index.ts files is the real one" — is them trying to traverse a graph they can't see.

Courses teach the tree (component hierarchy). They mostly skip the graph (module dependencies). But the graph is what you navigate every day at work.

So the exercise gets better if you make the graph visible:

Trace one import chain end to end. AnalyticsWidgetSummary → @/components/chart → chart/index.ts → chart-widget.tsx. Three re-exports to get to real code. That's not unusual; that's Tuesday.
Ask "what breaks if I delete this file?" and then actually look at the answer. Inbound edges are a concept you can feel, not just define.
Show a broken edge. Rename an export and watch which parts of the graph go red. Beginners learn far more from a targeted break than from a working example.

There's a practical angle too: real templates often have edges that don't resolve — a missing peer dep, an optional import, a path alias nobody configured. Traditionally that's a hard stop; nothing renders, the student is dead in the water in minute three. It doesn't have to be. If the tool can bypass an unresolved import and keep rendering the rest of the graph, a broken edge becomes a lesson instead of a blocker. (We wrote about the mechanics of that separately, in Don't just find the broken import. Bypass it.)

A student who can read a dependency graph can onboard onto any codebase. A student who only knows hooks can onboard onto the one they were taught.

The thing that's usually a diagram

Every React curriculum I've seen has a moment where the instructor draws a box, puts smaller boxes inside it, and says "so the provider wraps everything, and the components underneath can read from it."

The diagram is correct. It's also inert. It doesn't respond when you poke it. Nobody has ever learned what a provider does by looking at a rectangle.

What if instead of the diagram, the student opened the actual app — a real, shipped, slightly messy admin template — clicked into a card buried four levels deep inside a .map() inside a conditional inside a layout component, and changed one prop? And saw both the rendered result and the exact source diff at the same time?

That's not a replacement for the explanation. It's the thing the explanation is about, made touchable.

What this actually looks like in practice

Concretely, here's the exercise I keep imagining for week one, before the student has written a single line of React themselves:

1. Open a real template. Not a teaching example — something that actually shipped. Material Kit React, shadcn-admin, whatever. Entry file, straight from disk. No npm install, no dev server, no "wait for it to build."

2. Find one thing on screen. "See that revenue card in the top left? Click it." The corresponding JSX highlights in the code — they didn't search for it, they pointed at it. Then walk back up: main.tsx → DashboardPage → OverviewAnalyticsView → AnalyticsWidgetSummary. Four hops. The student just learned what a component tree is, by walking one.

2.5. Go the other direction. Put the cursor on a random JSX node in the code and watch the canvas highlight what it draws. Do it on a node inside a .map() so they see one line of code producing eight things on screen. That single observation explains lists better than any lecture on key props.

3. Change one prop — from both sides. Edit total={714000} → total={928000} in the code, watch the number change. Then change the next card's value on the canvas instead, and watch the one-line diff appear in the source. Same operation, two directions. That's props, and that's also the first time most students really believe the UI is the code.

3.5. Follow one import out of the file. Where does AnalyticsWidgetSummary actually live? Not the import line — the real file, past the barrels. Two or three hops through the dependency graph. Do it once by hand so they know what the tool is doing for them later.

4. Change something in the theme. Watch six other components move. That's context. No diagram required.

5. Break something on purpose. Pass a string where a number goes. See what React does. Fix it.

None of that requires the student to know how to write React yet. It requires them to know how to read it and poke it — which is honestly what most junior work is anyway. You're rarely writing a new app from scratch. You're finding the thing in someone else's codebase and changing it without breaking three other things.

The objection I keep coming back to

The obvious pushback: isn't this just teaching people to be dependent on a visual tool? If they can't find the file by hand, have they actually learned anything?

I think that's a fair worry, and it depends entirely on how it's used. If the tool does the navigation for them and they never look at the path, no, they haven't learned much. If the tool shows them the path — literally, the breadcrumb of components it walked through, and the file each one lives in — then it's closer to training wheels than a crutch. They see the structure repeatedly, in a real codebase, until it stops being mysterious.

The other objection: real templates are messy, and messy is confusing for beginners. Also fair. But they're going to hit messy eventually, and I'd rather they hit it with an instructor in the room than alone on day three of a new job.

Why I'm thinking about this at all

I build a tool that does the "open a real React app with no build step and edit it" part — CrossUI Studio. It wasn't built for education. It was built because I got tired of running npm install on a template just to see whether the card component was worth using.

But the education angle keeps coming up. People teaching React tell me the hardest part isn't syntax — it's the gap between "I can write a component" and "I can find my way around a codebase someone else wrote." That gap is not a knowledge problem. You can't lecture it away. It's a familiarity problem, and familiarity comes from time spent poking at real things.

So the question I actually want to ask: has anyone teaching React tried starting with a real app instead of a curated one? Bootcamps, university courses, even internal onboarding for new hires. Did it work? Did students find it empowering, or just overwhelming? Is there a reason this is a bad idea that I'm not seeing from where I sit?

Genuinely curious. I'm on the tool side of this, not the teaching side, and I'd rather hear from people who've actually stood in front of a room of beginners.

If you want to try the mechanic yourself: Guest mode opens instantly, no account. Point it at a template, click something, and see how far down it goes.

Preview and edit material-kit-react without a build step

Jack Lee — Thu, 23 Jul 2026 18:52:02 +0000

~7 min read · Tutorial

I look at a lot of MUI admin templates. material-kit-react from the minimals people is one I keep going back to. Clean, typed, and the folder structure makes sense. Repo: minimal-ui-kit/material-kit-react.

But every time I just want to see it, or change one color to check something, it's the same ritual. git clone, npm install, wait, npm run dev, wait more, tab over to localhost. Few minutes gone, a few hundred MB of node_modules on disk. All that to look at a dashboard.

So this time I skipped the build. Opened the folder in CrossUI Studio, rendered src/main.tsx directly. No install, no Vite, no localhost. Below is what I did, including the bits that made me stop and think.

One honest note first. This does not replace your dev server. You still need the real thing for tests, prod builds, actual feature work. It's good for the look-and-tweak loop. Evaluating a template, recoloring something, showing a client. The stuff where booting the whole toolchain costs more than the task itself.

Quick note: local folder support requires a Pro account. To test it out, use the code in the original blog for a free upgrade. No credit card required, available while it lasts.

Your browser does not support video. Watch on YouTube.

1. Clone to local disk (don't open it straight from GitHub)

Studio can mount a GitHub repo directly. For a small repo that's the nicest path. For this one I cloned to disk first:

git clone https://github.com/minimal-ui-kit/material-kit-react

The reason is boring. src/ alone is ~130 files, ~245 in the whole project, spread over sections/, components/, layouts/, theme/, routes/. Opening a project means the tool has to pull the files it touches. Over the GitHub API, on demand, that's a lot of small requests. It works, just not snappy, and you can hit the rate limit if you poke around. A local folder is only the filesystem, so it's instant. For a template this size, local wins.

No npm install here. I only cloned the source. The whole point is to not build.

2. Open the folder — and let it generate a project setting

In Studio: open a Local Folder, pick the cloned material-kit-react directory. It reads the tree. Nothing installs, nothing runs, files stay on my disk. That last part matters if you don't love uploading a client's codebase somewhere just to look at it.

First time in, Studio sees there's no project setting file and pops a prompt:

This project has no CrossUI Studio setting file. We recommend auto-scanning the project to generate one first, then editing it by hand.

Hit Scan & generate. It goes through the project's own config files and writes a setting file at the root. After that, the imports the template uses everywhere just resolve, without Vite in the loop. I didn't have to tell it anything.

You can hand-edit it after. The Project Settings dialog opens right on the generated file. But the auto one was enough for everything below. Couple of seconds, still zero npm install.

3. Open `src/main.tsx` and hit preview

Close the Project Settings dialog and Studio opens the entry file for you. No need to go hunting in the file tree.

Here's the file you normally can't "just render":

// src/main.tsx
const router = createBrowserRouter([
  {
    Component: () => (
      <App>
        <Outlet />
      </App>
    ),
    errorElement: <ErrorBoundary />,
    children: routesSection,
  },
]);

createRoot(document.getElementById('root')!).render(
  <StrictMode>
    <RouterProvider router={router} />
  </StrictMode>
);

This is a Vite entry. createBrowserRouter + RouterProvider, and the whole app lives inside <App> (the theme provider) and routesSection (the routes). Render this file in isolation the naive way and it blows up. No router context, no theme, no #root the way the app wants it.

It rendered anyway. I configured nothing. Opened main.tsx, hit preview, and the dashboard showed up on the canvas with the MUI theme and all.

Now return to the Design Mode. From what I can tell it picks the providers up from the entry files, so a template that does something weird at bootstrap probably needs you to point it at the right one by hand. For material-kit it just worked, and I'd guess it's because app.tsx is this plain:

// src/app.tsx
export default function App({ children }: AppProps) {
  return (
    <ThemeProvider>
      {children}
      {/* github fab */}
    </ThemeProvider>
  );
}

Clean entry files matter a lot here. More on that at the end.

4. Drill down — the providers follow you down (this is the real part)

The dashboard at / isn't one component. It's a lazy-loaded stack:

main.tsx  (RouterProvider defined here + the detected ThemeProvider)
  └─ routesSection              (src/routes/sections.tsx)
       └─ DashboardPage          (src/pages/dashboard.tsx, lazy)
            └─ OverviewAnalyticsView   (src/sections/overview/view)
                 └─ AnalyticsWidgetSummary ×4   (src/sections/overview, the stat cards)

Ctrl+click on the canvas walks you DOWN this tree, one file at a time. The nice surprise: the provider wrapping follows you down by itself. Open the Render Decorations panel at any level and you can see the two wrappers listed, RouterProvider and ThemeProvider:

On main.tsx it lists both but auto-skips RouterProvider. Makes sense, that provider lives in this very file, so wrapping again would double it. It only applies the theme.
On sections.tsx, then dashboard.tsx, then below, both are on (the panel shows "2"). So router + theme context is there the whole way down. I never had to hand-fix a "missing provider" on the way.

That's usually the painful part of rendering a deep file in isolation, and it was handled for free. What was left on the way to the file I wanted were two small navigation detours. Neither is a crash. They're just what real code looks like.

Detour 1 — sections.tsx opens on the wrong JSX block (renderFallback).

Ctrl+click into the router file and it lands on renderFallback, the Suspense spinner:

// src/routes/sections.tsx
const renderFallback = () => (
  <Box sx={{ display: 'flex', flex: '1 1 auto', alignItems: 'center', justifyContent: 'center' }}>
    ...
  </Box>
);

So the canvas goes almost empty. One file can hold several JSX blocks and this spinner is just the first one. Up top there's a block navigator (the breadcrumb dropdown) listing them all. I jumped to routesSection and its children:

export const routesSection: RouteObject[] = [
  {
    element: ( /* <DashboardLayout><Suspense><Outlet/></Suspense></DashboardLayout> */ ),
    children: [
      { index: true, element: <DashboardPage /> },
      { path: 'user',     element: <UserPage /> },
      { path: 'products', element: <ProductsPage /> },
      { path: 'blog',     element: <BlogPage /> },
    ],
  },
  // sign-in, 404 ...
];

Picked { index: true, element: <DashboardPage /> }, the / route, and the whole dashboard rendered. Theme already riding along from the auto-wrapper. Finding DashboardPage next to UserPage / ProductsPage took one glance. The routes read like the URL map.

Lesson: when a file has more than one JSX block, don't trust the first thing it shows. Use the block navigator to land on the piece you care about.

Detour 2 — index.ts is a barrel, not a component.

From DashboardPage I kept drilling and hit this:

// src/sections/overview/view/index.ts
export * from "./overview-analytics-view.tsx";

NO-TARGET-JSX: No target jsx block found in the file. Which is correct. It's a re-export, there's no JSX to render. sections/ uses these short barrels everywhere so imports stay tidy (from 'src/sections/overview/view' instead of the full path). Click overview-analytics-view.tsx in the file list to open the source file. overview-analytics-view.tsx renders on arrival, theme already applied, and this is the file I actually edit (next section).

So the two things that made me stop weren't errors. The providers rode down on their own. One was a file with multiple JSX blocks (use the navigator), the other a barrel re-export (click through). Half-second detours, and both say more about how the template is wired than about the tool.

(The block navigator above the editor also jumps to any level directly, if clicking through gets old.)

5. Change something

overview-analytics-view.tsx is where the four stat cards get their props, and it reads easy:

<AnalyticsWidgetSummary
  title="Weekly sales"
  percent={2.6}
  total={714000}
  // color defaults to primary
/>

Two small edits, both from the canvas and the inspector. I changed the "Weekly sales" card's color to warning and pushed total up. Then flipped the "New users" card from secondary to success. The diff that lands is exactly that and nothing more:

   <AnalyticsWidgetSummary
     title="Weekly sales"
     percent={2.6}
-    total={714000}
+    total={928000}
+    color="warning"
     ...
   />
   <AnalyticsWidgetSummary
     title="New users"
     percent={-0.1}
     total={1352831}
-    color="secondary"
+    color="success"
     ...
   />

No reformatting, no touched imports, the other cards byte-identical. This is the bit I care about most in these tools. I want to see it write the edit the way I'd have typed it, not re-emit the whole file from some internal model. Here it's a surgical prop change.

If you want a bigger change, the theme is the place. src/theme/ is where the palette gets created, and changing the primary color there recolors buttons, nav, active states, everywhere. Same loop, wider blast radius.

6. Back to the whole app — just hit the browser Back button

Small thing I didn't expect to like this much. I didn't reopen main.tsx from the file tree to get out. Every drill-down step was real navigation, the URL changed each time I stepped in, so the browser Back button walks straight back out. View → page → route → main.tsx. Forward and back behave like any web app. Back a few times and I'm looking at the full dashboard again with my edit baked in. The "Weekly sales" card now amber inside the real layout, not only in the isolated view where I changed it.

That round trip, edit deep in a view then Back all the way out to see it in the whole app, is normally a reload plus a mental context switch. Here it's the same canvas and the Back button.

Total time from git clone to "amber card in the running dashboard": a couple of minutes, most of it the clone. Zero of it npm install.

Why the friction landed where it did (a note for template authors)

It wasn't quite zero friction. Two small navigation detours on the way down. But both were in predictable places, a multi-block router file and a barrel re-export, and each was a one-click fix. A good part of why it was that predictable is the template itself, not the tool. material-kit-react is put together in a way that cooperates:

The entry (main.tsx / app.tsx) is straightforward. Providers are right there, not hidden behind three layers of indirection. That's probably why RouterProvider and ThemeProvider got picked up and stayed applied at every level I drilled into. Theme context just rode along, no manual provider fixing on the way down.
Routes are lazy() and grouped in routesSection, so the block navigator reads like the URL structure. Spotting DashboardPage next to UserPage / ProductsPage takes one glance.
sections/ are split per feature behind short barrel index.ts files. Keeps imports tidy in the real app, and when drilling you just click the one export * line. A predictable pattern beats a clever one.
The cards take plain props. AnalyticsWidgetSummary is just title/total/percent/color/chart, fed by the view. So editing one from the view is a data change, not a backend call, and the diff stays a single line.

A messier template would be harder to preview this way, tool or no tool. Providers assembled dynamically, one 2000-line page, sections that only work when fed real fetched data. So good template structure is a big part of what makes "open it without building it" realistic. Hats off to material-kit-react there, the structure is doing real work.

The practical upshot, if you make or sell templates. A chunk of the friction for someone evaluating your template is the clone-install-run tax before they see anything. Being previewable and tweakable straight from source cuts that tax a lot. Worth thinking about.

What I would not use it for

Running the test suite or the real Vite build. This is preview + edit, not CI.
Anything that needs live backend data to render at all. You can mock it for a drill-down, but that's a different workflow.
A final answer on runtime behavior. It renders structure from the source. It's not watching your app actually execute end to end.

For "open this template, change a couple of things, see it in context", which is most of what I do with admin kits before committing to one, skipping the build was just less ceremony.

Quick note: local folder support requires a Pro account. To test it out, use the code in the original blog for a free upgrade. No credit card required, available while it lasts.

Editing React components that never rendered

Jack Lee — Mon, 13 Jul 2026 14:33:47 +0000

~7 min read · Engineering

There are only two ways a tool can learn the shape of your React code. Which one you pick decides the single most important thing about the tool: whether it's available in the exact moment you need it most.

Two ways to know a codebase

Runtime introspection watches a running app. React DevTools, profilers, error overlays — they read the live fiber tree after the app mounts. This is the richer of the two: they know real prop values, real state, what actually rendered. But all of that is conditional on one thing — the app has to successfully run first. The moment a render throws, they go dark. Nothing mounted, so there's nothing to inspect. And a module that failed to initialize is invisible to them by definition.

Static AST analysis reads source. It parses each file into an abstract syntax tree and reads the structure directly — every JSX node, every import, every prop — without executing anything. It's poorer in one sense: it can't tell you what a variable held at 2:04pm, because nothing ran. But it has a property no runtime tool can match: it works on code that has never once rendered cleanly.

Most developer tooling is built on the first model. We built CrossUI Studio — a visual editor for React — on the second, on purpose. This post is about why that constraint turned out to be the whole point.

The moment tooling abandons you

Here's the scenario that shaped the decision. A component renders blank. The stack trace points at the component, but the real failure is five imports down — a dynamic import that didn't resolve, a peer dependency that got bumped, a circular reference that's undefined on first access. The component is innocent; the thing it transitively pulls in is the culprit.

This is exactly when you most need to understand your code's structure — which file imports what, where the break is, what the surrounding code looks like. And it's exactly when every runtime tool has gone dark, because the app didn't render. DevTools shows nothing. The profiler has no render to profile. The error overlay gives you a line number but not the shape of the code around it. They all need the app to run first, and the entire problem is that it won't.

The one moment you most need to see your code's structure is the one moment a runtime tool refuses to produce it.

A static AST tool has no such dependency. It parsed the files when you opened them; it can draw the whole import graph, point at the broken module, and show you the code around it — with the app fully crashed. A broken page isn't a dead end. It's the entry point.

Editing what you can't run

The same property unlocks something stranger: editing a component that isn't rendering, in a file you never opened.

Think about what a visual editor normally needs to render a <Card> that lives inside a .map(). To put that Card on a canvas, it has to know what item is — and item only exists at runtime, inside the loop, when real data flows through. A runtime-based editor simply can't render that Card in isolation; there's no live item to feed it. So most visual editors quietly refuse to go inside a .map() at all.

Working from the AST, the problem reframes. We don't need a running loop; we need the node. Parse the file, find the JSX inside the map callback, and render that subtree in isolation. The one thing missing is the value of item — so we ask you for it (a small mock in a panel) rather than requiring the app to produce it. The Card renders, live, with real theming, standing on its own.

And because the unit of understanding is the AST node rather than the mounted component, drill-down doesn't stop at the file boundary. A child component imported from another file is just another edge in the graph. Follow the import, parse that file, render its node — you're editing a component defined somewhere you never opened, in an app that may never have rendered as a whole.

The cost of the constraint

None of this is free, and pretending otherwise would be dishonest. Static analysis buys unconditional availability by giving up runtime knowledge:

Fully dynamic imports are unresolvable. import('./pages/' + name) with a runtime-computed path can't be resolved statically. We mark the edge rather than guess.
We see structure, not values. The AST tells you AIPanel reaches TreeSitter; it can't tell you what the parser returned on a given render. Mock data stands in for real data; it doesn't replay it.
Exotic resolution needs config. Non-standard bundler aliases or monorepo path magic resolve best when we can read your tsconfig/jsconfig. Without it, some edges fall back to raw specifiers.

These are real boundaries. But notice none of them touch the core promise: the tool is there when you're stuck, because it never needed your code to run in the first place.

Why this is one idea, not many

The crash-surviving dependency graph, the edit-inside-a-map drill-down, the cross-file navigation, the one-line diffs — from the outside they look like separate features. They're the same decision seen from different angles: treat parsed source as the source of truth, and make every surface a view over that AST.

The canvas is a view over the AST. The prop inspector is a view over the AST. The dependency graph is a view over the AST across files. None of them depend on a successful render, because none of them are built on the runtime. That's a harder thing to build than hooking the fiber tree — and it's exactly what keeps the tooling alive in the moments the runtime, and everything built on it, goes dark.

→ Try it — open a project, break a deep import on purpose, and watch the structure still render.

About CrossUI Studio — A visual IDE for React & MUI. Code and canvas stay in two-way sync on the same AST: edit code and the canvas updates live; click an element on the canvas, edit its props visually, and the code changes with a surgical one-line diff. No build, no localhost — it runs in the browser, works on your real Git repo or a local folder, with no vendor lock-in.

Try it free → studio.crossui.com

Edit inside a .map(), a ternary, even a component in another file

Jack Lee — Mon, 06 Jul 2026 13:07:34 +0000

~7 min read · Tutorial

Here's the wall almost every visual editor hits. You can edit the outer JSX just fine. But the thing you actually need to change is a Card inside a .map(), and the tool goes quiet — because to render that Card, it needs to know what item is, and item only exists at runtime, inside the callback.

So you drop back to hand-editing. Which is fine, except the whole reason you opened a visual editor was to not do that.

CrossUI Studio's Layer Drill-down Engine is built for exactly this. You can isolate and edit any node at any depth — including the ones that live behind a runtime boundary. And drill-down doesn't stop at the file edge: Ctrl+click a child component and Studio follows it into the file where it's defined, keeping the canvas live the whole way down.

The depth problem, concretely

Take a list that every React app has some version of:

{items.map((item) => (
  <Card key={item.id} elevation={item.featured ? 3 : 1}>
    <CardContent>
      <Typography variant="h6">{item.title}</Typography>
      <Chip label={item.tag} size="small" />
    </CardContent>
  </Card>
))}

You want to visually tweak that Card — bump the padding, change the Chip size, adjust the Typography variant. But a normal visual editor can only see the items.map(...) expression. It can't render the inside, because item is undefined until the loop runs. Same story for a ternary (cond ? <A/> : <B/>) and for children passed into a slot.

That runtime boundary is where most tools stop. Studio treats it as just another layer to step into.

Step 1 — Drill into the iteration

There are three ways to drill into a node, and they work whether the target is in the current file or in another one:

Ctrl+click on the canvas or in the component tree. Hover a drillable sub-component or expression and an action prompt appears; hold Ctrl to highlight the target with a mask, then click to step into it. Or just click the corresponding node in the left component tree.
JSX block selector / breadcrumb. Use the block selector or breadcrumb above the editor to see the hierarchy and jump to any level — handy when the tree is dense and you'd rather pick than click through.
Cursor focus (in-file). In the code editor, place your cursor inside a JSX block and Studio promotes it to the canvas focus. Editor and canvas point at the same AST, so moving in one moves the other.

Drill into the .map() and Studio renders an isolated canvas for the inner block — one iteration of your list, standing on its own.

In the shot above, Ctrl+click on the .map() drills into ProjectBoard['map-0-item'] — the first item of the list, isolated on the canvas while the full items.map(...) stays put in the code.

Supply the missing context: the Test Data Injector

An isolated list item has a problem: it lost the context its parent gave it. item is undefined now — there's no loop feeding it. So Studio gives you a Test Data Injector: a panel where you supply temporary mock data (JSON, strings, booleans) for any undefined props or variables at the current level. Fill in item and the isolated Card renders realistically, without the full app around it.

One thing that saves guesswork: hover any unassigned variable and the code editor highlights its exact location in the source, so you can see how item is used before you decide what to mock.

Now the Card is live. Not a screenshot — the actual component, rendered with real MUI theming.

Step 2 — Edit the inner node

With the inner block isolated, editing is the normal Studio loop. Click the Chip, change size from small to medium. Select the Card, promote its padding to a responsive { xs: 2, md: 3 }. Each change writes back into the callback body as a precise AST patch:

   {items.map((item) => (
-    <Card key={item.id} elevation={item.featured ? 3 : 1}>
+    <Card key={item.id} elevation={item.featured ? 3 : 1} sx={{ p: { xs: 2, md: 3 } }}>
       <CardContent>
         <Typography variant="h6">{item.title}</Typography>
-        <Chip label={item.tag} size="small" />
+        <Chip label={item.tag} size="medium" />
       </CardContent>
     </Card>
   ))}

The .map() wrapper, the key, the ternary on elevation — all untouched. Your mock data never touches the file; it lived only in the drill-down session. What lands in the diff is exactly the two properties you changed.

The same mechanism works for conditional rendering (drill into the true or false side of a ternary, or a && branch, and edit it in isolation), for controlled sub-components that depend on external props or state, and for render-slot children. Any depth your tree actually has, you can reach.

Step 3 — Cross the file boundary

Real components don't live in one file — a page composes children that are imported from all over src/. A file-bound editor stops when it hits one of those imported children: you have to go find the file yourself, open it, and lose the canvas.

Studio doesn't stop there. Ctrl+click a child component and Studio drills straight into the file where it's defined, and keeps rendering it live on the canvas.

In the shot above, the active file is ShadcnDashboard.jsx. Its component tree lists the children it composes — KpiCard, RevenueChart, OrdersTable, Sidebar, Header, and so on. Sidebar isn't defined in this file; it's imported from ./components/Sidebar.jsx (line 16). Ctrl+click it, and Studio follows the import, opens the real definition, and drops you onto its canvas — the dashboard's sidebar, rendered live — with no manual file hunting and no losing your place. From there you can keep drilling: into that file's own children, into a .map() inside it, into a component it imports from somewhere else.

The same three drill-down methods from Step 1 apply here — Ctrl+click and the JSX block selector both cross file boundaries (cursor focus is the one that's in-file only, since it needs the code open in front of you). The effect is that the component tree stops being one-file-at-a-time. You navigate your UI the way it's actually structured — as a graph of components across files — while the canvas stays live at every hop.

Why it can do this

Same reason the rest of Studio works the way it does: everything is a view over the AST, not over a running app.

Drilling into a .map() is an AST operation — Studio finds the callback body node and renders it with an injected scope. Following a child component across files is also an AST operation — it resolves the import, parses the target file, locates the exported component, and renders that node. The runtime never has to succeed for any of this; Studio is reading structure, not observing execution. That's why it can isolate a node five levels deep, in a file you haven't opened, whether or not the full app renders.

If you want the architecture behind that, the dependency graph post covers how static AST parsing survives things a runtime tool can't.

Try it

The fastest way to feel this is on a real project with real nesting — a dashboard with a list of cards, a page that composes imported sections.

Open a project (Playground, Git repo, or a local folder).
Find a .map() or a ternary, drill in, use the Test Data Injector to mock the missing variable, and edit the inner node.
Find an imported child component in the tree, Ctrl+click it, and watch Studio follow it into its own file.

Guest mode, no account: studio.crossui.com

Try it free → studio.crossui.com