Building the DesignComponent

Props Contract

interface DesignComponentProps {
  control: FormControl;    // Default config (from plugin's defaultConfig)
}
// No value, onChange, onBlur — DesignComponent is purely visual

Two Use Cases

The DesignComponent appears in two places:

• Palette tile — Small thumbnail in the control palette, showing the icon and label
• Canvas preview — When a control is on the canvas in design mode, this renders inside the design overlay frame

Phone Input Design Component

import React from 'react';
import type { DesignComponentProps } from '@atlas-forms/types-js';

export const PhoneDesignComponent: React.FC<DesignComponentProps> = ({ control }) => (
  <div className="design-preview phone-preview">
    <label className="field-label">{control.label || 'Phone Number'}</label>
    <div className="input-mockup">
      <span className="flag-placeholder">🇺🇸</span>
      <span className="input-placeholder">+1 (555) 000-0000</span>
    </div>
  </div>
);

Design Best Practices

• Keep it simple — The design component is a thumbnail, not a full render. Show the shape and key visual elements only.
• Show the label — Always render control.label so form authors can read the field name on the canvas.
• Use static/placeholder data — Never make API calls or use hooks that fetch data in the design component.
• Match the visual shape — The design component should look similar to the edit component so authors can recognise what they are dropping.
• Omit interaction — No click handlers, no focus states, no validation messages.

When to Omit DesignComponent

If you omit DesignComponent, Form Studio falls back to rendering EditComponent in static mode (no events). This works for most controls. Only provide a custom DesignComponent when the edit component is too heavyweight for design-mode rendering (e.g., it makes API calls on mount).