Shipping production code from a visual canvas

The fastest way to lose a developer’s trust is to show them generated code they would never commit. Nested divs, inline styles, class names like div-block-7. It works in the demo and dies in the pull request.

Export is where most visual tools quietly give up. We treated it as the product.

The output is the component

When you compose in Plus UI, you are arranging real components from the design system. Export doesn’t re-interpret a canvas into markup — it serializes the component tree you already built.

import { Button } from "@plus-ui/react";
 
export function Hero() {
  return <Button variant="primary">Start a project</Button>;
}

That is the export. Typed props, named imports, the same component a teammate would write by hand.

Tree-shaken by construction

Because components are imported by name, a page ships only the code it uses:

• Named imports, never a wildcard barrel.
• Server components by default; client code only where interaction lives.
• Styling through tokens, so there is no per-page stylesheet to prune.

The result is a page weight that tracks what is on the page, not what is in the library.

Code you would have written

The test we hold export to is simple: would a senior engineer approve this in review? If a line would draw a comment, that is a bug in the exporter — not a quirk to explain away in the docs.

Composition is the fast part. Code you can keep is the hard part. The hard part is the one worth owning.