Validierung und Bedingungen

Enum-Werte

Wird für String- oder Number-Eigenschaften verwendet, um Select-Felder darzustellen:

import type { StringProperty } from "@rebasepro/types";

// Simple: each value mapped to its label
const simple: StringProperty = {
    type: "string",
    name: "Status",
    enum: { draft: "Draft", published: "Published", archived: "Archived" }
};

// As a list, which keeps the order you write
const listed: StringProperty = {
    type: "string",
    name: "Status",
    enum: [
        { id: "draft", label: "Draft" },
        { id: "published", label: "Published" },
        { id: "archived", label: "Archived" }
    ]
};

// With colors (for Kanban columns and chips)
const colored: StringProperty = {
    type: "string",
    name: "Status",
    enum: [
        { id: "draft", label: "Draft", color: "grayDark" },
        { id: "published", label: "Published", color: "greenDark" },
        { id: "archived", label: "Archived", color: "orangeDark" }
    ]
};

Eine einfache Werteliste, enum: ["draft", "published", "archived"], ist kein Teil des Typs. Eine JavaScript-Konfiguration, die eine solche schreibt, funktioniert weiterhin: Das Datenbank-Enum, die generierten Typen und das Dropdown des Admins lesen sie als diese Werte, jeder sein eigenes Label.

Validierung

Jede Regel befindet sich im validation-Block der Eigenschaft. Welche Regeln eine Eigenschaft akzeptiert, hängt von ihrem Typ ab – min zählt Zeichen bei einem String, vergleicht Größenordnungen bei einer Zahl und zählt Elemente bei einem Array.

properties: {
    title: {
        type: "string",
        name: "Title",
        validation: { required: true, min: 2, max: 200 }
    },
    slug: {
        type: "string",
        name: "Slug",
        validation: {
            unique: true,
            matches: /^[a-z0-9-]+$/,
            matchesMessage: "Lowercase letters, digits and hyphens only",
            trim: true,
            lowercase: true
        }
    },
    readingMinutes: {
        type: "number",
        name: "Reading time",
        validation: { integer: true, moreThan: 0, max: 120 }
    }
}

Wo die Validierung ausgeführt wird

Der Server prüft validation an der Anfragegrenze — REST, der Realtime-Socket und MCP — anhand dessen, was der Aufrufer gesendet hat, bevor beforeSave läuft, und beantwortet einen Schreibvorgang, der eine Regel verletzt, mit einem 400, das jedes fehlschlagende Feld benennt. Serverseitiger Code, der prozessintern schreibt, ist vertrauenswürdig und wird nicht gegen diese Regeln geprüft: rebase.data und rebase.dataAsAdmin in einer Funktion oder einem Cron-Job, context.data in einem Callback, ein Seed-Skript. Was dort gilt, ist das, was die Datenbank erzwingt — required (NOT NULL), unique (ein Unique-Index), der Typ eines Enums und die Breite einer varchar- oder char-Spalte. Alles andere, das Ihr Servercode schreibt, prüfen Sie im Code, der es schreibt.

Das Admin-Panel prüft dieselben Regeln vor dem Speichern, im Datensatzformular und im Inline-Editor der Collection-Tabelle. Eine Tabellenzelle beurteilt einen Wert, sobald Sie ihn bearbeiten: Ein gespeicherter Wert, der eine später hinzugefügte Regel verletzt, zeigt in der Tabelle keinen Fehler, bis jemand diese Zelle bearbeitet.

Alle Typen

Regel	Typ	Beschreibung
required	boolean	Der Wert muss vorhanden sein. Bei einem string gilt "" als nicht vorhanden: Die API lehnt es bei jedem Schreibvorgang ab, ob Erstellung oder Aktualisierung, mit derselben required-Verletzung (es sei denn, die Collection hat ein beforeSave, das es füllen darf)
requiredMessage	string	Was angezeigt wird, wenn er fehlt: vom Admin-Formular und als message des required-Eintrags des Felds im 400 der API. Das NOT NULL der Datenbank trägt keine Meldung
unique	boolean	Nur eine Zeile in der Tabelle darf diesen Wert enthalten. Das Admin-Formular prüft dies auch beim Speichern eines Werts, den die Bearbeitung geändert hat, sodass ein Duplikat vor dem Schreibvorgang an seinem Feld benannt wird
uniqueInArray	boolean	Nur ein Eintrag pro Array darf ihn enthalten. Gilt für ein direktes Kind einer array-Eigenschaft oder ein Kind der ersten Ebene einer map darin. Nur im Admin-Formular – wird nicht von der API oder der Datenbank erzwungen.

Strings

