Composify

The Catalog is the central registry for Composify. Both the editor and the renderer depend on it. Every component must be registered in the Catalog before it can be used in the editor or rendered correctly.

Through the Catalog, you define:

• Component availability in the editor
• Prop specifications (what props are accepted)
• Editor UI for props (how they are edited)
• Metadata like categories and default values.

Note on Unregistered Components: If you attempt to render a component that has not been registered via Catalog.register, Composify treats it as a React Fragment. The component will not render, and its props will be ignored, but the application will not crash.

import { Catalog } from 'composify';

// Components must be registered here to be usable
Catalog.register('ComponentName', {
  component: MyComponent,
  props: { ... },
});

Composify implements a democratized version of Server-Driven UI. In this architecture, the server (or a remote configuration) decides which components are rendered and how they are composed, rather than the client having a hardcoded layout.

This enables:

• Instant UI updates: Change layouts and component combinations without redeploying your application.
• Decoupled workflows: Allow non-engineers to manage content and layouts while engineers focus on building the underlying component library.

Composify allows you to use your actual production code as a design canvas. Instead of creating static mockups or lookalike components that eventually drift from the real implementation, designers build using the exact same components used in the live application.

This approach provides:

• Zero drift: The design canvas is the production code.
• Guaranteed consistency: Only components registered in your system can be used in the editor.
• Creative freedom with guardrails: Designers work within the established boundaries of your actual UI stack.

Workflow for new components:

1. Designers identify a need for a new component.
2. Engineers build and register the component in the system.
3. The component becomes instantly available for use in the Composify editor.

Composify is a Server-Driven UI (SDUI) solution designed to bridge the gap between code-based design systems and visual editing. Unlike traditional no-code tools that require you to abandon your code or rewrite components to fit a proprietary SDK, Composify works with your existing components.

It allows engineering teams to provide 'building blocks' from their existing design system to non-technical users (like marketing or product teams), enabling them to compose layouts visually without requiring new code deployments.

The children prop is a specialized version of the node property. By defining a prop named children with type: 'node', the property is hidden from the standard property panel. Instead, it enables a visual canvas feature where you can directly drop and arrange child components onto the canvas, mimicking standard React composition.

Catalog.register('Sample', {
  component: Sample,
  props: {
    children: {
      label: 'Children',
      type: 'node',
    },
  },
});

Composify follows a specific workflow to enable Server-Driven UI (SDUI) and visual editing:

1. Register your components: Define editable props, types, and defaults in a Catalog using your actual production components.
2. Render JSX directly: Use the Renderer to parse JSX strings from your backend/server and render them as React components.
3. Edit visually: Use the Editor component to allow non-technical users to compose layouts visually using the registered components.

Composify offers two ways to implement the engine:

1. Open Source Library: Provides the core engine, including the Editor and the Renderer. You are responsible for the backend plumbing, such as the database, API, version history, and collaboration features.
2. Composify Cloud: Provides the full infrastructure layer. You register your components in your code, and Composify Cloud handles storage, real-time collaboration, and content delivery, removing the need to maintain your own backend.

An object property type allows you to group multiple controls together into a single structured package in the Composify editor. You define the structure of this object using the fields option. Each entry within fields is itself a property specification, meaning you can nest types like text, number, boolean, or even other object and array types to create complex data structures.

Catalog.register('Sample', {
  component: Sample,
  props: {
    actions: {
      label: 'Actions',
      type: 'object',
      fields: {
        label: {
          label: 'Label',
          type: 'text',
        },
        primary: {
          label: 'Primary',
          type: 'boolean',
        },
      },
    },
  },
});

Unlike traditional CMSs (e.g., WordPress) that lock you into specific themes and plugins, Composify allows you to use your existing production component library as the foundation for your content experience.

Key benefits include:

• Component Consistency: Use the same components for marketing pages as you do for your core product.
• Visual Editing without Templates: Content and marketing teams can build visually using your actual design system rather than being limited by pre-made templates.
• Zero Gap between CMS and Production: The visual editor operates on your actual production components, ensuring that what is edited is exactly what ships to users.

Composify enables a Server-Driven UI (SDUI) pattern. Instead of hard-coding UI in your application code, you store JSX strings (the source) on your server.

1. Engineers build and register reusable React components in a Catalog.
2. Non-developers use the Editor to compose pages using those components.
3. The Application fetches the JSX string from the server and uses the Renderer to display it.

This allows for UI updates, A/B testing, and rapid prototyping without requiring new code deployments or CI/CD cycles.