Documentazione · src/baselines
Le baseline
Dieci file: i valori da cui un progetto vuoto parte. Non sono runtime — il motore legge gli store, non questi file. Sono il punto di partenza che init copia una volta.
Punto di partenza, non configurazione
La distinzione è la cosa più importante di quest’area. Le baseline non vengono lette a runtime: init le scrive nei sei store del progetto, e da quel momento appartengono al progetto. Aggiornare il pacchetto non le riscrive.
Il che significa che un progetto può divergere quanto vuole senza combattere con la libreria. Il prezzo era che un miglioramento nelle baseline non arrivava da solo a chi aveva già installato — mai, nemmeno chiedendolo.
Per questo esiste npx woodylab-uims update: applica agli store lo stato del pacchetto, e la regola è che ciò che il pacchetto SPEDISCE viene ripristinato mentre tutto il resto resta dov’è. Un viewMode del pacchetto che hai modificato torna com’era, componente compreso: chi voleva una variante doveva CLONARLO con un nome suo.
La garanzia più forte è un tema tuo: update non tocca in nessuno store ciò che appartiene a un tema che il pacchetto non gestisce. E reset è il gemello distruttivo, per quando stai solo provando.
la porta: cosa init legge
I valori di partenza, non il runtime
import { baselineStyles } from '@woodylab/uims/baselines'
// il motore legge gli store del progetto, non questi file:
// servono a `init` per scriverli la prima voltaLa style guide di partenza
Quattrocentoventinove stili, organizzati per ASSE: superficie, inchiostro, bordo, raggio, elevazione, trama, luce, rango tipografico, movimento, filtro. Ogni asse copre la propria scala per intero, anche i gradini che oggi non servono — un vocabolario con dei buchi costringe a scrivere una utility, ed è esattamente ciò che il vocabolario esiste per evitare.
La maggior parte è uno a uno con una utility di Tailwind — textXs È text-xs — e non è ridondanza: il nostro nome non aggiunge un valore, aggiunge un posto dove domani può atterrare un’informazione in più senza toccare i chiamanti.
Sopra ci sono una ventina di COMPOSIZIONI, che citano soltanto nomi del terzo livello e portano il nome che userebbe una persona: bgGrid è us-surfacePrimary us-patternGrid, imgPolaroid è us-borderMat us-roundedSm us-elevationLg. Non introducono CSS proprio.
È la parte più densa delle baseline e quella che conviene leggere per prima quando si vuole capire come è pensato l’aspetto: i nomi dicono il vocabolario.
la style guide di partenza
Un valore di partenza, non il runtime
// `init` lo copia in `db.styles.json` UNA VOLTA. // Da li in poi il motore legge lo store del progetto, non questo file.
il cablaggio delle dipendenze che il pacchetto si porta dietro: Radix, Swiper — tre chiavi, non una base piatta
I viewMode e i temi
I viewMode di partenza sono il file più lungo del pacchetto, ed è giusto che lo sia: descrive la configurazione di default di ogni forma. Accanto ci sono i viewMode presentazionali del pacchetto — strutture, con themeStyles per tema — e quelli dell’editor, che stanno in un tema a parte.
Il catalogo dei temi è una palette più dei font, e oggi ne spedisce UNO. Ce n’erano tredici, tolti per rifarli da uno scenario pulito: nessuno degli altri dodici dichiarava l’inchiostro dei ruoli, e un tema senza inchiostro non degrada — cade sul ripiego chiaro e scrive chiaro su chiaro.
La palette ha quaranta chiavi: dieci ruoli, ognuno con la variante scura e con il proprio inchiostro. La differenziazione strutturale non sta qui ma nei themeStyles dei viewMode: è quello che tiene un tema leggero.
La palette è UNA nel global, non una per tema: dato il tema scelto, un seeder importa la palette corrispondente e la scrive nei campi colore. I viewMode usano solo token semantici, quindi cambiare palette non tocca niente.
la configurazione di default di ogni viewMode
le strutture del pacchetto, con themeStyles per tema
i viewMode dell’editor, nel tema admin
il catalogo: palette più font
le palette, una per tema
Effetti ed eventi
Le ricette di animazione di partenza seguono la stessa regola dei viewMode: il codice definisce quali esistono, init le scrive se mancano, l’admin le modifica. Le fixture dei test derivano da qui, così un test non può passare contro una ricetta inventata.
Il catalogo degli eventi porta una cosa che un handler non può dichiarare da solo: gli eventi di STATO, quelli cablati per default nel reducer dello store. Esistono come nomi anche se nessun handler risponde, perché è il reducer a trattarli.
le ricette di animazione di partenza
il catalogo degli eventi, inclusi quelli di stato