Regel	Typ	Beschreibung
min / max	number	Mindest- / Höchstanzahl von Zeichen, inklusive. Mit columnType: "varchar" oder "char" bestimmt max auch die Spaltengröße (VARCHAR(max)); eine Verringerung auf einer Tabelle, die bereits längere Zeilen enthält, ist eine Migration, die die Datenbank verweigert, und der Collection-Editor warnt, wenn eine Änderung ihn senkt. Die Standardspalte ist TEXT, die max unbegrenzt lässt — die Grenze liegt dann allein in der Anfrageprüfung des Servers
length	number	Genau diese Anzahl von Zeichen – ein Ländercode, eine Referenz mit fester Breite
matches	string | RegExp	Ein Muster, dem der gesamte Wert entsprechen muss. Ein String wird pro Anfrage kompiliert; ein nicht kompilierbarer String wird daher beim Start abgelehnt, anstatt stillschweigend ignoriert zu werden
matchesMessage	string	Was das Formular anzeigt, wenn matches fehlschlägt
trim	boolean	Führende und nachgestellte Leerzeichen vor dem Speichern entfernen. Eine Transformation, keine Prüfung – sie ändert den geschriebenen Inhalt, was sie zur Lösung für „denselben Tag zweimal, einmal mit nachgestelltem Leerzeichen“ macht. Nur im Admin-Formular – wird nicht von der API oder der Datenbank erzwungen.
lowercase / uppercase	boolean	Groß-/Kleinschreibung des Werts vor dem Speichern anpassen, wie trim. Nur im Admin-Formular – wird nicht von der API oder der Datenbank erzwungen.

E-Mail- und URL-Formate sind keine Validierungsregeln. email und url sind Flags direkt an der Eigenschaft, neben type – Aussagen über die Daten, aus denen der OpenAPI-Vertrag generiert wird, und kein Formularverhalten:

properties: {
    email: { type: "string", name: "Email", email: true },
    website: { type: "string", name: "Website", url: true }
}

Siehe String-Eigenschaften.

Zahlen

Regel	Typ	Beschreibung
min / max	number	Kleinster / größter akzeptierter Wert, inklusive
moreThan / lessThan	number	Die exklusiven Gegenstücke zu min und max
positive / negative	boolean	Strikt über / unter null. 0 wird von beiden abgelehnt – verwenden Sie min: 0, um es zu erlauben
integer	boolean	Kein Nachkommateil. Ändert nicht den Spaltentyp; columnType tut dies

Datumswerte

Regel	Typ	Beschreibung
min / max	Date	Frühestes / spätestes akzeptiertes Datum, inklusive. Ein fester Zeitpunkt, nicht „heute“

Arrays

Regel	Typ	Beschreibung
min / max	number	Mindest- / Höchstanzahl von Elementen, inklusive. Elemente, nicht Zeichen

Bedingte Felder

Sie können Felder dynamisch gestalten, sodass sie auf die Werte der Entität reagieren. Dafür gibt es zwei Möglichkeiten:

1. JSON-Logic-Bedingungen (Deklarativ)

Sie können die conditions-Eigenschaft verwenden, um deklarative JSON-Logic-Regeln zu definieren, die serialisiert und im Collection-Editor visuell bearbeitet werden können.

price: {
    type: "number",
    name: "Price",
    conditions: {
        disabled: { "==": [{ "var": "values.is_free" }, true] },
        required: { "!=": [{ "var": "values.is_free" }, true] },
        min: 0,
        clearOnDisabled: true // Set to null if field gets disabled
    }
}

Das Conditions-Objekt gibt Ihnen Zugriff auf:

• disabled, disabledMessage, clearOnDisabled, hidden, readOnly
• required, requiredMessage, min, max
• defaultValue
• enumConditions, allowedEnumValues, excludedEnumValues
• referencePath, referenceFilter
• canAddElements, sortable (für Arrays)
• acceptedFiles, maxFileSize (für Uploads)

disabledMessage ist der Satz, den Benutzer anstelle des Steuerelements sehen. Ohne ihn erklärt ein ausgegrautes Feld nichts – und das ist der Unterschied zwischen einem Formular, das jemanden anleitet, und einem, das ihn abweist.

Bedingungen betreffen nur das Formularverhalten

Nur im Admin-Formular – wird nicht von der API oder der Datenbank erzwungen. Sie laufen im Browser auf der bearbeiteten Entität und bestimmen, was das Panel anbietet. Eine Regel, die für jeden API-Aufrufer gelten muss, gehört in validation, was der Server bei REST-, Socket- und MCP-Schreibvorgängen prüft (nicht bei den prozessinternen Schreibvorgängen Ihres eigenen Servercodes), oder in eine Sicherheitsregel, welche die Datenbank für jeden erzwingt – Panel, SDK oder curl.

2. Property Builders (Programmatisch)

Für komplexes Verhalten, das nicht über JSON Logic ausgedrückt werden kann, können Sie dynamicProps verwenden, wodurch eine JavaScript-Funktion ausgewertet wird.

price: {
    type: "number",
    name: "Price",
    dynamicProps: ({ values, authController }) => ({
        admin: { disabled: values.is_free === true || !authController.user?.roles?.includes("admin") },
        validation: values.is_free ? {} : { required: true, min: 0 }
    })
}

Der gleiche Vorbehalt gilt hier noch deutlicher: Die Funktion wird im Panel gebündelt und bei jedem Rendern des Formulars aufgerufen. Nur im Admin-Formular – wird nicht von der API oder der Datenbank erzwungen.

Nächste Schritte

• Eigenschaften — die Eigenschaftstypen, für die diese Regeln gelten
• Sammlungen definieren — wo Eigenschaften deklariert werden
• Sicherheitsregeln (RLS) — die Regeln, welche die Datenbank erzwingt und die eine Validierung nicht ersetzt