DEV Community: Jack Lee

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

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

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

Reading code and understanding code are different things

Sandboxes solve the setup problem, not the structure problem

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

The dependency graph is the thing you're actually teaching

The thing that's usually a diagram

What this actually looks like in practice

The objection I keep coming back to

Why I'm thinking about this at all

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

Your browser does not support video. Watch on YouTube.

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

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

3. Open src/main.tsx and hit preview

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

5. Change something

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

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

What I would not use it for

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

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

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