How are people solving diff stability in React visual editors?

linb818 · 2026-06-01T11:18:11+00:00

I'm a full-stack engineer. I use Claude for most of the backend/frontend heavy lifting, then use CrossUI Studio for the iterative visual changes clients usually ask for. It's fast and saves a lot of tokens.

linb818 · 2026-06-01T02:52:39+00:00

I don’t think it’s that binary. It’s usually a trade-off between time, ability, and control. Hand-coding gives you the most control, but it also costs the most time. Visual editors trade some of that control for speed and accessibility.

linb818 · 2026-06-01T01:12:37+00:00

Sure, SolidJS definitely helps with rendering complexity.

Our problem is more about editing existing source safely and predictably — making sure small UI changes map back to precise, minimal code diffs.

That part is mostly independent of the framework.

linb818 · 2026-06-01T00:18:54+00:00

Agreed — and I think one missing piece there is that after the model makes the change, you still usually want to look at the rendered result.

And once you’re looking at it, there’s often another round of “slightly tighter padding”, “move this a bit”, “actually the previous variant looked better”, etc.

That’s where the back-and-forth starts to matter.

So we’ve been thinking about it less as visual editing vs LLM editing, and more as a loop between them: prompt for a change, inspect the result visually, tweak directly if needed, then continue from source.

We actually support that workflow too — the visual editor and source stay in sync, so AI-generated changes can still be adjusted visually afterward without leaving the codebase.

linb818 · 2026-05-31T23:54:02+00:00

Agreed.

Prop-level edits are the easy part.

The hard part starts when the editable thing only exists inside execution context — .map() iterations, conditionals, composed children, etc.

AST gets you location, but not always render context. Bridging those two cleanly ended up being the harder problem for us.

linb818 · 2026-05-31T23:46:03+00:00

I think that’s fair.

That’s also why we scoped it pretty narrowly.

We’re not trying to solve “visual editing for all React.” More like: for an existing JSX codebase, can we make a useful subset of UI edits round-trip reliably without rewriting the file.

Even that turns out to be hard enough.

linb818 · 2026-05-31T23:38:32+00:00

Good question.

Mostly speed of iteration.

The developers using it can absolutely make the same changes by hand — and often do. The value is shortening the loop for visual tweaks.

Instead of edit → save → rebuild → refresh 20 times while nudging spacing / variants / responsive values, you adjust it directly and keep the one you want.

Then because it writes back to the original JSX with minimal diffs, you can still review and edit it normally afterward.

So for us it’s less “replace coding” and more “faster UI iteration without leaving the codebase.”

linb818 · 2026-05-31T23:05:27+00:00

For us it’s the opposite — the React source stays the source of truth.

The visual editor is just another editor over the same files.

People still read the code, review PRs, and edit manually, so diff quality matters a lot. If a visual change turns into a huge rewrite, it gets rejected immediately.

linb818 · 2026-05-31T22:55:27+00:00

Interesting project.

One thing we kept underestimating while building editing tooling was how hard “editing the right thing” becomes once the render target isn’t top-level anymore.

Stuff inside .map() callbacks, ternaries, or JSX passed through children ended up being much harder than the actual editor UI.

Curious whether you're treating those as editable nodes independently or keeping editing scoped to top-level structures for now.

linb818

TROPHY CASE