DEV Community: Jack Lee

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

Developer sovereignty: what "no lock-in" actually means

Jack Lee — Mon, 29 Jun 2026 12:02:14 +0000

Every developer tool says "no lock-in" on its landing page. It's the cheapest promise in software — easy to write, almost never tested, and by the time you find out it wasn't true, you've already built six months of work on top of it.

So instead of saying it, here's the test we hold ourselves to. One question, and it's the only one that matters.

The exit test

Stop using the tool tomorrow. Is your project still standard, shippable code that runs without it?

That's it. Not "can you export." Not "is there a migration path." Those are consolation prizes you accept after you've already been locked in. The real question is whether the tool ever inserted itself into your source in the first place.

Run that test against most visual editors and the answer is no:

Export-and-fork tools — the moment you export and hand-edit, the tool and your repo are separate forever. There's no exit back; the design tool can't read your changes. You don't own one project, you maintain two.
SDK-ownership tools — your components live in a proprietary model, rendered by the tool's runtime. "Stop using it" means migrating a schema, rewriting components, untangling a dependency you can't remove. The exit cost is the lock-in.
AI app generators — better here, since they hand you code and walk away. But they also walk away from the next change. They don't stay in sync with the source, because they were never connected to it.

The pattern: every one of them either never touched your real code, or touched it in a way you can't undo. Sovereignty is the opposite of both — the tool works on your real source, and leaves nothing behind when it goes.

What we put in writing

We call this principle developer sovereignty, and we made it a concrete guarantee, not a vibe:

The code processed by CrossUI Studio is standard React code. We promise not to embed any proprietary runtimes, closed-source dependency packages, or any logic "traps" that cannot run outside the platform into your source files. If you stop using CrossUI Studio, your project remains a standard React project — no migration effort required.

Three things that are not in your files after Studio touches them:

No proprietary runtime. Nothing your app needs to import from us to render. It runs on plain React, the same as before.
No closed-source dependencies. We don't slip a package into your package.json that only resolves through us.
No platform-locked logic. No magic comments, no special syntax, no node that only means something inside our canvas.

What's left in your repo is what a senior engineer on your team would have typed by hand. That's the whole point.

Why we can actually promise this

Most tools can't make this promise because of how they're built. If a tool owns a rendering model — its own representation of your component tree — then "saving" means serializing that model back to code. Serialization is lossy. The tool writes what it knows and discards what it doesn't, which is why exported code looks subtly foreign and why re-emitting a file strips your comments.

Studio is built the other way around. Your source code's AST is the single source of truth, and every surface — the canvas, the inspector, the code editor — is just a view over that AST. We never hold a parallel model that has to be flushed back to disk. When you change a prop on the canvas, we patch the one AST node that changed and write back only the bytes that moved.

The consequence you can see in git diff: a padding change is one line. Indistinguishable from what you'd have typed. And because we never owned anything but a view, there's nothing to take with us when you leave — the source was always yours, the whole time.

Sovereignty is a feature, not a disclaimer

It's tempting to read "no lock-in" as a defensive footnote — a thing you promise so buyers feel safe. But for the teams we care about, it's the product.

A senior engineer evaluating a visual tool isn't asking "is this fun to use." They're asking "what does this do to my codebase, my git history, my code review, six months from now." A tool that leaves the source clean and exits without a trace is one they can actually adopt, because adopting it costs nothing to reverse. The reversibility is the trust.

And it compounds outward. Template authors won't ship a tool to their buyers that traps those buyers. Agencies won't hand a client a codebase they can't maintain without a subscription. Sovereignty isn't just your guarantee — it's theirs to pass on.

The honest version

No lock-in doesn't mean no commitment. While you use Studio, you do connect it to your repo or a local folder — that's the price of real two-way sync, and we think it's worth it. What it means is that the commitment is revocable at any moment, for free. Close the folder, cancel the plan, delete your account: your project doesn't notice. It was standard React before Studio, during Studio, and after.

That's the test. Run it on every tool you adopt — including ours.

Try it free → studio.crossui.com

Your AI writes the logic. Studio tunes the UI. They don't compete.

Jack Lee — Mon, 22 Jun 2026 16:43:44 +0000

