dido-frontend-nuxt
Frontend Nuxt di Dido
Il metodo dei frontend Nuxt di Dido. Skill richiesta: dido-code-style, con i principi validi per ogni stack. Qui c'è solo ciò che è specifico del frontend.
Implementazione di riferimento: il boilerplate Nuxt 4 di Dido (DidoMarchet/starter-kit-nuxt-webapp su GitHub). Un sito nuovo parte da lì, e lì si legge il codice di composable, plugin e configurazione. I fatti del boilerplate (cosa è già cablato, moduli, rendering, sistema SCSS) stanno nei suoi docs/project-architecture.md e docs/scss-system.md.
Nei progetti nati dal boilerplate lo stesso metodo sta anche in docs/code-style.md. Se il progetto dice una cosa diversa da questa skill, vale il progetto, e la differenza va segnalata nel report perché una delle due fonti è da correggere. In un progetto più vecchio con convenzioni diverse, allineati al codice attorno.
| Stai per toccare | Leggi |
|---|---|
| chiamate a un backend di Dido: login, token, errori | riferimento/chiamate-al-backend.md |
Principi
- Componi con il design system. Margini e padding con le classi utility, i gap con i token, la larghezza con le righe (
.row-*). Riusa tipografia, bottoni e card che ci sono già, niente spaziature su misura. - Token pragmatici. I token sono variabili SCSS esposte come classi numerate, non un sistema formale di design token. Un valore usato una volta sola si scrive dov'è, sono token solo i valori ricorrenti.
- Valori disciplinati. Numeri pieni o multipli di 5, anche nelle misure di layout, e font a multipli di 2 o 4. Se il progetto ha un Figma, i valori vengono da lì e non si inventano, ma si arrotondano: un valore che non è un token della scala né un multiplo di 5 diventa il più vicino dei due (67 → 65, 17 → 16).
- Testi staccati dalle righe. Un testo, un titolo o una CTA non stanno mai appoggiati a una riga visibile (righe della griglia di sfondo, divisori verticali): hanno un padding minimo dalla riga anche se il Figma li allinea lì, con un token del progetto applicato da una classe. Le immagini possono toccarla.
- Degrada, non cadere. Un dato o una config che manca produce uno stato gestito (fallback, messaggio, sezione assente), mai una pagina in errore. In SSR una proprietà letta su un oggetto che può mancare fa fallire tutta la pagina, quindi il valore di sicurezza va dove leggi (
config?.chiave ?? default).