Framework-native

Velloo does not force every app through one universal export format. A design folder declares component providers, and each screen uses one of them. The canvas, inspector, agent guidance, and emitted structure adapt to that provider.

Supported providers

• shadcn/ui: current upstream components from the host app, with Tailwind classes.
• Material UI v6: real @mui/material components and the sx styling channel.
• Ant Design v5: Ant Design components in their native prop model.
• Chakra UI v2: Chakra components with its styling conventions.
• No library: a small primitive set over HTML, using Tailwind when present or inline styles when it is not.

velloo init detects an existing app and recommends the matching provider. New shadcn folders use the upstream provider rather than the retired embedded snapshot described by older documentation.

A provider is not the whole catalogue

An adapter decides styling, theme projection, and codegen idiom for a library Velloo knows deeply. It does not decide which components can appear in a screen.

Your app’s own components do too. Whether they come from a package it depends on (Mantine, NextUI, a private design system) or from its own components/ directory, Velloo discovers them from what the app actually renders, draws them on the canvas from the app’s own installed copy, and emits them with their exact imports. These are repository components, and they sit on their own shelves alongside the folder’s provider.

So a library with no adapter is not a library Velloo can’t render. A Mantine app uses the no-library provider for Velloo’s own primitives — Box, Heading, Text — and its Mantine components render for real. For a popular library, a built-in recipe supplies the provider wrapper, stylesheet, and theme mapping so this works with no setup at all; Mantine is the first.

Multiple providers and host apps

The current config keeps a libraries map plus a defaultLibrary; a screen can select another registered entry when needed. Monorepos can also record several host apps so extensions resolve their imports, aliases, dependencies, and React copy against the right application.

Keep this flexibility purposeful. Most folders should have one provider. Add another when the repo genuinely contains distinct UI systems, not to mix visual styles casually inside one product.

Styling stays native

• shadcn screens use Tailwind className.
• MUI and Chakra use sx-style objects where their provider expects them.
• Ant Design uses its supported props and inline style channel.
• no-library screens use Tailwind or inline style according to the folder.

Agents style through one verb on every framework: the style field of an update_props patch entry routes into the screen’s active channel. It takes a className string for Tailwind ({ "path": "@hero", "style": "flex gap-4 p-6" }) and an object of properties for sx or style ({ "path": "@hero", "style": { "display": "flex", "gap": "16px" } }), and null clears it. A payload of the wrong shape is rejected with a message naming the shape the channel wants. On Tailwind channels, the result’s diagnostics also flag classes that don’t compile. Semantic tokens should remain the default: they keep themes connected and make later changes cheaper.

App-specific components

Reach for them in this order:

1. Repository components for anything the app already has. They render for real and emit their real import; nothing needs registering.
2. Snippets for a composition you want to reuse across screens and edit in one place. A Velloo-side abstraction, not an app component.
3. Extensions for a dynamic leaf that can’t render as a normal node — a chart wired to a live data layer — where a bundled visual island beats a tree of nodes.