Documentazione · src/studio
Lo Studio
Dieci file per l’editor della forma. Non è una collection di Payload: scrive direttamente i sei store, che sono file — e per questo si vedono in un diff.
Perché non è una collection
Il catalogo delle ricette è uscito da una collection di Payload, dove stava riferendo per nome stili che vivono nei file: metà artefatto da una parte e metà dall’altra. Una modifica in admin non compariva in nessun diff, e allineare due ambienti significava esportare a mano.
Ora è tutto dalla stessa parte. Lo Studio scrive i file, i file stanno in versione, un cambio di forma si rivede come si rivede il codice. E Tailwind li legge, cosa che con una collection non avrebbe potuto fare.
l’editor: viewMode, slot, stili, temi, ricette
la parte server: legge gli store e i nomi dei componenti, senza importare React
La lettura, con fallback iniettato
readViewModes(fallback) // in dev legge il file; su serverless l'fs non ha i `db.*.json` nel bundle, // quindi si usa il fallback che il consumer importa come modulo
Il confine di produzione
// `/api/studio/*` risponde 404 fuori da sviluppo: la forma si aggiorna // editando in dev e ri-deployando, non scrivendo in produzione
I percorsi li dichiara il consumer
Dove stanno i sei store lo dice il progetto, passandolo. Il pacchetto leggeva le variabili d’ambiente da solo, e questo faceva sì che un nome scelto da noi diventasse parte della configurazione di chi installa: rinominarlo sarebbe stato un breaking change che nessun controllo avrebbe visto.
Stessa logica per il salto dell’autenticazione: è un’affordance di sviluppo locale, e il valore lo decide il consumer. Il pacchetto non legge process.env.
dove vivono gli store — dichiarati, non letti dall’ambiente
l’aggancio a Next, incluso il salto del gate di auth in locale
L'aggancio, dal consumer
// la vista Studio si registra come vista dell'admin di Payload, // e i percorsi degli store li dichiara il progetto — non il pacchetto
scrive gli store, generandoli dalle baseline quando mancano
porta un viewMode nella forma canonica prima di scriverlo
I tre momenti di una ricetta
Un’animazione è una ricetta con tre momenti: initial prima del trigger, quello di transizione, ending dopo. Restano tre campi distinti perché sono tre cose distinte, e comprimerli in uno solo avrebbe costretto a inventare una sintassi.
Le classi dei tre momenti vengono dagli stili dello Studio, quindi Tailwind le genera dallo stesso file. È dogfooding: le animazioni usano la style guide come la usa qualunque viewMode.
Il catalogo di partenza ne porta settantanove: dieci famiglie — fade, slide, reveal, zoom, flip, rotate, blur, skew, wipe, desaturate — nove delle quali per gli otto punti della rosa, più le varianti senza direzione. Il nome dice da dove si entra: animate:fadeBR entra da in basso a destra.
Stati e ricette sono generati dalla stessa tabella, e non è un vezzo: una ricetta cita tre stili per NOME, e un nome sbagliato non produce un errore — produce un’animazione che non parte. Scrivendoli due volte, prima o poi divergono e nessuno se ne accorge.
L’aggancio all’admin
Lo Studio è servito come vista personalizzata dell’admin di Payload, con due voci di navigazione — una verso lo Studio, una verso il sito pubblico. Il progetto le monta nella propria configurazione; sono cinque sottopercorsi pubblici distinti proprio perché si montino uno per uno.
la vista personalizzata
le voci di navigazione
la porta dell’area
Continua
Altro in «La forma · studio e baseline»
L’AdminBarTutte le diciassette pagineindice