I was building a dashboard. The card layout was almost right — just needed a bit more breathing room, a tighter border radius on the inner rows, and the label font to feel slightly lighter. Three small things.

I typed the description into Cursor. It came back with 180 lines rewritten. Every sx prop touched, four components restructured, a new wrapper div appeared. The layout looked the same. The diff was enormous.

I hit Ctrl+Z and went back to staring at the code.

That was the moment I stopped thinking of AI as a universal tool and started thinking of it as a specific tool — an exceptionally good one, for specific things.

What AI is actually good at

AI editors are brilliant at the parts of React development that are fundamentally about thinking: data flow, state architecture, API wiring, conditional rendering logic, form validation, accessibility semantics, refactoring towards patterns. These are tasks where the right answer involves reasoning across the whole codebase, holding context, understanding intent.

When I ask an AI to "add optimistic update to this mutation handler" or "extract this form logic into a custom hook" — I get back something genuinely useful, usually on the first try.

What AI is genuinely bad at

UI polish is a different category. Not because AI can't read CSS — it clearly can. But because getting a layout exactly right is an iterative, visual, trial-and-error process. You need to see the result immediately. You need to tweak a value, check it, tweak again.

The AI-for-UI workflow is fundamentally broken:

Describe what you want in words (already lossy)
Wait for the model to generate a response
Review 200 lines of diff
Wait for the build
See the result — probably not right
Repeat, burning tokens each round

The bigger the model's context about your component, the more it rewrites. It doesn't know how to make a surgical one-property change, because its job is to understand and regenerate, not to minimally diff.

AI is expensive at precision. It's cheap at breadth. UI tuning needs precision. Logic needs breadth. Match the tool to the task.

Where each tool belongs

AI Editor (Cursor / Claude / Copilot)

Component architecture and refactoring
State management and data flow
API integration and async logic
Accessibility and semantics
Test generation
Large-scale rewrites and migrations

CrossUI Studio

Spacing, sizing, layout tweaks
MUI sx and responsive breakpoints
Color, typography, visual hierarchy
Deep-layer UI drill-down and isolation
Rapid iterative visual feedback
Surgical one-property diffs

Notice there's no overlap. That's not accidental — these tools solve genuinely different problems. The goal was never to have one tool do everything. It was to cover the full surface of React development without gaps.

The pairing in practice

Since we shipped Local Folder access in v0.9.6, the workflow is concrete: point both your AI editor and Studio at the same folder on your machine. They work on the same files simultaneously. One writes logic, the other tunes UI. The diff in Git is always clean because every change is surgical.

Step 1 — AI builds the component
Cursor or Claude writes the data-fetching hook, the conditional render, the event handlers. Full context, full reasoning, exactly what it's good at.

Step 2 — Studio opens the same folder
No upload, no sync, no token. Studio reads the files directly off disk — the canvas shows your component live.

Step 3 — You tune visually
Adjust spacing, colors, and layout directly on the canvas. The code updates in real-time. One property changed = one property in the diff.

Step 4 — PR lands clean
Logic changes from AI. UI changes from Studio. Both are minimal, reviewable, and traceable. No 200-line rewrites for a border-radius tweak.

What this means for "AI replacing developers"

There's a lot of anxiety right now about AI eating programming jobs. Some of it is warranted — the volume of boilerplate code a developer needs to write by hand has dropped dramatically, and it's not coming back.

But the anxiety assumes AI is a single homogeneous capability that scales linearly. It isn't. There are things AI does cheaply and well (reasoning, pattern-matching, generation at scale) and things it does poorly or expensively (precise iterative feedback loops, visual judgment, knowing when to stop).

The developer who understands this boundary — and builds a workflow around it — is faster than the developer who either ignores AI entirely or tries to use it for everything. The job doesn't disappear. It shifts: less time writing boilerplate, more time designing systems and judging quality.

Studio is a bet on that shift. Not a replacement for AI. Not a rejection of it. A tool for the part of your work that AI handles badly — so you can let AI fully own the part it handles well.

If you've been using an AI editor and hitting the same wall on UI iteration — try the pairing. Open Studio, point it at your project folder, and see if the division of labor clicks for you.

