The editor and the generated code describe the same thing: one design file becomes one component, one element becomes one tag, and every logic block has a code equivalent. That one-to-one mapping is why the output reads like code someone wrote.
This page is the mental model. For the practical steps see Export your code; for the exact shape of the output see Export output.
A component file exports as a .tsx and a .module.scss sharing its name. The element tree becomes the JSX tree, one node per element, in the same order and nesting you see in the ELEMENTS panel.
If you can find it in the tree, you can find it in the JSX — and nothing appears in the JSX that the tree does not show.
Element — a div (or svg, path, input, … by type).
Component instance — an import plus <Name.Component />.
Style panel values — one generated class per element in the .module.scss.
Style variants — extra classes, composed via a variant prop.
Screens / breakpoints — @container queries.
Properties — the component's typed properties prop.
States — useState.
Events — onClick, onMouseEnter, … handlers.
Conditions — ternaries and guards around the JSX.
Repeats — .map() over the bound data.
Timelines — a timelineData(id) export, handed to the runtime's player.
Design-system tokens — CSS variables.
Children slots — a typed children object of named slots.
Mounted APIs, storage and CMS data — the loader hooks the component reads from.
Validators — the field rules, as the form's validation config.
Code components — your React source, transpiled alongside the wrapper.
Mockups are the deliberate exception: they never reach the output at all. See Projects and files.
Each element gets one generated class. The class names are derived from the node's identity rather than its role, so they look like .Echqv58 — stable across exports, and scoped by the CSS module so two components can never collide.
Interaction states export as real CSS, not JavaScript:
.Eag51ew { background: #333333ff; }
.Eag51ew:hover { filter: drop-shadow(0px 5px 10px #00000033); }That matters for performance and for server rendering: a hover doesn't need React to re-render.
A timeline exports as a timelineData(id) function — a list of targets and keyframes — handed to the runtime's player. Playback is then driven either automatically (on mount, on scroll, on entering view) or by your component's state.
Timelines are data rather than CSS animations because they need to sequence many elements against one clock, scrub with scroll position, and interpolate things CSS cannot — mesh gradients and path shapes. (Shader parameters can be keyframed in the editor, but those keyframes do not reach the exported code yet: the runtime shader takes a static parameter set.)
Some things a design expresses have no plain-HTML equivalent: the timeline player, mesh gradients, shaders, responsive containers, state and storage helpers. Those live in the misaki-studio-internal npm package, and the generated code imports it as msi.
So the output is your component plus one shared runtime, instead of the same helpers duplicated into every file.
Export regenerates each file wholesale from the design. There is no merge step and no attempt to preserve hand edits, which is what keeps the design and the code guaranteed to agree.
The header says so on every file:
// This file is generated by Misaki Studio. Do not edit.To extend a component, import it and wrap it in a file of your own. Your code and the generated code stay separable.
Export output — the exact shape of the files.
Export your code — the practical steps.
Examples — real exported components from this site.