Documentazione · src/config
La configurazione
Collection, global, campi, hook, permessi. È qui che il pacchetto si presenta a Payload — e la superficie è pensata perché un progetto la estenda, non la sostituisca.
Le collection
Quattro collection e un registro. pages è il layout, con le sue righe dati; sections sono le sezioni riusabili, e una sezione con righe è una vista; blocks le composizioni di blocchi riusabili; menus la navigazione. Il registro le espone insieme perché un progetto le installa in blocco.
Nessuna di queste contiene la FORMA: i viewMode e gli stili stanno negli store. È la divisione che permette di ridisegnare tutto senza una migrazione di database.
le pagine: layout, stato, bozza, meta
Il cancello in scrittura, dichiarato
access: {
read: () => true, // il sito e pubblico
...writeAccessFor(), // scrivere richiede un ruolo
}le sezioni riusabili: con le righe dati sono viste
le composizioni di blocchi riusabili, senza righe
i menu, ricorsivi
il registro
I global: la cornice del sito
Header e footer sono composizioni di slot: ogni slot ha un viewMode e i blocchi che contiene. I settings tengono la palette, i font e la configurazione generale. Il loader è un global di un elemento solo — l’indicatore dei caricamenti, vestito da un viewMode ponte. L’admin bar ha il proprio global perché la sua configurazione non è del sito ma dell’editor.
la cornice, come slot componibili
palette, font, configurazione del sito
l’indicatore dei caricamenti, un elemento solo col suo viewMode ponte
la configurazione dell’editor
Gli hook: la cache che si invalida da sola
Ogni modifica invalida i tag della DAL. Quattro hook per quattro casi: una modifica in collection, una cancellazione (dove il documento non c’è più e i tag vanno costruiti da quello che resta), un global, un menu.
Il menu ha un hook proprio perché la sua modifica invalida anche le pagine che lo mostrano, che sono tutte quelle con un header — un caso che il tag del solo documento non coprirebbe.
dopo una modifica
Come si disinnesca, e quando serve
await payload.update({ collection: 'pages', id, data, context: { disableRevalidate: true } })
// fuori da una richiesta — un seeder — `revalidateTag` non ha uno store statico
// a cui agganciarsi e lancia: «static generation store missing»dopo una cancellazione
per i global
per i menu, che toccano ogni pagina
la validazione dei form prima del salvataggio
I campi riutilizzabili
Cinque file per i campi che compaiono in più posti. Il più denso è quello dello stato dell’istanza, che costruisce trigger e conseguenze e sa quali slice il blocco espone.
fieldRoles merita una riga: un campo che decide i permessi lo amministra chi quei permessi li ha. Scriverlo aperto — create/update: () => true — su una collection users che non dichiara access significa che qualunque utente autenticato si assegna il ruolo che vuole. E il campo non compare a chi non è ADMIN: alla registrazione del primo utente non c’è nessuno autenticato, e il ruolo lo assegna il plugin.
il gruppo uiState: stato, trigger, conseguenze — costruito per blocco
i parametri di una vista viva: params e state
forma e stili
il ruolo dell’utente, scrivibile solo da chi ha il ruolo
l’utente ha almeno uno dei ruoli richiesti?
le collection forms e form-submissions, e le mail che partono all’invio