No account needed — Guest mode opens a workspace instantly. Or connect a local folder and work on your real files.

Try it free → studio.crossui.com

Don't just find the broken import. Bypass it.

Jack Lee — Mon, 22 Jun 2026 16:07:49 +0000

A dependency five levels down throws, and your whole canvas goes white. CrossUI Studio's Dependency Graph still draws — zero build — points you straight at the blinking node, and then lets you inject a mock for the broken module to bring the page back. No file edit. No rebuild.

The Dependency Graph is built from static AST parsing, not a build — open a file and the import tree renders instantly, even when the canvas has completely crashed. The failing module blinks with its exact line/column. Then the part that's actually new: from the inspector you can set an interceptor or override to swap the broken dependency for a mock, hit Apply Dependency Injection, and the render comes back — rules auto-persist per entry file.

The blank-screen problem, five levels deep

A component blows up, but the component is never the culprit. Here's a real one. The canvas throws inside AIPanel.jsx:

Error (Canvas render — runtime)
Parser engine initialization aborted.
  in Studio/src/components/panels/AIPanel.jsx

  at initializeParser (Engine/src/TreeSitter.js:32:11)
  at async Engine/src/TreeSitter.js:36:31

But AIPanel isn't where it broke. The real failure is in TreeSitter.js, line 32 — five imports down the chain:

AIPanel.jsx → AIJsxResponseReconciler.js → JSXParserEngine.js
            → CodeFormatter.js → TreeSitter.js   ← throws here

Normally this is where the afternoon disappears: rebuild to reproduce, scatter console.logs down the chain, guess which import actually threw. And the tools built to help have all just gone dark — React DevTools shows nothing (no component mounted), the profiler has no render to profile, the error overlay gives you a line but not the shape of the code around it. They all need the app to run first. It didn't.

The one moment you most need to understand your code's structure is the one moment your code refuses to produce it.

Zero build, instant display

The Dependency Graph skips the build step entirely. Open a file and it parses the import tree to an AST and draws it in real time — no bundling, no dev-server round-trip, no waiting. That alone is the everyday time-saver: you see the whole reachable module graph the instant you ask for it, not after a rebuild.

And because the map is parsed from source rather than observed from a run, it has a property no runtime tool can match: it still renders when the canvas has completely crashed. A broken page isn't a dead end — it's the graph's primary entry point.

Two ways to know a codebase

There are only two ways for a tool to learn the shape of your project, and the difference decides everything about when the tool is available to you.

Runtime introspection — needs a successful render. React DevTools, profilers, error overlays. Reads the live fiber tree after mount, knows real prop values — but only if they exist. Goes completely dark when the render throws, and can't see a module that failed to initialize.

Static AST analysis — needs nothing to run. CrossUI's Dependency Graph parses each file to an AST and reads its imports. Knows structure — every edge, before execution — indifferent to whether the app renders, and maps the broken module and its neighbors.

Runtime tools are richer when they work. But they are conditional on success. Static analysis is poorer in some ways — it can't tell you what a variable held at 2:04pm — but it is unconditional. It works on a codebase that has never once rendered cleanly. That property is the whole point.

Reading the graph

Set any file as the ENTRY and the panel scans outward from it. Every node is tagged so you can place it at a glance: Entry, 📄 Local, 🌐 Ext, and ⟳ Cyclic.

Hover or select a node and animated lines trace its relationships in two directions — and the direction is the whole point:

Solid lines — downstream. The modules this file imports.
Dashed lines — upstream. The parents that import this file.

The search box highlights matching nodes live; the failing module blinks so your eye lands on it without hunting.

Click any node and the inspector slides out — your troubleshooting console for that file. It shows the resolved path, the raw source string and its resolvedSource, and, when parsing hit trouble, the exact error in red with line and column:

Inspector · TreeSitter.js                     📄 Local
  specifiers       { parserInstance }
  source           ./TreeSitter.js
  resolvedSource   Engine/src/TreeSitter.js
  error            Parser engine initialization aborted · Line 32, Column 12
  interceptor      [ intercept source… ]
  override         [ override resolved path… ]

Navigation note: mouse-wheel pans vertically, Shift+wheel pans horizontally, Ctrl+wheel zooms on the cursor — so a huge graph stays fast to move through.

