Skip to main content
Benutzerdefinierte Objekte sind neue Datensatztypen, die Ihre App zu einem Arbeitsbereich hinzufügt – Postkarte, Rechnung, Abonnement, alles, was spezifisch für Ihre Domäne ist. Jedes Objekt deklariert sein Schema (Felder, Relationen, Standardwerte) und einen stabilen universellen Bezeichner, der über Synchronisierungen und Deployments hinweg bestehen bleibt.
src/objects/post-card.object.ts

Hauptpunkte

  • Der universalIdentifier muss eindeutig und über Deployments hinweg stabil sein.
  • Jedes Feld benötigt name, type, label und einen eigenen stabilen universalIdentifier.
  • Das Array fields ist optional — Sie können Objekte ohne benutzerdefinierte Felder definieren.
  • Inline definierte Felder benötigen kein objectUniversalIdentifier – er wird vom übergeordneten Objekt geerbt. Verwenden Sie defineField(), um Objekten Felder hinzuzufügen, die Ihnen nicht gehören.
  • Sie können mit yarn twenty dev:add object neue Objekte erzeugen; der Assistent führt Sie durch Benennung, Felder und Beziehungen. Siehe Architektur → Gerüste für Entitäten.
Basisfelder werden automatisch hinzugefügt. Wenn Sie ein benutzerdefiniertes Objekt definieren, erstellt Twenty Standardfelder wie id, name, createdAt, updatedAt, createdBy, updatedBy und deletedAt für Sie. Sie müssen diese nicht in Ihrem fields-Array deklarieren – nur Ihre benutzerdefinierten Felder. Sie können ein Standardfeld überschreiben, indem Sie eines mit demselben Namen deklarieren, aber das ist nur selten eine gute Idee.

Feldtypen

Die vollständige Menge von FieldType-Werten, exportiert aus twenty-sdk/define: Zusammengesetzte Typen speichern mehrere Unterfelder (z. B. FULL_NAME = Vorname + Nachname; CURRENCY = amountMicros + currencyCode). SELECT und MULTI_SELECT erfordern ein options-Array wie im obigen Beispiel.

Standardwerte

Wörtliche Zeichenfolgen-Standardwerte müssen in einfache Anführungszeichen innerhalb der Zeichenfolge eingeschlossen werden — defaultValue: "'Draft'", nicht defaultValue: "Draft". Deshalb verwendet das status-Feld oben `'${PostCardStatus.DRAFT}'`. Nicht in Anführungszeichen gesetzte Zeichenfolgen sind für berechnete Standardwerte reserviert, die ausgewertet werden, wenn ein Datensatz erstellt wird:
  • 'uuid' — generiert eine UUID (für UUID-Felder)
  • 'now' — der aktuelle Zeitstempel (für DATE_TIME-Felder)
Dieselbe Konvention gilt für Zeichenketten-Unterfelder zusammengesetzter Standardwerte (z. B. { source: "'MANUAL'" } in einem ACTOR-Feld) und für SELECT-/MULTI_SELECT-Werte. Ein wörtlicher Zeichenfolgen-Standardwert, der nicht in Anführungszeichen gesetzt ist, löst beim Build deiner App eine Warnung aus.

Nullbarkeit

isNullable steuert, ob ein Feld NULL akzeptiert. Standardmäßig ist es true – lasse es für optionale Felder weg. Setze isNullable: false, um ein Feld auf Datenbankebene erforderlich zu machen. Änderungen an isNullable werden bei jedem Sync angewendet, einschließlich Syncs, die ein vorhandenes Feld aktualisieren – so kannst du die Nullbarkeit eines Feldes ändern, indem du das Manifest bearbeitest und erneut synchronisierst.
Das Ändern eines vorhandenen Feldes in nicht nullbar erfordert einen Standardwert. Wenn du ein Feld auf isNullable: false änderst, musst du auch einen defaultValue angeben, der nicht NULL ist. Der Standardwert füllt alle vorhandenen NULL-Zeilen auf, bevor die NOT NULL-Einschränkung angewendet wird; ohne ihn schlägt die Synchronisierung mit Default value cannot be null for non-nullable fields fehl. Relationsfelder und TS_VECTOR-Felder sind immer nullbar, daher hat isNullable keine Auswirkung auf sie.

Was kommt als Nächstes

  • Verbinden Sie dieses Objekt mit anderen – siehe Relationen für das bidirektionale Relationsmuster.
  • Fügen Sie Objekten aus anderen Apps Felder hinzu – siehe Objekte erweitern für defineField().
  • Zeigen Sie dieses Objekt in der UI an – siehe Ansichten und Navigationsmenüeinträge, um es in der Seitenleiste zu platzieren.