{"id":78980,"date":"2026-07-03T12:57:51","date_gmt":"2026-07-03T12:57:51","guid":{"rendered":"https:\/\/10web.io\/blog\/?p=78980"},"modified":"2026-07-03T12:57:51","modified_gmt":"2026-07-03T12:57:51","slug":"building-a-visual-point-click-editor-on-top-of-agent-generated-react-what-it-takes","status":"publish","type":"post","link":"https:\/\/10web.io\/blog\/building-a-visual-point-click-editor-on-top-of-agent-generated-react-what-it-takes\/","title":{"rendered":"Building a Visual Point-&-Click Editor on Top of Agent-Generated React: What it Takes"},"content":{"rendered":"

When a user clicks a hero section and changes the font size, what they see is simple. What has to happen is not: the browser knows what they clicked, but the React source code the agent wrote has no native concept of which element that DOM click corresponds to. Connect those two things and the edit has to travel back into the source without breaking anything around it, and then stay synchronized with what the agent sees the next time it runs.<\/span><\/p>\n

That’s the problem. It’s a sync problem, running in both directions, across three systems that weren’t built to know about each other.<\/span><\/p>\n

Building 10Web’s visual editor on top of agent-generated React means solving problems traditional editors never had to face. Traditional editors controlled the code they were editing. We didn’t.<\/span><\/p>\n

The difference <\/span><\/h2>\n

Traditional visual editors generate the code, own the schema, and know exactly what they wrote. That assumption makes every other problem tractable.<\/span><\/p>\n

An agent doesn’t write for an editor. It writes for a browser. By the time 10Web’s visual editor needs to operate on that output, the agent is done. Three systems now have to stay in sync: the rendered DOM the user clicks, the React source the agent wrote, and the backend source that persists between sessions. They share no common data structure, and none of them was designed to know about the others. Every problem that follows is a problem of keeping those three aligned.<\/span><\/p>\n

Connecting a click to a line of code<\/span><\/h2>\n

What it takes<\/b>: a traceable element identity built into every JSX node before the preview renders.<\/span><\/p>\n

Nothing in the browser connects a rendered DOM node to a source file. Once code is compiled and served to an iframe, that context is gone. You have to build the bridge before the click fires.<\/span><\/p>\n

We inject a traceable identity into every JSX element at transform time in 10Web’s build pipeline. It encodes the element’s location in the source. When a click fires, it resolves to that identity, which resolves to the source position. The bridge exists before the interaction begins.<\/span><\/p>\n

Nested elements complicate this. A span inside an h2, or child nodes with no distinguishing attributes, can resist clean identity resolution. For those cases we support alternate encoding strategies, including position-based encodings for backward compatibility with older agent output. A system that operates on code it just generated can make stronger assumptions. We handle multiple generations of 10Web agent output.<\/span><\/p>\n

Writing the edit back without breaking the file<\/span><\/h2>\n

What it takes<\/b>: structurally precise source modification, a decoupled update path, and three layers of state that have to agree.<\/span><\/p>\n

Text manipulation is the wrong tool. The file is code, and replacing a string at a character position risks corrupting adjacent nodes. <\/span><\/p>\n

The modification has to be structural: <\/span><\/p>\n