Vai al contenuto principale
Gli oggetti personalizzati sono nuovi tipi di record che la tua app aggiunge a uno spazio di lavoro — Cartolina, Fattura, Abbonamento, qualsiasi cosa specifica per il tuo dominio. Ogni oggetto dichiara il proprio schema (campi, relazioni, valori predefiniti) e un identificatore universale stabile che persiste tra le sincronizzazioni e le distribuzioni.
src/objects/post-card.object.ts

​
Punti chiave

  • Il universalIdentifier deve essere univoco e stabile tra i deployment.
  • Ogni campo richiede un name, type, label e il proprio universalIdentifier stabile.
  • L’array fields è facoltativo: puoi definire oggetti senza campi personalizzati.
  • I campi inline definiti qui non hanno bisogno di un objectUniversalIdentifier — viene ereditato dall’oggetto padre. Usa defineField() per aggiungere campi a oggetti che non possiedi.
  • Puoi generare nuovi oggetti con yarn twenty dev:add object, che ti guida nella denominazione, nei campi e nelle relazioni. Vedi Architettura → Scaffolding delle entità.
I campi base vengono aggiunti automaticamente. Quando definisci un oggetto personalizzato, Twenty crea per te campi standard come id, name, createdAt, updatedAt, createdBy, updatedBy e deletedAt. Non è necessario dichiararli nel tuo array fields — solo i tuoi campi personalizzati. Puoi sovrascrivere un campo predefinito dichiarandone uno con lo stesso nome, ma è raramente una buona idea.

​
Tipi di campo

L’insieme completo dei valori di FieldType, esportati da twenty-sdk/define: I tipi compositi memorizzano più sotto-campi (ad es. FULL_NAME = nome + cognome; CURRENCY = amountMicros + currencyCode). SELECT e MULTI_SELECT richiedono un array options come nell’esempio sopra.

​
Valori predefiniti

I valori predefiniti letterali devono essere racchiusi tra apici singoli all’interno della stringa — defaultValue: "'Draft'", non defaultValue: "Draft". Ecco perché il campo status sopra utilizza `'${PostCardStatus.DRAFT}'`. Le stringhe senza virgolette sono riservate ai valori predefiniti calcolati, valutati quando viene creato un record:
  • 'uuid' — genera un UUID (per i campi UUID)
  • 'now' — il timestamp corrente (per i campi DATE_TIME)
La stessa convenzione si applica ai sotto-campi stringa dei valori compositi predefiniti (ad es. { source: "'MANUAL'" } su un campo ACTOR) e ai valori SELECT/MULTI_SELECT. Una stringa letterale predefinita lasciata senza virgolette genera un avviso quando la tua app viene compilata.

​
Nullabilità

isNullable controlla se un campo accetta NULL. Il valore predefinito è true — omettilo per i campi facoltativi. Imposta isNullable: false per rendere un campo obbligatorio a livello di database. Le modifiche a isNullable vengono applicate a ogni sincronizzazione, incluse quelle che aggiornano un campo esistente — quindi puoi cambiare la nullabilità di un campo modificando il manifest e rieseguendo la sincronizzazione.
Rendere un campo esistente che non ammette NULL richiede un valore predefinito. Quando imposti isNullable: false per un campo, devi anche fornire un defaultValue non nullo. Il valore predefinito esegue il backfill di tutte le righe NULL esistenti prima che venga applicato il vincolo NOT NULL; senza di esso la sincronizzazione non riesce con l’errore Default value cannot be null for non-nullable fields. I campi di relazione e i campi TS_VECTOR ammettono sempre NULL, quindi isNullable non ha alcun effetto su di essi.

​
Cosa c’è dopo