I take a lot of notes while I'm working. Meeting notes, quick ideas, system design sketches — all of it ends up somewhere.
The frustrating part was never writing the notes. It was what happened after. I'd describe a UI idea in a note — a color picker, a calculator, a data formatter — and then I'd have to open a separate editor, build the thing, test it, and come back. The note and the tool lived in completely different places.
At some point I thought: what if the tool just lived inside the note?
That's what I've been building for the past few weeks. You type /ai in the editor, describe what you want, and a working interactive component appears inside your document. Not a screenshot. Not a code block. A real, running UI.
Here's what that looks like mid-generation:
This is the streaming moment — the AI is writing the component live, and it appears inside the note as it generates.
Let me walk through how I built this.
The editor foundation
I'm using Tiptap — a headless, extensible rich text editor for React. Tiptap is built on ProseMirror, which means you can define custom nodes: blocks that behave however you want inside the document.
I created a custom AiNode — a Tiptap node that holds generated HTML/CSS/JS as a string in its attributes. When the node renders, it shows a live iframe. The node persists to Supabase as part of the document's JSON content.
const AiNodeExtension = Node.create({
name: 'aiComponent',
group: 'block',
atom: true,
addAttributes() {
return {
code: { default: '' },
prompt: { default: '' },
}
},
// ...
})
Simple enough. The hard part was getting the code into the node while streaming.
The streaming problem
The AI backend uses Gemini 2.5 Flash via Server-Sent Events. The model streams the HTML, CSS, and JS as one big string — character by character.
The problem: I needed to show this output live inside the Tiptap node while it was still being generated. Users shouldn't stare at a spinner for 10 seconds.
My first approach was to update the rendered output on every streamed chunk. It worked, but it caused too many re-renders and made the editor feel heavy.
The better approach was to decouple streaming from rendering: accumulate the generated code in a ref while the stream is active, then render the final result once inside a sandboxed iframe.
const accumulated = useRef('')
// On each chunk:
accumulated.current += chunk
// On stream close:
editor.commands.updateAttributes('aiComponent', {
code: accumulated.current
})
The node re-renders once, the iframe appears, the component runs.
The sandbox setup
The iframe uses this sandbox configuration:
<iframe
sandbox="allow-scripts"
srcdoc={generateSrcdoc(code)}
/>
Notice what's missing: allow-same-origin.
This is intentional and critical. Without allow-same-origin, the iframe cannot access localStorage, cookies, or the parent document's DOM. The AI-generated code runs in complete isolation. It can't read your tokens, it can't exfiltrate data, it can't touch anything outside its own sandbox.
allow-scripts alone is enough for interactive components to work — timers, event listeners, DOM manipulation inside the frame, all fine.
I also inject Tailwind CSS via CDN inside the iframe's srcdoc so generated components can use utility classes without any build step:
function generateSrcdoc(code) {
return `
<!DOCTYPE html>
<html>
<head>
<script src="https://cdn.tailwindcss.com"></script>
<style>
body { background: #09090b; margin: 0; padding: 16px; }
</style>
</head>
<body>${code}</body>
</html>
`
}
The refine system
Once a component is generated, users can update it with natural language. There's a "Refine" button in the component toolbar. You type something like "make the background darker" or "add a reset button" — and the component updates.
The naive approach would be to regenerate the entire component from scratch. That works but it's slow and wasteful.
Instead, I built a /api/edit endpoint that receives two things: the current component code and the edit instruction. The system prompt wraps them together:
You are editing an existing UI component.
Current code:
[CURRENT_CODE]
Edit instruction:
[INSTRUCTION]
Return only the updated full component code. No explanations.
The model returns the full updated component — but it only needs to reason about the delta. In practice this is faster and produces more coherent edits than full regeneration.
The response streams the same way as generation, and the node updates when it's done.
What I got wrong
A few things that cost me time:
Stale closures in Tiptap. If you reference editor inside a useEffect without including it in the dependency array, you'll be working with a stale editor instance. Commands will silently fail. This one took a while to track down.
Rate limiting before you think you need it. I added Upstash Redis rate limiting to both endpoints early on. Good call — during testing I hit Gemini's limits faster than expected. Shared rate limiter utility across both endpoints so I wasn't duplicating logic.
The middleware gap. My Next.js middleware was redirecting unauthenticated users to login — including the /share/ route for public documents and the /api/ routes. Had to explicitly whitelist these paths. Simple fix, annoying to debug.
Where it is now
The app is called Fluxerv. It's a workspace where your documents can contain live, interactive tools — not just text.
Here's a 2-minute demo of it generating a pomodoro timer from a single prompt:
The stack: Next.js (App Router), Tiptap v3, Supabase, Gemini 2.5 Flash (starting point — will scale up as needed), Tailwind CSS, Upstash Redis.
It's currently in private beta. If you want early access when it opens, follow me on Twitter — I post build updates there.
If you've built something similar or ran into the same iframe/streaming problem, I'd love to hear how you solved it. Drop a comment.
Top comments (0)