Cycles, in red and one click away

The engine detects circular references and draws the offending edge in red. A Show cycles filter in the bottom-left isolates just the nodes caught in a loop. Inside the inspector, a node in a cycle shows the full closed-loop chain — and hovering the chain highlights every related node on the canvas, while clicking a name in the chain selects and focuses that file. Circular imports are the quiet cause of a whole genre of bugs — a module that's undefined at first access, lazy chunks that won't split, "works on the second hot-reload" gremlins. The graph just shows you the loop instead of making you find it by accident.

The part that's actually new: bypass the broken module

Finding the blinking node is good. But the Dependency Graph goes one step further than any read-only map: it lets you swap the broken dependency for a mock and bring the render back — without editing the file and without a rebuild. Two injection levers, both in the inspector:

Interceptor — match on the import … from 'yyy' declaration. The source string shown on the node is exactly the word you intercept.
Override — match on the final physical path the system resolved to. The resolvedSource on the node is exactly the path you override.

Configure either, then click the highlighted Apply Dependency Injection button in the top toolbar. Studio injects your rule into the current rendering context and attempts to restore the visualization — the deep, crashing module is now standing in for itself with something that renders. And the rules auto-persist, keyed by the entry file: reopen the same page tomorrow and your injection is already in place.

A read-only graph tells you where it broke. This one lets you route around the break and keep working — the file untouched, the page alive.

The render-error resolution flow

Locate the blinking node. Open the graph from the error overlay's Show Dependency Graph link. The module that crashed the render is already blinking.
Investigate the root cause. Follow the line/column on the node, double-click to open that exact file, and find the offending code.
Isolate with injection. If a deep dependency is the cause, set an interceptor (on source) or override (on resolvedSource) in the inspector to swap it for a mock.
Apply to restore the render. Click Apply Dependency Injection. The rule is injected into the rendering context and the page attempts to come back — no rebuild.
Persistence handles the rest. Your rules are saved locally against this entry file and restored automatically next time. Re-enter nothing.

Why this is the same thesis as everything else

If you read our first post, this will feel familiar. The reason a CrossUI visual edit produces a one-line git diff is the same reason the Dependency Graph survives a crash and can inject around it: we treat your parsed source as the source of truth, and every surface is just 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 — and injection is a controlled rewrite of how one edge resolves. None of it depends on your app successfully running, because none of it is built on the runtime. That's a constraint we chose on purpose — it's harder to build, and it's exactly what keeps the tooling alive in the moments runtime tools abandon you.

What it can't do — honestly

Static analysis buys unconditional availability by giving up runtime knowledge. The boundaries are real and we'd rather name them:

Fully dynamic imports are unresolvable. A dynamic import('./pages/' + name) with a runtime-computed path can't be resolved statically — we mark the edge rather than guess wrong.
It shows structure, not values. The graph tells you AIPanel reaches TreeSitter; it can't tell you what the parser returned this particular render. Injection mocks the dependency; it doesn't replay the runtime state.
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.

None of those change the core promise: the graph is there when you're stuck, and it can route you around the break — because it never needed your code to run.

→ Open Studio — crash a deep dependency, watch the graph point at it, then inject a mock and click Apply.

Try it free → studio.crossui.com

Add "Try in Studio" to Your React Tutorials in 5 Minutes

Jack Lee — Mon, 22 Jun 2026 14:40:38 +0000

~7 min read ·TUTORIAL

Your readers copy-paste your code examples. Wouldn't it be better if they could try them live, in the browser, right from your article? Add an "Open in Studio" button with a single script tag. No build, no local setup, no dependencies.

Bridge is how Studio reaches your audience. If you write React tutorials, teach courses, sell component templates, or build UIs for clients — one button turns your static code examples into live, editable Studio workspaces. This is how you set it up.

FOR PARTNERS

This is how partners bring Studio to their audience. Add one line of code and your tutorials, courses, or templates get a visual IDE built in. Your readers learn better. Your students skip setup. Your templates sell themselves. Your clients sign off faster.

Why Bridge?

You already have great content, courses, or templates. Bridge makes them more valuable with zero effort on your side:

For Tutorial & Content Partners: Transform static snippets into live, tweakable playgrounds. Readers experiment instead of just reading. No hosting, no infra — it's free and maintenance-free.
For Template Authors: Offer buyers a "Try Before You Buy" visual preview. They visually edit layouts without touching React code, drastically reducing support tickets. Templates sell themselves.
For Instructors & Bootcamps: Your students get free Pro for 1 month per cohort. They skip npm install, environment hell, localhost issues. Jump straight into visual React learning. Your course feels more premium.
For Agencies: Co-design UIs with clients in real-time. Visual edits immediately generate clean, PR-ready React code. Sign-offs faster, less back-and-forth.

One button. Your audience gets a better experience. You get more value from the work you've already done.

Three integration paths

Pick one based on your site's tech stack:

Path 1: HTML Form (Simplest)

Works on static blogs, markdown CMS, or anywhere you can paste raw HTML. Just a form with a button.

Step 1: Copy this HTML

<form action="https://studio.crossui.com/public/bridge.php" method="POST" target="_blank">
  <textarea name="code" style="display:none;">
import React from 'react';
import { Button } from '@mui/material';

export default function Demo() {
  return <Button variant="contained">Hello!</Button>;
}
  </textarea>

  <input type="hidden" name="ref" value="YOUR_REF_CODE">

  <button type="submit">Open in CrossUI Studio</button>
</form>

Step 2: Customize the button (optional)

Style it to match your site. It's just a standard form button — use your own CSS. Add an origin parameter if you want to track which page sends traffic (helpful for knowing what's working).

<input type="hidden" name="origin" value="my-react-tutorial-page">

Step 3: Paste the React code

Replace the import React... block with your actual component. That's it. You're done.

Styling? Add CSS to the button element. It's just a standard form button. You can style it however you want.

👉 Live demo — HTML Form

Path 2: JS SDK (Most Automatic)

For documentation sites or blogs where you have many code blocks. The SDK automatically finds them, injects buttons, and handles the rest.

Step 1: Add the script

<script src="https://studio.crossui.com/public/CrossUI-Bridge-Client.js"></script>

Place it near the end of your <body> tag.

Step 2: Initialize with your config

<script>
CrossUIBridge.init({
  selector: 'pre code.language-jsx',  // Target JSX blocks
  ref: 'YOUR_REF_CODE',              // Your partner code
  origin: 'my-blog'                  // Optional: analytics
});
</script>

The script scans your page for code blocks matching that CSS selector and adds a button to each one.

👉 Live demo — JS SDK

