with one click
migrate-lovable
Convert SSR-heavy Lovable/v0 apps into client-only Domo apps.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
Convert SSR-heavy Lovable/v0 apps into client-only Domo apps.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Step-by-step orchestrator for building Domo App Studio apps with native KPI cards via community-domo-cli. Sequences app creation, pages, theme, hero metrics, native charts, filter cards, layout assembly, and navigation. CLI-first — no raw API calls.
Domo KPI card CRUD via community-domo-cli — body schema, column mapping, beast modes, chart type index with on-demand reference files, and gotchas.
**Generating sample data for Domo** -- invoke when a user needs to create realistic sample datasets and upload them to a Domo instance. Primary signals: requests for sample data, demo data, test data, fake data for Domo; mentions of Salesforce, Google Analytics, QuickBooks, NetSuite, Google Ads, Facebook Ads, HubSpot, Marketo, or Health Portal sample data; questions about the datagen CLI or domo_data_generator. Covers: generating datasets, uploading to Domo, creating datasets in Domo, rolling dates, entity pools, connector icons, catalog management, and adding new dataset definitions. Skip for: real connector setup, production data pipelines, data transformations (Magic ETL), or Domo App Platform.
Create AppDB collections via CLI-first workflows where collection creation also provisions the required datastore, then returns collection identifiers for manifest wiring and document-write follow-up. Use when an agent must initialize new AppDB storage for a Domo app, not just list/get collections or create documents.
Create Domo Code Engine packages from CLI workflows with deterministic payload contracts, automatic function parameter datatype mapping, and manifest packagesMapping follow-up guidance. Use when an agent must create a new package/versioned package container rather than only invoke an existing function from app runtime code.
Update Domo Code Engine packages through CLI-driven versioned lifecycle workflows with compatibility checks, datatype contract safeguards, and manifest mapping drift synchronization. Use when an agent must update package code or create a new package version and keep app mappings aligned.
| name | migrate-lovable |
| description | Convert SSR-heavy Lovable/v0 apps into client-only Domo apps. |
Many developers use AI tools like Lovable, v0, or similar LLM-based generators to create app prototypes. However, these tools typically generate apps with server-side rendering (SSR) that are incompatible with Domo's client-side-only architecture.
Generated apps often include:
pages/api/ or app/api/ directories)getServerSideProps, loaders, etc.)Domo apps must be:
domo.get(), Query, AppDBClient, etc. instead of backend endpointsDA CLI is NOT a conversion tool - it doesn't automatically convert apps. However, you can use it as a reference structure and starting point.
# Create a fresh Domo app to use as reference
da new my-converted-app
cd my-converted-app
# This gives you the correct structure to compare against
Check for SSR indicators:
getServerSideProps, getStaticProps (Next.js)loader, action functions (Remix)+page.server.js, +server.js (SvelteKit)pages/api/ or app/api/ directoriesprocess.env usageAction: Remove all server-side code. Domo apps run entirely in the browser.
Before (Next.js example):
// ❌ Server-side data fetching
export async function getServerSideProps() {
const res = await fetch('https://api.example.com/data');
const data = await res.json();
return { props: { data } };
}
// ❌ API route
// pages/api/users.ts
export default async function handler(req, res) {
const users = await db.users.findMany();
res.json(users);
}
After (Domo):
// ✅ Client-side with Domo APIs
import domo from 'ryuu.js';
import Query from '@domoinc/query';
import { AppDBClient } from '@domoinc/toolkit';
// Fetch from Domo dataset
const data = await domo.get('/data/v1/sales');
// Or use Query API for filtered/aggregated data
const summary = await new Query()
.select(['region', 'sales'])
.groupBy('region', { sales: 'sum' })
.fetch('sales-dataset');
// Or use AppDB for document storage
const tasksClient = new AppDBClient.DocumentsClient('Tasks');
const tasks = await tasksClient.get();
Before (Next.js):
// ❌ Next.js routing
import Link from 'next/link';
<Link href="/dashboard">Dashboard</Link>
After (Domo):
// ✅ HashRouter for client-side routing
import { HashRouter, Routes, Route } from 'react-router-dom';
import domo from 'ryuu.js';
// Use HashRouter (works without server rewrites)
<HashRouter>
<Routes>
<Route path="/" element={<Home />} />
<Route path="/dashboard" element={<Dashboard />} />
</Routes>
</HashRouter>
// For Domo navigation, use domo.navigate()
domo.navigate('/page/123456789');
Before (Next.js):
// next.config.js
module.exports = {
// Next.js config
}
After (Domo - Vite):
// vite.config.js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
export default defineConfig({
base: './', // CRITICAL: Relative paths for Domo
plugins: [react()],
});
Remove Lovable-specific Vite plugins like lovable-tagger:
// ❌ Remove this
import { componentTagger } from "lovable-tagger";
plugins: [react(), mode === "development" && componentTagger()].filter(Boolean),
// ✅ Replace with
plugins: [react()],
Lovable/v0 apps include tooling that must be removed:
Dependencies to remove:
next-themes — SSR theme provider; replace useTheme() with a hardcoded theme string (e.g. "light")lovable-tagger — Lovable's dev-only component taggerFiles to delete:
playwright.config.ts — Uses lovable-agent-playwright-configplaywright-fixture.ts — Re-exports Lovable test fixturesbun.lock / bun.lockb — Lovable uses Bun; standardize on npmApp.css — Often unused in generated apps (verify first)Fix next-themes usage in Sonner toaster:
// ❌ Before (depends on next-themes)
import { useTheme } from "next-themes";
const { theme = "system" } = useTheme();
<Sonner theme={theme as ToasterProps["theme"]} />
// ✅ After (hardcoded, no SSR dependency)
<Sonner theme="light" />
Domo requires a manifest.json in the publish directory:
{
"name": "My App Name",
"version": "1.0.0",
"size": {
"width": 10,
"height": 10
},
"mapping": [],
"fileName": "index.html",
"id": "",
"proxyId": ""
}
name — Display name in Domosize — Card dimensions (columns x rows on the Domo dashboard grid)mapping — Dataset mappings (empty array if using mock data or AppDB)fileName — Entry HTML file (always index.html)id — Leave empty; domo publish fills this on first publishREQUIRED — domo publish will fail without this.
Place a 300x300 PNG named thumbnail.png in the project root. This is used in the Domo Appstore and mobile app.
# Generate a simple thumbnail programmatically (Python + Pillow)
python3 -c "
from PIL import Image, ImageDraw, ImageFont
img = Image.new('RGB', (300, 300), color=(15, 23, 42))
draw = ImageDraw.Draw(img)
draw.rectangle([0, 0, 300, 6], fill=(99, 102, 241))
try:
font = ImageFont.truetype('/System/Library/Fonts/Helvetica.ttc', 72)
except: font = ImageFont.load_default()
bbox = draw.textbbox((0, 0), 'EF', font=font)
draw.text(((300-(bbox[2]-bbox[0]))/2, 110), 'EF', fill='white', font=font)
img.save('thumbnail.png')
"
Or use any 300x300 PNG image.
dist/ DirectoryCRITICAL — Running domo publish from the project root causes a 400: Unable to parse form content error because the CLI tries to upload node_modules, source files, and config files, creating an oversized payload.
Solution: Copy manifest.json and thumbnail.png into dist/, then publish from there:
# Manual publish
npm run build
cp manifest.json thumbnail.png dist/
cd dist && domo publish
Automate it by updating package.json scripts:
{
"scripts": {
"build": "vite build && cp manifest.json thumbnail.png dist/",
"publish": "npm run build && cd dist && domo publish"
}
}
This ensures only built assets, the manifest, and thumbnail are uploaded.
Use DA CLI to generate new components with correct structure, then port logic:
# Generate component structure
da generate component SalesChart
# Copy component logic from generated app
# Replace data fetching with Domo APIs
# Update imports and dependencies
✅ Reference structure - Shows correct Domo app organization
✅ Component generation - Creates properly structured components
✅ Pattern examples - Demonstrates Domo conventions
✅ Starting fresh - If conversion is too complex, start new and port logic
❌ No automatic conversion - Doesn't transform SSR to client-side
❌ No migration wizard - No step-by-step conversion tool
❌ No code transformation - Doesn't rewrite framework-specific code
❌ No API migration - Doesn't replace backend calls automatically
pages/api/, app/api/)fetch() calls to backend with Domo APIsBrowserRouter to HashRouterbase: './'lovable-tagger) from Vite confignext-themes and replace useTheme() with hardcoded themeplaywright.config.ts, playwright-fixture.ts, bun.lock*)ryuu.js dependency for Domo API integrationmanifest.json with app name, version, and sizethumbnail.png (300x300 PNG) in project rootmanifest.json + thumbnail.png into dist/npm run build)dist/ directory (cd dist && domo publish)Original (Lovable/Next.js):
// pages/dashboard.tsx
export async function getServerSideProps() {
const sales = await fetch('http://api.company.com/sales').then(r => r.json());
return { props: { sales } };
}
export default function Dashboard({ sales }) {
return <div>{/* Render sales data */}</div>;
}
Converted (Domo):
// src/components/Dashboard/Dashboard.tsx
import { useEffect, useState } from 'react';
import domo from 'ryuu.js';
export default function Dashboard() {
const [sales, setSales] = useState([]);
useEffect(() => {
// Fetch from Domo dataset instead of backend
domo.get('/data/v1/sales').then(setSales);
}, []);
return <div>{/* Render sales data */}</div>;
}