Markdown blog? Most markdown renders code as <pre><code class="language-jsx">...</code></pre>. Set selector: 'pre code.language-jsx' (or your markdown's class). The SDK does the rest.

Path 3: Server-Side (Most Flexible)

For premium template marketplaces or enterprise sites where you want to validate the user's purchase before showing them the code. Your backend receives the request, checks the user's access, and if OK, injects your partner code before redirecting to Studio.

See the GitHub bridge folder for full examples in Node, PHP, C#, and Java.

What do your readers / students / clients get?

One click. Zero setup. They land in Studio with full IDE power:

Instant feedback: Edit code, see changes live on the canvas in real-time (SCD — Synchronized Code & Design)
No environment hell: No npm install, no localhost, no waiting. Works in any browser, on any device.
Visual + Code: Drill down any layer in the component tree, edit styles visually, tweak props, understand the structure.
Guest access: No sign-up required. They get the full IDE experience immediately.

Result: Your readers learn better. Your students skip friction. Your templates show themselves. Your clients buy with confidence.

Ready to bring Studio to your audience?

Three easy steps:

Pick your integration path — HTML Form (simplest), JS SDK (most automatic), or Server-Side (most control)
Read the full guide: See the GitHub bridge folder for all three paths with code examples in Node, PHP, C#, and Java.
Apply to become a partner: Fill out the partnership form and we'll get back to you in 48 hours with setup docs and everything you need.

Bring Studio to your audience.

Make your content interactive. Make your courses friction-free. Make your templates sell themselves.

Become a Partner →

Try it free → studio.crossui.com

Why we rejected the export-and-fork model for visual UI editing

Jack Lee — Mon, 22 Jun 2026 13:16:56 +0000

~10 min read · Engineering

There are roughly three honest ways a visual editing tool can relate to your codebase.

The first is export and fork: you design in the tool, it generates code, you paste it into your project, and from that moment forward the tool and your repo are strangers. This is how most AI code generators (v0, Bolt, Lovable) work — and for greenfield components, it's fine. You generate, you customize, you ship.

The second is SDK ownership: the tool becomes a runtime dependency. Your components are stored in a proprietary model, rendered via the tool's SDK, and deployed through the tool's infrastructure. Leave the tool, and you're migrating a schema, not just moving files. This is roughly how Plasmic and Builder.io work — and again, for the right use case (marketing pages, designer-editable CMS content), it makes sense.

The third — the one we bet CrossUI Studio on — doesn't have a clean industry name yet. We call it Symmetric Collaborative Development (SCD): your React source code is the single source of truth, and the visual canvas is a peer editor of that source. Every visual change is written back to your file as a precise AST patch. No export step. No SDK. No lock-in. Stop using the tool tomorrow and nothing breaks.

This post explains why we think the third model is the right one for senior engineers maintaining real codebases — and what it actually takes to build it.

TL;DR. If your existing repo is the source of truth and you want a visual layer over it, the editor has to write back through the AST — atomically, one property at a time — or it will lose against your code reviewer. Everything else is a different product for a different team.

The git diff test

Here's the simplest way to evaluate any visual editor. Three steps:

Open the tool with a real MUI component already in your codebase.
Change variant="text" to variant="contained" on a button.
Run git diff.

Every "design-to-code" tool I evaluated over the last five years failed this test, in one of two ways. Either the file was re-emitted entirely — comments stripped, formatting normalized, imports reshuffled, hand-tuned useMemo blocks subtly rearranged — or the tool refused to touch existing files at all and emitted a parallel "design document" we then had to glue back into the project.

Neither was acceptable for a team that takes diff hygiene seriously. We rejected three tools in a row on this basis.

The third time, I decided the category itself was wrong.

Why "re-emit the file" is such a hard habit to break

If you read how most visual editors are architected, the root assumption is: the tool owns the rendering model. The tool maintains its own representation of the component tree — either in a proprietary schema or in an in-memory tree — and "saving" means serializing that representation back to JSX.

Serialization is lossy by nature. The tool's model doesn't know about your comment. It doesn't know why you named a variable isSaving. It doesn't know that your /* Main content area */ block comment is something a human will read in code review. So when it writes back, it writes what it knows — the component structure, the props, the styles — and silently discards everything it doesn't.

The result is a visually identical file that is a conceptually different file. Same output, different authorship. If you're a senior engineer who cares about your codebase, that's enough reason to never use the tool again.

The only way to avoid this is to not use serialization at all. Which means working at the AST level from the start — and the AST is hard.

What AST-level sync actually requires

Abstract Syntax Trees are how JavaScript parsers represent code internally. Every identifier, every JSX attribute, every function call has a position in the tree. If you want to change variant="outlined" to variant="contained", you don't re-serialize the whole file — you find the JSXAttribute node whose name is variant, update its StringLiteral value, and write back only the characters that changed.

This is what CrossUI Studio's engine does. The practical consequences:

Formatting is preserved. We don't pass the file through Prettier on every visual edit (though we do run Prettier on deliberate code saves). The unchanged bytes don't move.

Comments survive. AST nodes have attached comment ranges. We track them and leave them where they are.

Business logic is untouched. The engine identifies which AST node corresponds to the visual change and patches only that node. Your custom hooks, your useCallback wrappers, your conditional rendering logic above and below the component — we don't touch any of it.

The undo stack is unified. Whether you typed in the code editor, dragged a component on the canvas, or changed a value in the inspector, every operation is a reversible AST mutation. Ctrl+Z rolls back the code and the canvas in sync.

The visible result for the engineer:

   {/* keep until the new spec lands — Jordan, Apr 14 */}
   const total = useMemo(() => sum(order.items), [order])
   return (
     <Card sx={{ p: 2 }}>
-      <Button variant="text" onClick={handle}>Pay</Button>
+      <Button variant="contained" onClick={handle}>Pay</Button>
     </Card>
   )

One line removed, one line added. The comment, the useMemo, the surrounding JSX — byte-identical to before. The diff that lands in code review is exactly the change the engineer would have typed.

The depth problem: why `.map` is the real test

Even among tools that do some form of code-aware editing, almost all share the same limitation: they can only operate on the outermost JSX block.

Consider this common pattern:

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

A typical visual editor sees the map expression. It cannot edit the Card inside it visually — because to render a canvas for the Card, it needs to know what item is, and item only exists at runtime inside the callback.

CrossUI's Layer Drill-down Engine solves this with a Test Data Injector. When you drill into a .map callback, Studio asks: "what's the shape of item?" You provide a mock value — or it infers one from surrounding usage — and Studio renders an isolated canvas for the inner block, with item injected as a real prop. You edit the Card visually. The changes are written back to the callback body as precise AST patches. The outer items.map(...) expression is untouched.

The same mechanism works for ternary branches (cond ? <A/> : <B/>) and children render slots. You can drill any depth your component tree requires.

This is the feature that separates a toy from a tool you'd actually use on a production codebase.

MUI isn't generic React

One more thing the "re-emit" tools get wrong: they treat all React components the same.

MUI components have a richer prop surface than native HTML. variant, size, color, elevation, sx — these aren't just className strings. They're typed, enumerated, and in some cases highly structured. The sx prop accepts a deep object with pseudo-class keys, state-based keys, and responsive breakpoint objects like { xs: 'small', md: 'large' }. Generic React visual editors render an untyped text field for sx and call it done.

CrossUI Studio ships a dedicated MUI panel with:

Enumeration completions for every MUI prop value (correct values, no guessing).
sx tree editor — nested objects, pseudo-classes, and media queries in a structured visual tree.
Responsive property promotion — click the lightning icon next to any MUI system prop and it splits into a breakpoint object. Change the value at LG and the code becomes size={{ xs: 'small', lg: 'medium' }} automatically.
Design Token access — your custom createTheme() tokens surface in the inspector.

These aren't features you can retrofit onto a generic visual editor. They require knowing what MUI is, how it works, and where the edge cases are.

What we gave up

The SCD model has real costs. It's why most tools don't do it. We owe an honest accounting:

We don't work on every React codebase. If your components are deeply entangled with SSR edge cases, or your bundler produces non-standard output, the AST layer may not parse cleanly. We document the boundaries instead of pretending they don't exist.
Focus is our superpower. No Vue, no Svelte, no Angular — not on the roadmap. We'd rather be the best possible tool for one ecosystem than a mediocre tool for five. We are dedicated exclusively to the React ecosystem, deeply supporting leading design systems like MUI and shadcn/ui, with expandable support for Joy UI, Ant Design, and beyond.
We don't generate apps. If you want to prompt your way to a working dashboard, use v0 or Bolt. They're genuinely good at that. We're for engineers who already have a codebase and want a canvas that respects it.
We don't host your code. No CrossUI-side storage. Git operations are direct browser-to-provider. That's a feature, but it also means we can't offer cloud workspaces, team collaboration on a shared document, or any of the conveniences a hosted model enables.
We evolve alongside the ecosystem. We closely follow major updates of our supported component libraries. While we prioritize empowering teams on the latest versions with robust, modern alignment, we continually evaluate expanding our backwards compatibility. If you are locked into legacy framework versions, we might not be the right tool for you — yet.

The decision

Three honest recommendations, no false modesty:

If you're…	…use
Building a marketing site that designers need to edit	Plasmic
Prototyping from scratch and want AI generation speed	v0 or Bolt
Handing Figma files off to engineers, once	Locofy or Anima
Maintaining a React + MUI codebase, care about your git history, want a visual canvas that treats your code as the source of truth	CrossUI Studio

The Playground is free, works immediately, and doesn't require connecting a repo. Paste any React snippet and see it on the canvas.

Try it free → studio.crossui.com

CrossUI Web App Builder

Jack Lee — Mon, 13 May 2019 21:46:10 +0000

https://crossui.com/RADGithub

Explore the benefits of the no code app builder
You no longer need to hire an app developer to create an application for you. Create a fully interactive and responsive HTML5 application without writing a single line of code with CrossUI Front-end Builder. It’s much faster, easier and more fun to do app development without coding. Just choose the necessary template, modify all the elements you need and launch. Whether you need to create an interactive prototype, database management app or build a management information system, you can do it with the Cross UI app builder within several days.

What you can do with CrossUI no code app builder
If you hired a developer, you would have spent as much time explaining the concept as it took you to do it yourself with CrossUI. With CrossUI, every person who is familiar with business logic can build an application. Just make sure that your data can be stored in a database, entered with a form and displayed in common charts, tables, or rows. Our builder has an easy-to-navigate menu and a set of features that will allow you to design and build your HTML5 application within a few days. Just create what you imagine. Here are the things you can do with the CrossUI builder:

Use built-in templates relevant to the type of application you want to build.
Drag and drop the objects to the desired location.
Use and edit 100+ UI widgets. Among them are buttons, inputs, lists, tabs, shapes, diagrams, charts and other.
Create customized reusable modules.
Bring in interaction by using events actions that can be easily configured.
Call Remote Service EndPoint. No coding is required.
Publish your app where you want, on any desktop (Linux, Windows, Mac PC/Mobile), or any website.
Embed the WYSIWYG designer, our designer product, into the application you already have. The exported APIs and Events offer customization flexibility to developers.

Benefits of no code apps
Create an app without coding to quickly get custom solutions to your business needs. According to a Quick Base report, no code app builders can help save money, increase productivity, and work efficiency. Use CrossUI to save time and remain 100% focused on your business. It is especially beneficial for small businesses that don’t require complex solutions. If you need to organize inventory information, keep track of your business contacts, manage customer data, you can do it with an app, developed with an app builder specifically for your case. CrossUI front-end builder has a user-friendly dashboard and admin panel that make updates a breeze. You can entirely customize your application's behavior without writing code. Its API tools allow connecting apps to your own back-end software. The library of pre-built application elements reduce development time and accelerate production. CrossUI builder can be used for commercial projects as well as non-profit ones. If you are a student who wants to learn how to create an app with no coding, or if you have personal, not-for-profit projects, we can offer you a license at a special price. Check out our prices on the Purchase page. Keep in mind, that each license is bound to one PC only. If you are interested in reselling our products, please contact our sales department. Build an app without code which is powerful enough to support your most ambitious ideas!

DEV Community: Jack Lee

Editing React components that never rendered

Two ways to know a codebase

The moment tooling abandons you

Editing what you can't run

The cost of the constraint

Why this is one idea, not many

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

The depth problem, concretely

Step 1 — Drill into the iteration

Supply the missing context: the Test Data Injector

Step 2 — Edit the inner node

Step 3 — Cross the file boundary

Why it can do this

Try it

Developer sovereignty: what "no lock-in" actually means

The exit test

What we put in writing

Why we can actually promise this

Sovereignty is a feature, not a disclaimer

The honest version

Your AI writes the logic. Studio tunes the UI. They don't compete.

What AI is actually good at

What AI is genuinely bad at

Where each tool belongs

The pairing in practice

What this means for "AI replacing developers"

Don't just find the broken import. Bypass it.

The blank-screen problem, five levels deep

Zero build, instant display

Two ways to know a codebase

Reading the graph

Cycles, in red and one click away

The part that's actually new: bypass the broken module

The render-error resolution flow

Why this is the same thesis as everything else

What it can't do — honestly

Add "Try in Studio" to Your React Tutorials in 5 Minutes

FOR PARTNERS

Why Bridge?

Three integration paths

Path 1: HTML Form (Simplest)

Path 2: JS SDK (Most Automatic)

Path 3: Server-Side (Most Flexible)

What do your readers / students / clients get?

Ready to bring Studio to your audience?

Bring Studio to your audience.

Why we rejected the export-and-fork model for visual UI editing

The git diff test

Why "re-emit the file" is such a hard habit to break

What AST-level sync actually requires

The depth problem: why .map is the real test

MUI isn't generic React

What we gave up

The decision

CrossUI Web App Builder

The depth problem: why `.map` is the real test